انتقال توضیحات رانگ در RSLogix 500: پیوست کردن توضیحات به آدرس خروجی
نظرات ردیف‌های RSLogix 500 را بدون از دست دادن معنای مهندسی آن‌ها منتقل کنید. پیوستگی شماره ردیف و نشانی خروجی را مقایسه کنید، از پایگاه‌دادهٔ مبدأ محافظت کنید و هر دسته را به‌صورت آفلاین اعتبارسنج...
توضیحات رَنگ در یک پروژه RSLogix 500 بخشی از پایگاه داده مهندسی هستند، نه منطق اجرایی پردازنده. به همین دلیل، در فرایند پاک‌سازی یا مهاجرت به‌راحتی نادیده گرفته یا آسیب‌دیده می‌شوند. وقتی پس از درج، کپی یا سازمان‌دهی مجدد منطق، توضیحات روی رَنگ‌های اشتباه ظاهر می‌شوند، واکنش درست این است که حالت اتصال را شناسایی کنید، یک خط مبنا حفظ کنید و پیش از تغییر آرشیو تولید، نتیجه را در یک کپی آفلاین اعتبارسنجی کنید.
انتخاب نوع اتصال تعیین می‌کند که مستندات، شماره رَنگ را دنبال کنند یا آدرسی را که با رَنگ مرتبط است.
درک کنید که دقیقاً چه چیزی جابه‌جا می‌شود
RSLogix 500 می‌تواند مستندات رَنگ را به محل فایل و رَنگ یا به یک آدرس خروجی مرتبط کند. توضیح مبتنی بر محل زمانی مفید است که فایل عمداً ثابت نگه داشته شود، اما ویرایش رَنگ‌های بالاتر می‌تواند روایت توضیح را از منطقی که قرار بوده توضیح دهد جدا کند. اتصال به آدرس می‌تواند باعث شود توضیح هنگام جابه‌جایی منطق، آدرس خروجی انتخاب‌شده را دنبال کند. یادداشت پشتیبانی راکول درباره عنوان‌های AI500 واردشده تأیید می‌کند که نرم‌افزار حالت اتصال را ارائه می‌دهد و می‌تواند مستندات را بین ارتباط با خروجی و ارتباط با شماره رَنگ تبدیل کند.
هیچ‌یک از این دو حالت همیشه درست نیست. ممکن است یک رَنگ دستور خروجی نداشته باشد، چند خروجی داشته باشد، خروجی‌ای داشته باشد که آدرس آن در جای دیگری دوباره استفاده شده باشد، یا دستوری داشته باشد که به‌عنوان بخشی از یک بازآرایی بزرگ‌تر جابه‌جا شود. بنابراین، توضیح مبتنی بر آدرس ممکن است روی بیش از یک رَنگ ظاهر شود، در حالی که توضیح مبتنی بر شماره رَنگ ممکن است در جای خود باقی بماند، حتی وقتی منطق آن جابه‌جا شده است. با اتصال مانند یک قاعده کنترل‌شده مستندسازی رفتار کنید، نه یک دکمه تعمیر خودکار.
پیش از ویرایش، از منبع محافظت کنید
فایل RSS اصلی را به‌صورت فقط‌خواندنی ذخیره کنید و چک‌سام، نام کنترلر، بازبینی برنامه و تاریخ بارگذاری آن را ثبت کنید. پایگاه داده و توضیحات رَنگ را به شکلی صادر یا چاپ کنید که بعداً قابل مقایسه باشد. اگر پروژه از یک کنترلر بارگذاری می‌شود، به یاد داشته باشید که شرح‌ها و توضیحات ممکن است در پردازنده SLC به همان شیوه منطق نردبانی ذخیره نشده باشند. بارگذاری می‌تواند منطق را بازیابی کند، اما همچنان پروژه را بدون پایگاه داده صحیح مستندات آفلاین باقی بگذارد.
روی یک فایل کپی کار کنید. چند مورد آزمایشی انتخاب کنید: یک رَنگ معمولی OTE، یک جفت OTL و OTU، یک رَنگ با چند خروجی، یک رَنگ بدون خروجی آشکار و یک زیربرنامه که قرار است منطق جدید دریافت کند. برای هر مورد، شماره فعلی فایل، شماره رَنگ، آدرس لنگر انتخاب‌شده و متن توضیح را ثبت کنید.
اتصال را بر اساس هدف مهندسی انتخاب کنید
وقتی خروجی به‌طور یکتا عملکرد را مشخص می‌کند و احتمال جابه‌جایی رَنگ وجود دارد، از اتصال به آدرس خروجی استفاده کنید. فرمان روشن‌ماندن موتور، بیت وضعیت توالی یا لچ هشدار، در صورتی که آدرس آن طبق استاندارد نام‌گذاری مدیریت شود و در جای دیگری استفاده نشده باشد، می‌تواند یک لنگر پایدار فراهم کند. توضیح را بر هدف، اینترلاک‌ها و رفتار غیرعادی عملکرد متمرکز کنید، نه اینکه صرفاً شرح نماد را تکرار کنید.
وقتی روایت به یک محل یا بخش مربوط است، نه به یک آدرس خاص، از اتصال به فایل و رَنگ استفاده کنید. نمونه‌ها شامل یادداشت‌های گذار، محاسبات عیب‌یابی، منطق مقداردهی اولیه یا رَنگی با چند خروجی مرتبط هستند. در این موارد، افزودن یک بیت صرفاً مستندسازی به منطق اجرایی برای حمل توضیح می‌تواند خطر نگهداری ایجاد کند. فقط برای رعایت یک قرارداد توضیحات، دستورهای بدون استفاده را به دستگاه در حال کار اضافه نکنید.
جفت‌های لچ و آنلچ به توجه ویژه نیاز دارند، زیرا اغلب آدرس مشترکی دارند. شرح در سطح آدرس باید معنای وضعیت لچ‌شده را توضیح دهد. توضیحات اختصاصی رَنگ باید توضیح دهند چه چیزی آن را تنظیم می‌کند، چه چیزی پاک می‌کند و کدام شرایط مجازکننده اعمال می‌شوند. اگر یک توضیح مشترک نتواند هر دو عمل را به‌طور ایمن بیان کند، یادداشت‌های تفصیلی را به‌صورت مکانی متصل نگه دارید و برای ارجاع متقابل از نمادها و شرح‌های آدرس یکدست استفاده کنید.
آدرس‌های مشترک به یک قاعده مستندسازی نیاز دارند که معنای وضعیت را از دلیل عملکرد هر رَنگ متمایز کند.
توضیحات را در دسته‌های کنترل‌شده مهاجرت دهید
کار را با یک فایل برنامه آغاز کنید، نه کل پروژه. پیش از تغییر اتصال هر توضیح، آن را با گزارش اصلی مقایسه کنید. فقط توضیحاتی را دوباره مرتبط کنید که منطق موردنظرشان بدون ابهام است. در کپی آفلاین، یک رَنگ آزمایشی موقت بالای منطق نمونه درج کنید، یک رَنگ نمونه را در فایل جابه‌جا کنید و یک نمونه را بین فایل‌ها کپی کنید. مشاهده کنید کدام توضیحات جابه‌جا می‌شوند و کدام‌ها به محل وابسته باقی می‌مانند.
پس از هر دسته، به‌دنبال توضیحات خالی، متن‌های تکراری، توضیحاتی که به آدرس‌های غیرمنتظره متصل شده‌اند و آدرس‌های خروجی استفاده‌شده در چند رَنگ بگردید. برای هر لنگر، ارجاع متقابل اجرا کنید. حتی یک بیت که یکتا به نظر می‌رسد ممکن است با یک آنلچ، دستور انتقال، عملیات فایل یا روال دیگری نوشته شود. اگر رابطه نامشخص است، توضیح منبع را بدون تغییر نگه دارید و آن را برای مهندس کنترل آشنا با توالی عملکرد دستگاه علامت‌گذاری کنید.
اعتبارسنجی در مرزهای نرم‌افزار و آرشیو
در صورت امکان، کپی ویرایش‌شده را با همان نسخه RSLogix 500 مورد استفاده در سایت باز کنید. سپس فایل ذخیره‌شده را دوباره باز کنید و آزمون‌های نمونه درج و جابه‌جایی را تکرار کنید. تبدیل بین نسخه‌ها و واردکردن پایگاه داده باید خود یک مهاجرت مستقل در نظر گرفته شود. راهنمای مرجع مجموعه دستورهای SLC 500 رسمی همچنان منبع اصلی رفتار دستورهاست، اما اتصال مستندات رفتاری مربوط به پایگاه داده نرم‌افزار است و باید در محیط نصب‌شده RSLogix بررسی شود.
مقایسه منطقی انجام دهید تا مطمئن شوید تغییر صرفاً مستنداتی پروژه، رَنگ‌های اجرایی، اندازه جدول داده، پیکربندی کانال یا تنظیمات پردازنده را تغییر نداده است. تعمیر توضیحات نباید به یک تغییر کنترلی بررسی‌نشده تبدیل شود. پیش از جایگزینی فایل اصلی، رویه‌های سایت برای پشتیبان‌گیری، تأیید و بارگذاری را دنبال کنید.
قرارداد را قابل نگهداری کنید
قاعده اتصال را به استاندارد برنامه‌نویسی و چک‌لیست بازبینی کد اضافه کنید. برای هر ویرایش تأییدشده، وجود یک آرشیو RSS به‌روز را الزامی کنید و توضیحات را با نمادها، نقشه‌های برق و متن هشدارهای HMI هماهنگ نگه دارید. برای ماشین‌هایی که همچنان روی پلتفرم SLC هستند، مالکیت مستندات را با برنامه چرخه عمر گسترده‌تر سیستم‌های PLC و PAC و رویه‌های ویرایش آنلاین RSLogix 500 سایت همسو کنید.
بهترین حالت اتصال، حالتی است که معنا را در طول ویرایش‌هایی که کارخانه واقعاً انجام می‌دهد حفظ کند. خط مبنای تأییدشده، قواعد انتخاب روشن، آزمون دسته‌ای و مقایسه پس از ذخیره، از تبدیل یک مشکل ظاهری پایگاه داده به خطری در عیب‌یابی جلوگیری می‌کنند.