الأخطاء البرمجية المشهورة PLC Programming Common Mistakes

0

 

الأخطاء البرمجية المشهورة PLC Programming Common Mistakes

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

ومن هنا يظهر موضوع في غاية الأهمية وهو:

·        الأخطاء البرمجية المشهورة PLC Programming Common Mistakes وهذا هو موضوع درسنا اليوم.

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

PLC Common Programming mistakes

1.    عدم الالتزام بهيكله منظمة لبرنامجك

 

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

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

وهذا يزيد من أهمية تعلم طرق ال Software Design ومن أشهرها هي طريقة ال Top Down Design.

وفي هذه الطريقة يتم تقسيم الماكينة الي مجموعة من الأجزاء الرئيسية ثم يتم التعامل مع كل جزء علي حده ويجب أيضاً عمل جزء خاص بأنظمة الأمان والانذار Alarms and Notifications وسوف يكون موضوع درس كامل نظراً لأهميته.

كما أن عدم الالتزام بتنظيم البرنامج وكتابته بالكامل في سطور برمجية متتابعة (Linear Programming) ربما يعتقد أنه أسهل وأسرع ولكن في الحقيقة فهو علي العكس تماماً ويظهر هذا بشدة كلما كبرت الماكينة وبالتالي البرنامج ، وذلك بسبب مرحلة ال Debugging وهيا مرحلة تصحيح الأخطاء البرمجية والتي تظهر بكثرة عند عمل Commissioning وتظهر صعوبتها لدرجة ممكن أن تعيد كتابة أجزاء كبيرة من الكود بالكامل.

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

-         يجب عليك تنظيم البرنامج عن طريق تقسيمه الي أجزاء وعمل Subroutine لكل جزء علي حده.

-         عمل Function block تقوم بكل العمليات المتشابهة لأكثر من حمل فلا تضطر الي كتابة كود جديد عند القيام بهذه العملية مرة أخري فقط تقوم بتغيير المدخلات والمخرجات لهذه الدالة.

-         عمل mapping للمدخلات Inputs علي ذاكرة داخلية.

-         تنظيم استخدامك للذاكرة وسوف يفيدك كثيراً برنامج Microsoft Excel في تحقيق ذلك.

-         لا تنسي Alarms and Notifications.


وهذا مثال لكيفية تنظيم ماكينة صغيرة:






2.    عدم كتابة التعليقات خلال البرمجة

وهذا أيضاً من المواضيع الهامة التي يجب عليك الالتزام بها عند كتابة أي برنامج وهو وضع تعليقات تصف كل Rung/Network حتي يزيد من سهولة البرنامج عليك مستقبلاً أو علي الشخص الذي سوف يقوم بفتحه اذا حدث خطأ معين في الماكينة.

3.    عدم ترك الجهاز عند انعدام التركيز تماما.

اذا شعرت بالإرهاق وعدم القدرة علي التركيز ، عليك أخذ استراحة (هذا ضروري جدا حتي لا تقوم بأخطاء أكبر).

4.    الكتابة علي Single Coil في أكثر من مكان.

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

5.    عدم عمل أكثر من Version بعد الإضافات.

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

6.    نسيان حفظ اخر تعديل بعد تصحيح الأخطاء وتشغيل الماكينة ، ثم تمييزه باسم معروف.

بعد عمل أكثر من Version لا تنسي أن تميز اخر نسخه في أقرب وقت ممكن حتي لا تنساها ومفترض أن تكون هيا صاحبة أعلي Version

7.    عدم عمل نسخ احتياطية لبرامجك وكذلك كلمات السر التي وضعتها في بعض الماكينات.

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

8.    عدم استخدام الماركرات (PLC Internal Bits) أو الإفراط في استخدامها.

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

9.    عدم فهم ال PLC Scan Cycle بصورة عميقة.

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

10. عمل واحده فقط من Set/Reset أو Latch/Unlatch.

فقط لا تنسي عند استخدام هذا النوع من ال Output Commands أن تراجع هذا.

11.       عدم مراجعة توزيع الذاكرة الداخلية لل PLC المستخدم.

يجب عليك مراجعة المانوال الخاص بالجهاز لمعرفة أماكن التايمرات وال base units الخاصة بها ومعرفة أماكن ال Retentive Memory وهل هي جاهزة أم يتم وضعها عن طريق المبرمج ، فقط أقرأ هذه المعلومات قبل البدء حتي لا تضطر الي العودة الي التعديل مرة أخري ولا تستخدم Retentive Memory بدون داعي.

 

12.    لا تفعل شيئاً لمجرد أنك تستطيع فعله.

من فضلك اجعلك برنامجك بسيطاً قدر المستطاع فالبرنامج الجيد يجب أن يكون Simple, Readable, and Reusable.

 

 

أخيراً وليس أخراً وهذه نصيحة وليس خطأ وهو استخدام الأوامر والماركرات الخاصة بنوع معين من ال PLC في حين إمكانية إنجازها عن طريق كود بسيط مثل التعامل مع الإشارات الانالوج واستخدام ال Pulse Generator Markers الخ.

فقط قم بمثل هذه الأمور يدوياً حتي تستطيع إنجازها باستخدام أنواع أخري من ال PLC.

 

أرجو أن أكون قد أفدتكم ،

فضلاً وليس أمرا مشاركة الموضوع ان وجدته مفيداً

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


إرسال تعليق

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