چرا RSLogix 500 هنگام ویرایش آنلاین کند می‌شود
گردش‌کار عیب‌یابیِ خطامحور برای ویرایش آنلاینِ کند در RSLogix 500 که پیش از تأیید تغییرات، رندرکردن در ایستگاه کاری، تأخیر ارتباطات، سازگاری پروژه، منابع کنترلر و ریسک فرایند را از یکدیگر جدا می‌کند.
کند بودن ویرایش آنلاین RSLogix 500 اغلب به قدیمی بودن پردازنده SLC نسبت داده می‌شود، اما تأخیر قابل مشاهده می‌تواند از چندین بخش ناشی شود: ایستگاه کاری مهندسی، ارتباطات RSLinx، شبکه مسیریابی‌شده یا پرنویز، ناسازگاری فایل پروژه، حافظه موجود کنترلر، یا کاری که پردازنده برای حفظ ویرایش آنلاین انجام می‌دهد. تعویض سخت‌افزار پیش از تفکیک این لایه‌ها ممکن است مشکل واقعی را بدون رسیدگی باقی بگذارد.
پیش از تغییر کنترلر یا شبکه، مشخص کنید تأخیر در کجا رخ می‌دهد—به‌روزرسانی صفحه، مرور، بارگذاری، راستی‌آزمایی، پذیرش، آزمایش یا سرهم‌بندی.
نشانه مشکل را دقیق تعریف کنید
«آنلاین کند» می‌تواند به خرابی‌های بسیار متفاوتی اشاره کند. ثبت کنید که تأخیر هنگام باز کردن جدول داده، پیمایش منطق نردبانی، جست‌وجوی پروژه، ویرایش یک ردیف، بررسی نحو، پذیرش ویرایش، آزمایش ویرایش‌ها، سرهم‌بندی ویرایش‌ها یا ذخیره فایل ظاهر می‌شود. توجه کنید که آیا پردازنده همچنان پاسخ‌گو می‌ماند و آیا زمان اسکن تولید، خطاهای ارتباطی یا به‌روزرسانی‌های HMI در همان لحظه تغییر می‌کنند یا نه.
به‌جای تکیه بر برداشت شخصی، چند اقدام تکرارپذیر را زمان‌گیری کنید. پیمایش آفلاین را با پیمایش آنلاین در همان پروژه مقایسه کنید. خواندن یک جدول داده ساده را با بارگذاری مقایسه کنید. اگر پروژه آفلاین از قبل کند است، پیش از کنترلر باید به ایستگاه کاری یا پایگاه داده پروژه توجه شود.
یک خط مبنای ایمن ایجاد کنید
برنامه در حال اجرا را بارگذاری و حفظ کنید، سپس آن را با فایل منبع موردنظر مقایسه کنید. کاتالوگ پردازنده، سری، میان‌افزار، اندازه حافظه، حالت کار، نسخه RSLogix 500، نسخه RSLinx، درایور ارتباطی، مسیر، سیستم‌عامل ایستگاه کاری و منابع آزاد دیسک و حافظه را ثبت کنید. دستگاه را در وضعیتی نگه دارید که بتوان ویرایش را با ایمنی لغو کرد.
راهنمای کاربر سخت‌افزار ماژولار SLC 500 شرکت Rockwell Automation مرجع اصلی سخت‌افزار برای آرایش‌های پشتیبانی‌شده پردازنده و ارتباطات است. راهنمای مرجع مجموعه دستورالعمل‌های SLC 500 رفتار دستورالعمل‌ها، فایل‌های داده، اطلاعات وضعیت و خطاهای محاسباتی را مستند می‌کند؛ این موارد ممکن است زمانی اهمیت پیدا کنند که ویرایش پیشنهادی، اجرا یا مصرف حافظه را تغییر دهد.
تأخیر ایستگاه کاری را از تأخیر ارتباطی جدا کنید
برنامه‌های نامرتبط را ببندید، افزونه‌های غیرضروری پروژه را غیرفعال کنید و هنگام بازتولید تأخیر، مصرف پردازنده، فشار حافظه، فعالیت دیسک و پاسخ‌گویی نمایشگر را بررسی کنید. پایگاه‌های داده بزرگ ارجاع متقابل، جدول‌های داده متعددِ باز، وضعیت متحرک منطق نردبانی، اسکن آنتی‌ویروس، گرافیک دسکتاپ از راه دور و تقریباً پر بودن درایو سیستم می‌توانند ویرایشگر را کند نشان دهند، بدون آنکه اسکن کنترلر تغییر کند.
پیش از تغییر نرم‌افزار امنیتی، از رویه تعمیر و نگهداری تأییدشده استفاده کنید. استثناگذاری تشخیصی یا آزمایش موقت آفلاین باید کنترل‌شده و قابل بازگردانی باشد. صرفاً برای پاسخ‌گوتر کردن یک ابزار قدیمی، حفاظت نقطه پایانی را به‌طور دائمی تضعیف نکنید.
سپس ارتباطات را آزمایش کنید. عیب‌یابی درایور RSLinx را بررسی کنید و هرگاه جایگزین ایمن و پشتیبانی‌شده‌ای وجود دارد، مسیر مستقیم محلی را با مسیر معمول مسیریابی‌شده مقایسه کنید. وجود تلاش‌های مجدد مکرر، ناپایداری در مشاهده گره‌ها، نشانی‌های تکراری، خطاهای دوطرفه یا سوئیچ در اترنت و خرابی‌های لایه فیزیکی در شبکه‌های سریال، DH-485 یا DH+ را بررسی کنید. مرورگری که در نهایت موفق می‌شود، دلیل سلامت مسیر برنامه‌نویسی نیست.
سازگاری پروژه و نشست را بررسی کنید
نشست آنلاین زمانی ایمن‌تر است که فایل بازشده مطمئناً با کنترلر در حال اجرا مطابقت داشته باشد. اگر نرم‌افزار مجبور باشد پروژه‌ای قدیمی یا از نظر ساختاری متفاوت را با کنترلر تطبیق دهد، پیمایش و راستی‌آزمایی ممکن است حتی با وجود اتصال پایدار گیج‌کننده شوند. در یک نسخه کنترل‌شده بارگذاری کنید، فایل‌ها را مقایسه کنید و پیش از ویرایش منطق تولید، اختلاف‌های توضیح‌داده‌نشده را برطرف کنید.
محدوده‌های ویرایش رهاشده را لغو کنید و مطمئن شوید ایستگاه کاری دیگری مالک نشست ویرایش نیست. هرگونه فورس، ویرایش آنلاین و منطق موقت تعمیر و نگهداری موجود را ثبت کنید. تغییرات حل‌نشده متعدد، خطر را افزایش می‌دهند و تشخیص اینکه تأخیر به ویرایش جدید مربوط است یا وضعیت موجود را دشوارتر می‌کنند.
هزینه‌ای را که متوجه کنترلر است درک کنید
ویرایش آنلاین با جایگزین کردن یک فایل آفلاین یکسان نیست. کنترلر و نرم‌افزار باید منطق اصلی و تغییریافته را در طول توالی ویرایش، تا زمان سرهم‌بندی یا لغو تغییر، حفظ کنند. بنابراین حافظه موجود و توانایی پردازنده اهمیت دارند. کنترلری که به محدودیت حافظه نزدیک است، ممکن است فضای کمتری برای ساختارهای موقتی موردنیاز یک ویرایش قابل‌توجه داشته باشد.
اولین ویرایش تشخیصی را کوچک نگه دارید. تغییر منطق را با فایل‌های داده جدید، جدول‌های داده گسترده، تغییرات ارتباطی و پاک‌سازی مستندات ترکیب نکنید. برخی تغییرات ساختاری به ویرایش آفلاین و دانلود نیاز دارند و با راهکار آنلاین قابل انجام نیستند. اگر تغییری در محدوده ویرایش آنلاین پشتیبانی‌شده این پلتفرم قابل بیان نیست، خاموشی مناسب را برنامه‌ریزی کنید.
زمان اسکن پردازنده و بیشینه اسکن، وضعیت ارتباطات، نشانگرهای خطای اصلی و فرعی و زمان‌بندی فرایند را پیش، حین و پس از ویرایش پایش کنید. پاسخ سریع ویرایشگر، ویرایشی را که نوسان بیش از حد زمان اسکن ایجاد می‌کند یا یک توالی حساس به زمان را تغییر می‌دهد، توجیه نمی‌کند.
از یک توالی ویرایش کنترل‌شده استفاده کنید
ابتدا کوچک‌ترین تغییری را ایجاد کنید که مسیر ویرایش را بدون تأثیر بر تجهیزات اثبات کند. آن را راستی‌آزمایی و سپس بپذیرید و طبق رویه سایت، کنترلر و برنامه را زیر نظر بگیرید. ویرایش را فقط زمانی آزمایش کنید که فرایند در وضعیت ایمن تعریف‌شده باشد. پیش از سرهم‌بندی، منطق موردنظر و همه خروجی‌های تحت‌تأثیر را تأیید کنید.
پس از سرهم‌بندی، دوباره مقایسه یا بارگذاری کنید و فایل منبع حاصل را همراه با زمان، دلیل تغییر، تأییدکننده و مرجع بازگشت ذخیره کنید. اگر عملکرد در مرحله مشخصی افت کرد، متوقف شوید و شواهد را حفظ کنید. پذیرفتن مکرر ویرایش‌های بزرگ‌تر، روش معتبری برای تشخیص تأخیر ناشناخته نیست.
الگوهای رایج را تفسیر کنید
اگر پیمایش و جست‌وجوهای آفلاین کند هستند اما به‌روزرسانی داده‌های کنترلر عادی است، روی ایستگاه کاری و پایگاه داده پروژه تمرکز کنید. اگر همه خواندن‌های آنلاین مکث می‌کنند و تلاش‌های مجدد درایور افزایش می‌یابد، مسیر ارتباطی را بررسی کنید. اگر ویرایش‌های کوچک کار می‌کنند اما ویرایش‌های بزرگ‌تر شکست می‌خورند یا متوقف می‌شوند، حافظه، ساختار پروژه و محدودیت‌های ویرایش پشتیبانی‌شده را بررسی کنید. اگر ویرایشگر پاسخ‌گو می‌ماند اما زمان اسکن فرایند افزایش می‌یابد، خود تغییر منطق را بررسی کنید.
اگر کندی فقط پس از چند ساعت ظاهر می‌شود، نشست مهندسی را به‌صورت کنترل‌شده راه‌اندازی مجدد کنید و به‌جای راه‌اندازی مجدد کنترلر، رشد مصرف منابع را بررسی کنید. اگر ایستگاه کاری دیگری از همان مسیر شبکه عملکرد عادی دارد، پیش از معیوب اعلام کردن PLC، نسخه‌های نرم‌افزار، درایورها، کنترل‌های امنیتی و فایل‌های پروژه را مقایسه کنید.
زمان توقف ویرایش آنلاین را تشخیص دهید
زمانی متوقف شوید که پروژه در حال اجرا را نمی‌توان با اطمینان تطبیق داد، ارتباطات ناپایدار هستند، کنترلر به محدودیت منابع نزدیک است، تغییر به اصلاحات ساختاری نیاز دارد یا فرایند توان تحمل آزمایش را ندارد. به‌جای تحمیل تعمیر در زمان اجرا، یک راستی‌آزمایی آفلاین و دانلود کنترل‌شده را همراه با نسخه‌های پشتیبان و امکان بازگشت برنامه‌ریزی کنید.
پلتفرم‌های قدیمی و گزینه‌های مهاجرت را می‌توان در مجموعه Allen-Bradley و مجموعه سیستم‌های PLC و PAC بررسی کرد. مهاجرت باید بر اساس شواهد مربوط به ریسک چرخه عمر، عملکرد، قطعات یدکی و بازیابی انجام شود، نه بر مبنای یک نشست ویرایش کند.
دیدگاه مهندسی
پرسش مفید این نیست که «چرا RSLogix کند است؟» بلکه این است که «کدام مرز، در کدام اقدام تکرارپذیر و تحت چه شرایطی کند می‌شود و چه شواهدی همراه با آن تغییر می‌کند؟» وقتی اثرات ایستگاه کاری، ارتباطات، پروژه، کنترلر و فرایند جداگانه اندازه‌گیری شوند، تیم می‌تواند محدودیت واقعی را برطرف کند و هم‌زمان از دستگاه در حال اجرا محافظت نماید.