راهنمای ارتقای فریم‌ویر 1756-L73: تصمیم‌گیری بین v19 و v21/v31

جایگزین کردن یک 1756-L73 خراب و مدرن‌سازی میان‌افزار آن، دو کار مهندسی متفاوت هستند. هدف از جایگزینی اضطراری، بازگرداندن یک برنامه شناخته‌شده با کمترین تغییر ممکن است. مهاجرت، نسخه کنترلر، قالب پروژه، ابزارهای مهندسی و احتمالاً رفتار یا وضعیت پشتیبانی اجزای متصل را تغییر می‌دهد. ترکیب این دو کار در زمان توقف برنامه‌ریزی‌نشده، دقیقاً زمانی که کارخانه کمترین فرصت را برای مدیریت ریسک دارد، خطر را افزایش می‌دهد.

تصمیم‌گیری باید با هدف تعمیر و نگهداری آغاز شود، نه با مقایسه سه شماره میان‌افزار. کاتالوگ و سری کنترلر نصب‌شده، میان‌افزار فعلی، ویرایش پروژه، نرم‌افزار مهندسی موجود، نسخه پشتیبان تأییدشده، ماژول‌های شاسی، شبکه‌ها، مسیر HMI یا OPC، سیستم حرکت، درایوها، تگ‌های تولیدشده و مصرف‌شده و دستورالعمل‌های پیام را تأیید کنید. میان‌افزار فقط یکی از وابستگی‌های این سیستم است.

کنترلر جایگزین باید با پروژه و معماری پیرامون آن سازگار باشد، نه صرفاً با شماره کاتالوگ درج‌شده روی پنل جلویی.

پیش از انتخاب نسخه، دامنه کار را مشخص کنید

بازیابی اضطراری

وقتی یک کنترلر پایدار تولید از کار می‌افتد، بازگرداندن همان میان‌افزار اصلی و نسخه سازگار پروژه معمولاً کم‌تغییرترین مسیر است. این کار از تبدیل برنامه در حین رفع خرابی جلوگیری می‌کند و روابط شناخته‌شده میان کنترلر، HMI، ارتباطات و ماژول‌های نصب‌شده را حفظ می‌کند. «همان نسخه» همچنان به راستی‌آزمایی نیاز دارد: تأیید کنید بسته دقیق میان‌افزار از شناسه کنترلر پشتیبانی می‌کند و پروژه اصلی در نرم‌افزار موجود باز می‌شود.

مهاجرت برنامه‌ریزی‌شده میان‌افزار

مهاجرت برنامه‌ریزی‌شده می‌تواند چرخه عمر ایستگاه مهندسی، ناهنجاری‌های مستند مرتبط با برنامه، سیاست پشتیبانی، استانداردسازی یا نیازهای بازیابی پروژه را پوشش دهد. این کار به بسته تغییر، بررسی سازگاری، برنامه توقف، آزمون‌های پذیرش و منابع بازگشت نیاز دارد. کنترلری که با موفقیت فلش شده است، هنوز ثابت نکرده که سیستم کنترل کار می‌کند.

از اسناد Rockwell به‌عنوان شواهد مخصوص هر نسخه استفاده کنید

یادداشت‌های انتشار ControlLogix Revision 19 شرکت Rockwell به‌طور صریح 1756-L73 را شامل می‌شوند و محیط RSLogix 5000 مرتبط، نسخه‌های پشتیبانی‌شده میان‌افزار، اقدامات مقدماتی و ناهنجاری‌های شناخته‌شده یا اصلاح‌شده را مشخص می‌کنند. این سند مبنای مناسبی برای ارزیابی برنامه نسخه 19 است، نه یک جدول عمومی نسخه که از پلتفرمی دیگر کپی شده باشد.

یادداشت‌های انتشار ControlLogix Revision 21 نسل‌های اولیه Studio 5000 و بهبودها، محدودیت‌ها و ناهنجاری‌های مخصوص این نسخه را پوشش می‌دهند. کارخانه‌ای که نسخه 21 را بررسی می‌کند باید این جزئیات را با قابلیت‌های واقعی پروژه و ماژول‌ها مقایسه کند، نه اینکه فرض کند نسخه جدیدتر خودبه‌خود ایمن‌تر است.

برای هر هدف دیرتر، از جمله نسخه 31، کاتالوگ دقیق کنترلر، سری، میان‌افزار، نسخه Studio 5000، سیستم‌عامل، پروفایل‌های ماژول و نرم‌افزارهای مرتبط را در زمان انجام کار، در مرکز Product Compatibility and Download Center شرکت Rockwell بررسی کنید. عبارت «L73 از v31 پشتیبانی می‌کند» را گزاره‌ای عمومی و جدا از ترکیب سخت‌افزار و نرم‌افزار در نظر نگیرید.

میان‌افزار و حافظه فیزیکی، ویژگی‌های متفاوتی هستند

تغییر میان‌افزار، حافظه فیزیکی بیشتری در 1756-L73 نصب نمی‌کند. ظرفیت کنترلر یک ویژگی سخت‌افزاری است که برای کاتالوگ و سری مربوطه مستند شده است. بااین‌حال، مصرف حافظه پروژه ممکن است پس از تبدیل تغییر کند، زیرا دستورالعمل‌ها، تگ‌ها، ساختارهای ارتباطی، مستندات و سرویس‌های میان‌افزار ممکن است به شکل متفاوتی نمایش داده شوند.

با استفاده از نرم‌افزار مهندسی هدف، پروژه تبدیل‌شده را برآورد کنید و سپس برای ویرایش‌های آنلاین و تغییرات آینده، حاشیه عملیاتی کافی در نظر بگیرید. برای الزامات سخت‌افزاری، ذخیره‌سازی، نصب و بهره‌برداری باید از راهنمای کاربر کنترلرهای ControlLogix 5570 و 5560 رسمی استفاده شود. از جدول‌های غیررسمی که برای یک کنترلر یکسان، در نسخه‌های مختلف میان‌افزار ظرفیت‌های متفاوت حافظه فیزیکی تعیین می‌کنند، اجتناب کنید.

فهرست سازگاری را تهیه کنید

با تهیه فهرست شاسی و شبکه شروع کنید. کاتالوگ، سری و میان‌افزار کنترلر؛ ماژول‌های ارتباطی و تخصصی؛ میان‌افزار ماژول‌ها؛ کلیدگذاری الکترونیکی؛ آداپتورهای I/O راه دور؛ محورهای حرکت؛ روابط ایمنی؛ درایوها و پیکربندی شبکه را ثبت کنید. اگر شبکه‌های قدیمی DeviceNet یا ControlNet همچنان فعال هستند، ابزارهای زمان‌بندی و پیکربندی آن‌ها را نیز لحاظ کنید.

سپس زنجیره نرم‌افزاری را ترسیم کنید: نسخه اصلی RSLogix 5000 یا Studio 5000، اجزای FactoryTalk Linx یا RSLinx، نسخه HMI یا SCADA، سرورهای OPC، پروفایل‌های افزوده، فایل‌های EDS، ابزارهای درایو و هر ابزار اختصاصی سازنده اصلی. نسخه کنترلر به‌تنهایی تعیین نمی‌کند که همه HMIها باید ارتقا یابند. سازگاری به درایور ارتباطی واقعی، مجموعه قابلیت‌ها و ترکیب پشتیبانی‌شده بستگی دارد.

در نهایت، رابط‌های برنامه را ترسیم کنید. تگ‌های تولیدشده و مصرف‌شده، دستورالعمل‌های MSG، رک‌های راه دور، دستگاه‌های EtherNet/IP شخص ثالث، حرکت، همگام‌سازی زمان، تاریخچه‌نگارهای داده، سیستم‌های بچ و اینترلاک‌های خارجی را شناسایی کنید. مجموعه Allen-Bradley ControlLogix به شناسایی اجزای پلتفرم کمک می‌کند، در حالی که مجموعه سیستم‌های PLC و PAC زمینه معماری‌های ترکیبی را فراهم می‌کند. سوابق سایت و مستندات سازنده همچنان مرجع اصلی سازگاری هستند.

یک مسیر واقعی برای بازگشت حفظ کنید

پیش از تبدیل، فایل اصلی ACD را در نسخه اصلی نرم‌افزار ذخیره کنید و مطمئن شوید که باز می‌شود. کاتالوگ، سری و میان‌افزار فعلی کنترلر، مسیرهای ارتباطی، تنظیمات IP یا شبکه، وضعیت کارت SD و پیکربندی شاسی را ثبت کنید. دارایی‌های پشتیبان را که به‌طور کامل در پروژه کنترلر ذخیره نشده‌اند، از جمله پیکربندی‌های HMI، شبکه، درایو و تجهیزات شخص ثالث، صادر کنید.

یک نسخه تبدیل‌شده جداگانه ایجاد کنید. تنها پروژه سالم شناخته‌شده را بازنویسی نکنید. تبدیل رو به جلو، تبدیل خودکار به نسخه قبل را تضمین نمی‌کند. بنابراین بازگشت معتبر باید شامل بسته میان‌افزار سازگار اصلی، نرم‌افزار مهندسی اصلی، فایل ACD اصلی، اطلاعات دسترسی یا مجوزها و روش بازیابی ارتباطات و دستگاه‌های غیرکنترلری باشد.

تبدیل پروژه یک تغییر مهندسی کنترل‌شده است؛ فایل تبدیل‌شده هرگز نباید جایگزین تنها نسخه اصلی قابل بازیابی شود.

پیش از فلش کردن، برنامه تبدیل‌شده را بررسی کنید

نسخه کپی را در نرم‌افزار هدف باز کنید و پیام‌های تبدیل را ثبت کنید. ویژگی‌های کنترلر، پروفایل‌های ماژول، کلیدگذاری الکترونیکی، ارتباطات، حرکت، دستورالعمل‌های افزوده، انواع داده، وابستگی‌های ایمنی یا افزونگی و هر رفتار دستورالعملی را که در یادداشت‌های انتشار برجسته شده است، بررسی کنید. مطمئن شوید پروفایل‌های افزوده و نرم‌افزارهای پشتیبان موردنیاز نصب و تأیید شده‌اند.

حافظه پروژه و مصرف منابع را مقایسه کنید. اطمینان حاصل کنید تگ‌ها، برنامه‌ها، روتین‌ها، ماژول‌ها، تعاریف محورها، مسیرهای MSG و اتصالات تولیدشده یا مصرف‌شده همچنان وجود دارند. اگر مهاجرت چندین نسخه اصلی را دربرمی‌گیرد، به قابلیت‌هایی که بین نقاط مبدأ و مقصد معرفی، تغییر یا منسوخ شده‌اند توجه بیشتری کنید. پروژه‌ای که هیچ خطای تبدیلی گزارش نمی‌کند، همچنان به بررسی عملکردی نیاز دارد.

عملیات میان‌افزار را کنترل کنید

از روند و بسته میان‌افزار مورد تأیید Rockwell برای هدف راستی‌آزمایی‌شده استفاده کنید. از برق پایدار و مسیر ارتباطی مطمئن اطمینان یابید، کنترلر را از مسئولیت تولید خارج کنید و اقدامات مقدماتی یادداشت‌های انتشار را انجام دهید. پیش از کار، نحوه استفاده از کارت SD و تنظیمات بارگذاری غیرفرار را تأیید کنید؛ یک تصویر یا حالت بارگذاری غیرمنتظره می‌تواند توالی بازیابی موردنظر را مختل کند.

پس از فلش کردن، پیش از دانلود، نسخه واقعی کنترلر را دوباره بخوانید. فقط پروژه نسخه هدف را که بررسی شده است دانلود کنید. هشدارها و وضعیت کنترلر را ثبت کنید. صرفاً به دلیل اینکه کنترلر وارد حالت Run شده است، موفقیت را اعلام نکنید.

آزمون پذیرش باید کل مسیر کنترل را پوشش دهد

وضعیت I/O و تجهیزات

ورودی‌ها و خروجی‌های محلی و راه دور، مقیاس‌بندی، کیفیت کانال، خطاهای ماژول، وضعیت‌های فرمان‌داده‌شده و رفتار ایمن در هنگام خرابی را بررسی کنید. مطمئن شوید خروجی‌ها تا زمان برقرار شدن شرایط راه‌اندازی کارخانه غیرفعال باقی می‌مانند.

ارتباطات

تگ‌های تولیدشده و مصرف‌شده، دستورالعمل‌های MSG، خواندن و نوشتن HMI و SCADA، اتصالات OPC، داده‌های تاریخچه‌نگار، رک‌های راه دور، درایوها و دستگاه‌های شخص ثالث را آزمایش کنید. هم به‌روزرسانی عادی و هم رفتار زمان‌خروج یا بازیابی را بررسی کنید.

ترتیب اجرا، هشدارها و حرکت

اینترلاک‌های حیاتی، گذارهای توالی، هشدارهای اولین رخداد، فرمان‌های اپراتور و رفتار بازنشانی را اجرا و بررسی کنید. در صورت وجود حرکت، یادداشت‌های انتشار مربوط Rockwell و رویه ایمنی ماشین را دنبال کنید و سپس خانه‌یابی، محدودیت‌ها، هماهنگی و بازیابی خطا را در شرایط کنترل‌شده اعتبارسنجی کنید.

چرخه برق و آمادگی برای بازگشت

رفتار راه‌اندازی موردنظر را پس از یک چرخه برق کنترل‌شده، از جمله تنظیمات کارت SD یا حافظه غیرفرار، اثبات کنید. تأیید کنید دارایی‌های مستند بازگشت همچنان در دسترس هستند و نسخه پشتیبان نهایی با کنترلر در حال اجرا مطابقت دارد.

چگونه v19، v21 و v31 را ارزیابی کنیم

نسخه 19 زمانی که با یک پروژه تولیدی اعتبارسنجی‌شده و ایستگاه مهندسی پشتیبانی‌شده مطابقت دارد، هدفی منطقی برای بازیابی است. قدیمی بودن آن یک نگرانی چرخه عمر است، اما صرفاً قدیمی بودن ثابت نمی‌کند که مهاجرت اضطراری ایمن‌تر است.

نسخه 21 را می‌توان به‌عنوان گامی عمدی به نسل Studio 5000 ارزیابی کرد. مزایا و ناهنجاری‌های آن باید بر اساس یادداشت‌های انتشار رسمی و نحوه استفاده واقعی پروژه از اتصال HMI، مستندسازی، حرکت و قابلیت‌های ارتباطی بررسی شوند.

نسخه 31 یا هر خط مبنای جدیدتر، به تصمیمی برای نوسازی برنامه‌ریزی‌شده تعلق دارد. هدف را فقط پس از آن انتخاب کنید که داده‌های سازگاری فعلی، سخت‌افزار دقیق L73 و نرم‌افزارهای پیرامون آن را تأیید کنند. حتی اگر تبدیل با موفقیت انجام شود، جهش بزرگ‌تر بین نسخه‌ها دامنه بررسی را افزایش می‌دهد.

بنابراین تصمیم درست مشروط است، نه همگانی: اگر تنها هدف مجاز، بازیابی پس از توقف است، جایگزینی مشابه انجام دهید؛ و زمانی مهاجرت کنید که کارخانه بتواند وابستگی‌ها را تأیید کند، کل برنامه را بیازماید و امکان بازگشت داشته باشد. این رویکرد با میان‌افزار به‌عنوان یکی از لایه‌های کنترل‌شده یک سیستم تولیدی رفتار می‌کند، نه عددی که باید صرفاً افزایش یابد.