دليل أسلوب ST: التسمية والتعليقات والثوابت وإدارة النسخ

من يقرأ كودك

ليس المترجم. الذي يقرأه هو مهندس آخر في الثالثة فجراً والخط متوقف، وقد يكون أنت بعد سنتين. كل ما في هذا الدرس يخدم تلك اللحظة.

التسمية: بادئة تقول النوع

العرف المعروف بأسلوب PLCopen يضع بادئة قصيرة تدل على النوع والدور:

لا يهم أي عرف تختار، يهم أن يكون واحداً في المشروع كله وموثّقاً في صفحة واحدة.

التسمية الأهم: أسماء الحلقات من المخطط

في مصنع حقيقي الأسماء ليست من عندك، بل من P&ID. مستوى الخزان 101 اسمه LT-101 في المخطط وفي الكابل وفي شاشة التحكم، فليكن في الكود LT_101 أو LT101_PV. الاصطلاح الشائع (ISA-5.1): حرف أول للمقيس وحروف بعده للوظيفة:

فائدة هذا فورية: الفني يقرأ الإنذار على الشاشة، يجد نفس الوسم على الحقل، ويفتح نفس الاسم في الكود. لا ترجمة ولا تخمين.

التعليقات: اشرح السبب لا الفعل

التعليق الذي يكرر الكود عبء يجب تحديثه مرتين:

(* سيئ: يضبط المضخة على TRUE *)
Pump := TRUE;

(* جيد: الشركة المصنّعة تطلب 30 ثانية تبريد بين تشغيلين
   لحماية ملف البادئ. مرجع: دليل P-101 صفحة 14 *)
tRestartDelay := T#30s;

علّق على: سبب الرقم، ومرجع المستند، والقرار الذي بدا غريباً، والعطل الذي دفعك لكتابة هذا السطر. ولا تعلّق على ما يقوله الكود بنفسه.

اجعل الـ POU قصيراً

إذا احتجت التمرير لرؤية بداية IF، صار الكود طويلاً. مؤشرات عملية:

• POU يُقرأ في شاشة أو شاشتين.
• مهمة واحدة واضحة لكل POU: FB_Motor تدير محركاً، لا تدير محركاً وتحسب التقارير.
• المنطق المتكرر في كتلة وظيفية تُنشأ منها نسخ، بدل نسخ ولصق.
• القرارات في مكان واحد: لا تضبط Pump في ثلاثة مواضع.

لا أرقام سحرية

الرقم 85.0 وسط الكود لا يخبر أحداً بشيء، وتغييره يعني البحث في المشروع كله:

VAR CONSTANT
  LEVEL_FILL_SP   : REAL := 85.0;   (* % نقطة توقف الملء *)
  LEVEL_HI_ALARM  : REAL := 90.0;   (* % إنذار مستوى عالٍ *)
  FILL_TIMEOUT    : TIME := T#60s;  (* أقصى زمن ملء قبل إعلان عطل *)
END_VAR

IF rLevelF >= LEVEL_FILL_SP THEN
  iStep := 2;
END_IF

ما يتغير أثناء التشغيل يصبح نقطة ضبط (Setpoint) في متغير RETAIN يُعدّلها المشغل من الشاشة. وما لا يتغير يصبح CONSTANT. الرقم المنثور في الكود ليس واحداً منهما.

إدارة النسخ لكود المتحكم

العرف القديم Station_v3_final_FINAL.zip سبب حوادث حقيقية. ما يعمل عملياً:

• مستودع Git للمشروع، ونصوص ST كملفات قابلة للمقارنة. سيمنس وCODESYS وTwinCAT كلها تصدّر وتستورد الوحدات نصاً.
• رسالة التزام تقول لماذا: «رفع مهلة الملء إلى 90 ثانية بعد تركيب المضخة الأصغر».
• وسم (Tag) لكل نسخة حُمّلت فعلاً إلى المتحكم، مع تاريخ وموقع: هذا ما ستحتاجه عند التحقيق في حادث.
• نسخة احتياطية من المشروع الكامل لا من النصوص فقط: الأجهزة والشبكة وإعدادات الوحدات.
• سجل تغييرات مطبوع في اللوحة: من حمّل، وماذا، ومتى.

كلمة في OOP داخل IEC 61131-3

الإصدار الثالث من المعيار أضاف إلى الكتلة الوظيفية: METHOD و PROPERTY و INTERFACE و EXTENDS و IMPLEMENTS. مدعومة جيداً في CODESYS وTwinCAT، وجزئياً أو كلياً غير مدعومة في منصات أخرى.

متى تستحق؟

• تستحق عندما تبني مكتبة لعشرين آلة متشابهة: FB_ValveBase ومنها FB_ValveDigital و FB_ValveAnalog، مع I_Device تعطي Start و Stop و GetState لكل جهاز، فتكتب منطق المحطة مرة واحدة.
• لا تستحق في محطة فيها مضختان وصمام. طبقة التجريد ستكلّفك وقت فهم أكثر مما توفّره، ولن يقرأها فني الصيانة.

والقاعدة التي لا تُخالف: إذا كان الكود سيُسلَّم لفريق صيانة لا يعرف البرمجة بالكائنات، فأنت تكتب مشكلة مستقبلية لا حلاً هندسياً. الوضوح يغلب الأناقة في كل مرة.