PLC Clean Code - Part 3

0

 
الكود الجيد والكود السيء في برمجة ال PLC- الجزء الثالث
Clean code Vs. Dirty Code in PLC Programming – Part Three

في الموضوع السابق من هذه السلسلة قمت بالتحدث عن قواعد مهمة في تسمية المتغيرات والثوابت ، وكذلك أيضاً ما هي الطريقة الصحيحة لكتابة التعليقات عند برمجة الحاكمات المنطقية PLCs ، اذا كنت لم تقرأ الموضوعين السابقين يمكنك العودة اليهم من هنا:

الدرس الأول ، الدرس الثاني

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

 

PLC Clean Code

محتويات المقال:

  1. مقدمة
  2. قواعد برمجية مهمة
  3. الخاتمة.

مقدمة

على الرغم من وجود إرشادات لكتابة الأكواد للعديد من لغات البرمجة ، إلا أنها غير موجودة تقريبًا في مجال التحكم الصناعي المهم ، على سبيل المثال لغات البرمجة المنصوص عليها في معيار IEC61131-3 ومع ذلك فإن تنظيم البرامج في البيئات الصناعية يصبح أكثر أهمية مع ازدياد حجم المشاريع، وتزداد تكاليف الأخطاء البرمجية.

البرمجيات في الوقت الحاضر تمتص جزء كبير من التكاليف الأولية للمشروع ومع ذلك تكثر مشكلاتها وتحتاج للصيانة بشكل مستمر.

ولهذا فمن أجل التعامل مع تعقيد البرامج الأكبر يحتاج المبرمج إلى تطوير برمجيات تدعم نهج منظم ، وأيضا نحن بحاجة إلى زيادة الكفاءة في كتابة الأكواد البرمجية الخاصة بنا عبر إعادة استخدام الوظائف المحددة مسبقًا وللمساعدة في فهم البرنامج بشكل أفضل على مدار دورة حياة البرنامج بعد ذلك.

 

قواعد برمجية مهمة

هناك العديد من القواعد والارشادات الواجب الحفاظ عليها ، عند برمجة المتحكم المنطقي Programmable Logical Controller ، وكالعادة سوف أقوم بسرد هذه التعليمات علي هيئة نقاط مع إعطاء شرح مختصر لكل نقطة.

القاعدة الأولي: تجنب ترك الكود غير المستخدم (الكود الميت Dead Code )

بعض الأحيان سوف تقوم بكتابة بعض الأوامر البرمجية ثم تظهر لك بعض الأخطاء أثناء مرحلة الDebugging ، وهكذا سوف تقوم بتعديل برنامجك تاركاً بعض السطور البرمجية غير مستخدمة ، فما عليك أن تفعله في هذه الحالة هو تحويل هذه الأكواد الي تعليقات ان كنت تستخدم لغة نصية ، أو إضافة شرط لا يمكن حدوثه اذا كنت تستخدم لغة رسومية مثل إضافة ماركر خارج الكود اذا كنت تستخدم اللادر دياجرام ، وهذا حتي تستقر علي برنامج يعمل بشكل صحيح ،

بعد أن تصل الي نسخة صحيحة من البرنامج عليك الغاء كل الأكواد غير المستخدمة (Dead Code) ، لأن هذه الأكواد تؤثر علي سهولة قراءة البرنامج ، وتجعله أكثر عرضة للأخطاء بعد التشغيل ، كما أنه من المهم أن تراعي استخدام أقل حجم من الذاكرة الخاصة بجهاز الPLC ، فأنت تريد أعلي كفاءة ممكنة للجهاز ، واستخدام حجم ذاكرة أقل أحد العوامل المهمة التي تؤثر علي الكفاءة والأداء.

فاذ تركت كود ميت يجب أن تترك تعليقاً يحدد ويشرح بشكل صحيح سبب ترك هذا الجزء.

 

القاعدة الثانية: يجب ألا تتداخل أماكن التعيين في الذاكرة

عند تعيين موقع ذاكرة لكائن ما ، يجب على المبرمج أن يحرص علي أن ينظم الذاكرة المستخدمة في البرنامج فلا يقم بتخصيص الذاكرة في مكان مخصص بالفعل لاستخدام آخر.

معظم الCompilers سوف تمنعك من تعيين أكثر من متغير علي مكان واحد في الذاكرة بطريقة مباشرة ، ولكن سوف تظهر المشكلة في حالتين ، فالحالة الأولي هي استخدام الجزء الثاني من الريجستر فكما نعلم أن الريجستر عبارة عن 2 بايت ، 16 بت ، فاذا قكت بكتابة شيء ما علي البايت الثاني من ريجستر معين ، فلا مانع في ذلك لدي الCompiler ، مما قد يؤدي الي خلل في الأداء الوظيفي للبرنامج الخاص بك.

لحل هذه المشكلة يمكنك استخدام برنامج Microsoft Excel بالتوازي أثناء عمل البرنامج لتنظيم الذاكرة الخاصة بك ، ثم استخدامها في برنامجك دون قلق ، هذا أو الحرص والتركيز علي عدم تداخل الذاكرة علي بعضها ، افعل الأسهل لك.

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

لذلك وبشكل عام يجب عليك تنظيم وترشيد استخدامك للذاكرة لتقليل الضغط علي المعالج والرام ميموري وبذلك تحصل علي كفاءة أعلي للجهاز وللبرنامج.



القاعدة الثالثة: يجب أن تكون التطبيقات مصممة بشكل جيد

يجب تصميم جميع التطبيقات بشكل جيد ، أن تقوم بذلك قبل البدء في مرحلة البرمجة نفسها ، فاذا قمت بعمل تصميم جيد للبرنامج فسوف يستغرق منك بعض الوقت الذي تعتقد أنه وقت زائد ولكن في الحقيقة فان هذا الوقت سوف يقلل بشكل كبير جدا من الوقت المستغرق في مرحلة البرمجة ومرحلة التجارب.

أيضا يجب عليك الاستفادة من الأشياء المدعومة في جهاز الPLC اذا وجدت مثل استخدم المصفوفات (Arrays) لتجميع المتغيرات ذات الصلة من نفس نوع البيانات Data Type ، الاستفادة من الهياكل (ٍStructs) لتجميع المتغيرات ذات الصلة من البيانات المختلفة ، استفد من الFunctions & Function Blocks مما يقلل من تعقيد البرنامج ، ويعطي لك سهولة إعادة الاستخدام Reusable Code.

اعط للمشغل ما يحتاجه وليس ما يريده

يجب أن تراعي عدم اخراج أي وظائف حرجة في عمل البرنامج سواء علي الشاشة أو علي ازرار ، ولا يجب أن تعطي المشغل اختيارات أكثر من اللازم ، فبقدر الإمكان اجعل الوظائف الحرجة تعتمد علي الجهاز وليس علي العامل البشري ، حتي وان طلب منك المشغل ذلك ، ضع بعين الاعتبار مدي الأهمية بالنسبة لمتطلبات التشغيل والإنتاج أولاً وليس رغبة المشغل.

يجب ألا تكون مقارنة الأرقام الحقيقية Real مساواة أو عدم مساواة

المقارنة بين متغيرات من نوع Floating يجب أن تستخدم فقط العوامل التالية:

أصغر من (<) ، أصغر من أو يساوي (<=) ، أكبر من (>) ، أكبر من أو يساوي (> =).

حيث يتطلب عامل المساواة دقة عالية جداً وقد لا تحصل عليها أبداً فاذا قمت بعمل مقارنة ضغط معين وتحديد المقارنة عند المساواة ، فقد تحدث هذه المساواه بسرعه عالية للغاية ، ولا يتحقق الشرط أبدا مما يؤدي الي خلل في وظائف البرنامج ، ولكن عليك استخدام أكبر/أصغر من أو يساوي حسب المطلوب.

 

يجب ألا تكون مقارنة الوقت والقيم التماثلية Analog مساواة أو عدم المساواة

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

الحد من تعقيد البرنامج

هناك طرق مختلفة لقياس مدى تعقيد الكود ولكن الطريقة الابسط هي باختصار عدد أسطر الكود لكل POU آخر يمكن العثور على مقاييس مثل McCabe-metric و Prater-metric من خلال البحث علي الانترنت وكل مقياس له مميزاته وعيوبه ؛ ولكن أفضل استخدام طريقة عدد الاسطر لسهولتها ، فلا يجب ل POU أن يتجاوز 25 سطراً ، فان كان ضروريا قم بتقسيمه مره أخري الي جزئين فالكود المعقد وهو مصدر دائما للأخطاء ،ولا أحد يريد ذلك.

 

يجب كتابة المخرجات الحقيقة مرة واحدة لكل Scan Cycle

وهذه من الممارسات المهمة ، حيث أن الكتابة علي مخرج معين أكثر من مره في الScan cycle يعطي نتائج خاطئة ، الا اذا قمت به بشكل مقصود ففي بعض الأحيان يكون من الضروري الكتابة علي المخرج من أكثر من موقع ، ولكن ذلك يجب أن يتم بحذر.

 

قم بتهيئة المتغيرات قبل استخدامها Initialization

يجب تهيئة المتغير قبل أن يقرأه جزء آخر من الكود ، فوفقًا للمواصفة IEC 61131-3 ، يجب تحتوي جميع المتغيرات على قيم ابتدائية افتراضية Initial Values. فإذا كانت منصة البرمجة لا تدعم النظام هذه الميزة  فيجب على المبرمج عمل ذلك بطريقة يدوية (إضافة جزء كود خاص بالقيم الأولية للمتغيرات).

تجنب الأخطاء الرياضية Mathematical Errors

والمقصود هنا أنه يجب عليك مراعاة القيم التي قد تنتج عن المعادلات الحسابية الخاصة بك ، وربطها بحجم ذاكرة مناسب ، وعدم تراكم الأرقام  Overflowوهذا أيضا مرتبطه بالقاعدة السابقة حيث يجب تهيئة المتغيرات بطريقة أو بأخري في البرنامج الخاص بك.

 

الخاتمة

اعمَل بِعِلمي وَإِن قَصَّرتُ في عَمَلي        يَنفَعكَ عِلمي وَلا يَضرُركَ تَقصيري

الي هنا نكون قد انتهينا من هذا الدرس والي لقاء اخر في درس جديد في سلسلة الكود النظيف ، أتمني أن أكون قد وفقت في عرض المعلومة ،

شاركوا المحتوي مع الاخرين لتعم الفائدة

أسألكم الدعاء

 

يرجي ترك تعليق للإبلاغ عن رابط لا يعمل

 

 

Tags

إرسال تعليق

0 تعليقات
إرسال تعليق (0)
To Top