خطأ مصيدة تجاوز السعة 0020 في SLC 500: إصلاح تثبيت S:5/0
يعني الخطأ الجسيم 0020 في SLC 500 أن مصيدة تجاوز السعة S:5/0 قد ثُبّتت بعد عملية حسابية غير صحيحة. يمكن أن يساعد مسحها باستخدام OTU في إبقاء وحدة المعالجة ال...
كل بضعة أيام يتحول جهاز SLC إلى حالة عطل. الخطأ الجسيم 0020. يهزّ المشغلون أكتافهم، ويمسح قسم الصيانة الخطأ، ويستأنف الإنتاج—حتى تتكرر الغلطة الحسابية نفسها في الوردية الليلية. هذا النمط هو بت فخّ تجاوز السعة S:5/0 الذي ينفذ تمامًا ما صمّمته Rockwell لأجله: تثبيت الحالة حتى لا تتظاهر بأن الحساب الخاطئ لم يحدث قط.
في وحدة 5/04 مثل 1747-L524، يعني الخطأ 0020 أن تعليمة ما أنتجت نتيجة خارج نطاق الأعداد الصحيحة المسموح به. تعمل الحسابات الموقعة ذات 16 بت ضمن المجال من −32768 إلى +32767. إذا تجاوزت هذا الحد باستخدام ADD أو MUL، أو أجريت قسمة على صفر، أو تجاوزت في FIFO/LIFO سعة المخزن المؤقت، أو طبّقت NEG على −32768، فسيضبط المعالج S:5/0، ثم يظل في حالة عطل حتى يلغي شيء ما تثبيت هذا البت. تصف الكتيبات من عائلة المنشورين 1747-UM011 / 1747-UM001 هذا الفخ؛ أما أرضية المصنع فلا ترى سوى وحدة CPU متوقفة.
لا تزال معالجات SLC القديمة تشغّل كثيرًا من الآلات المنفصلة. وغالبًا ما تكون فخاخ تجاوز السعة ناتجة عن حسابات التطبيق، لا عن اقتراب اللوحة الخلفية من التلف.
تعليمة OTU التي توقف النزيف
تضع معظم عمليات الاستعادة السريعة تعليمة OTU على S:5/0 حتى تستمر دورة المسح بعد الفخ. لكن موضعها هو جوهر المسألة. ضعها في آخر شبكة في LAD 2—وهو الملف الذي يضم استدعاءات JSR—حتى ينتهي كل روتين فرعي قبل مسح حالة التثبيت. بهذه الطريقة يُكتشف تجاوز السعة أثناء دورة المسح، ثم يُمسح مرة واحدة قبل الخمول.
LAD 2 — الشبكة الأخيرة S:5/0 ----] [----(OTU)----
إذا وضعت تعليمة OTU نفسها داخل الروتين الفرعي الذي يتسبب في تجاوز السعة، فأنت تبتكر نمط عطل جديدًا: تُمسح الحالة مبكرًا، ثم يحدث تجاوز آخر لاحقًا في دورة المسح نفسها، فيعود العطل فورًا. أو قد تعمل تعليمة OTU في مسار لا يصل إلى الحساب الخاطئ في دورة المسح تلك، فتظن أنك «أصلحت» المشكلة، بينما لا تزال الشبكة الحقيقية تتسبب في العطل مرتين أسبوعيًا.
| العنصر | الاستخدام |
|---|---|
| البت |
S:5/0 فخ تجاوز السعة (مثبّت)
|
| التعليمة | OTU |
| الملف | LAD 2 (الرئيسي) |
| الموضع | بعد كل JSR، في الشبكة الأخيرة |
نزّل البرنامج، وحوّل المفتاح إلى RUN، وراقب بقاء S:5/0 في حالة عدم التفعيل عبر بضع ورديات. إذا ظل هادئًا، فقد اشتريت وقتًا—وليس إغلاقًا للسبب الجذري.
اعثر على الحساب الذي تسبب فعلًا في تجاوز السعة
تعامل مع OTU كحزام أمان. ثم ابدأ البحث:
- أي تغيير حديث يتعامل مع الأعداد الصحيحة—عدادات الدُفعات، أو إشارات تماثلية مُحوّلة إلى ملفات N، أو تعليمة MUL «مؤقتة» لتحويل الوحدات
- مواضع ADD / SUB / MUL / DIV / DDV التي لا تتضمن محددات للنطاق
- المواضع التي كان ينبغي أن تستخدم LADD / LMUL (32 بت) بعد خروج القيم عن نطاق 16 بت
- استخدام NEG على قيمة يمكن أن تكون −32768
- طول FIFO/LIFO مقارنة بسعة المخزن المؤقت التي حجزتها فعليًا
ومن بتات الحالة ذات الصلة التي يجدر معرفتها أثناء تصحيح الأخطاء: S:5/1 لتمكين فخ تجاوز السعة، وS:1/0 للمسح الأول، وS:2/0 لعطل المعالج. لا تمسح الفخاخ عشوائيًا أثناء التعديلات عبر الإنترنت من دون معرفة الشبكة التي تتسبب في المشكلة.
فحص واقع العتاد
تقترب وحدات CPU من الفئة 1747-L524، وهي من طراز 5/04، من نهاية عمرها التشغيلي تمامًا. إذا كان الهيكل سيبقى، فاحتفظ بوحدة 5/04 احتياطية معروفة الصلاحية على الرف—فالمصانع التي لا تزال تشتري من هذه العائلة غالبًا ما تختار وحدات مثل 1747-L542. وقد تنتقل الآلات الأصغر أحيانًا بشكل جانبي إلى 5/03 مثل 1747-L532، لكن هذا قرار مشروع، وليس إصلاحًا لتجاوز السعة. وعلى المدى الأطول، تنقل معظم المواقع العملية إلى CompactLogix أو ControlLogix وتتخلص من فخاخ الحسابات ذات 16 بت بفضل المنصة الجديدة. ولا تزال استراتيجية قطع الغيار لأساطيل Logix المختلطة مرتبطة بكيفية تخزينك لأنظمة PLC وPAC.
وحتى يتم تنفيذ هذه الهجرة، يبقى الانضباط بسيطًا: ضع OTU في نهاية LAD 2، ثم أثبت أي تعليمة ADD/MUL تتجاوز نطاقها.
عن المؤلف
Mark Townsend | مهندس أتمتة أول – أنظمة Allen-Bradley
Mark Townsend مهندس أتمتة أول لديه أكثر من 18 عامًا من الخبرة في منصات Allen-Bradley، تشمل ControlLogix وCompactLogix وSLC-500 القديمة. ويتركز عمله اليومي على منطق RSLogix / Studio 5000 وتجهيز واجهات HMI في FactoryTalk View ضمن أساطيل قديمة ومختلطة.