زبان لدر PLC و عیب‌یابی سریع در اتوماسیون صنعتی

لدر فقط چند رَنگ ساده نیست. اگر درست نوشته شود، سریع‌ترین مسیر برای عیب‌یابی، تحویل پایدار و نگهداری کم‌ریسک را در کارخانه می‌دهد. این مقاله کاملاً پروژه‌محور است: الگوی Start/Stop، اینترلاک، تایمر/کانتر، و دو سناریوی واقعی توقف خط با مسیر تشخیص مرحله‌ای.

اگر یک‌بار وسط شیفت، خط تولید خوابیده باشد، می‌دانید «کد خوب PLC» یعنی چه. آن لحظه، کسی دنبال زیبایی معماری نیست. همه دنبال جواب‌اند:

• چرا Start نمی‌شود؟

• کدام شرط اجازه نمی‌دهد؟

• کدام خطا لچ شده؟

• آیا مشکل از سنسور است یا منطق؟

لدر اگر درست نوشته شده باشد، همین‌جا شما را نجات می‌دهد.

زبان برنامه نویسی لدر چیست؟

لدر یک زبان استاندارد PLC است که منطق را شبیه مدارهای فرمان نشان می‌دهد:

• کنتاکت‌ها = شرط‌ها

• کویل‌ها = خروجی/نتیجه

• رَنگ‌ها (Rungs) = جمله‌های منطقی

هر رَنگ می‌گوید:

• «اگر این‌ها برقرار بود → این خروجی را فعال کن.»

چرا لدر هنوز در صنعت محبوب است؟

سه دلیل کاملاً زمینی دارد:

1. زبان مشترک تعمیرات و برق
   تعمیرات با مدار فرمان راحت است. لدر همان زبان است.

2. عیب‌یابی آنلاین سریع
   در Online Monitoring می‌بینید کدام شرط false است و منطق کجا قطع می‌شود.

3. برای منطق‌های گسسته عالی است
   Start/Stop، interlock، permissive، trip، alarm latch… دقیقاً جنس لدر است.

یک قانون طلایی: هر رَنگ فقط «یک هدف»

بیشتر پروژه‌هایی که عیب‌یابی‌شان سخت است، یک ویژگی مشترک دارند: رَنگ‌های شلوغ و چندمنظوره.

اگر می‌خواهید لدر قابل عیب‌یابی باشد، این چهار اصل را جدی بگیرید:

• رَنگ تک‌هدفه

• نام‌گذاری معنی‌دار

• تفکیک permissive / trip

• Diagnostic قابل نمایش برای اپراتور

سناریوی واقعی ۱: Conveyor استارت نمی‌شود

اپراتور Start می‌زند.
هیچ اتفاقی نمی‌افتد.
خط خوابیده. نگاه‌ها به شماست.

اینجا بهترین کار این است که «حدس» نزنید. مسیر تشخیص را مرحله‌ای بروید.

قدم ۱) آیا RunCmd واقعاً true می‌شود؟

اولین سؤال: خروجی/کویل RunCmd فعال می‌شود یا نه؟

• اگر false است: مشکل در شرط‌ها/منطق است.

• اگر true است ولی تجهیز کار نمی‌کند: مشکل در خروجی/برق/تجهیز است.

قدم ۲) کدام شرط رَنگ را قطع کرده؟

Online Monitoring را نگاه کنید. معمولاً یکی از این‌ها false است:

• Safety_OK

• NoFault

• DriveReady

• GuardClosed

قدم ۳) اگر NoFault false است، Trip را بررسی کنید

Trip از کجا آمده؟

• DriveFault؟

• Overload؟

• EStop؟

اگر Trip لچ شده باشد، حتی با برطرف شدن علت، تا Reset منطقی انجام نشود Start نمی‌کند.

قدم ۴) اگر RunCmd true است، Feedback را چک کنید

RunCmd true است اما feedback نمی‌آید؟

• خروجی به کنتاکتور رسیده؟

• درایو ready است؟

• مکانیک گیر نکرده؟

• تایم‌اوت feedback باعث trip نشده؟

قدم ۵) بعد از رفع مشکل، یک اصلاح پیشگیرانه

اینجا تفاوت حرفه‌ای بودن مشخص می‌شود:

• یک پیام HMI اضافه کنید: «عدم اجازه استارت: DriveReady=false»

• یا یک Diagnostic Bit بسازید که “علت اصلی” را واضح نشان دهد

این کار دفعه بعد، زمان توقف خط را نصف می‌کند.

سناریوی واقعی ۲: پمپ استارت می‌خورد ولی فشار بالا نمی‌رود (Timeout)

این سناریو را احتمالاً در هر کارخانه‌ای می‌شود دید.

پمپ را Start می‌کنید.
فرمان Run فعال است.
اما Pressure switch یا Transmitter فشار مورد انتظار را نشان نمی‌دهد.
بعد از چند ثانیه سیستم trip می‌دهد.

اینجا الگوی درست معمولاً یک چیز است:

• Start + Feedback + Timeout

الگوی صنعتی: Start + Feedback + Timeout

لایه ۱) permissive قبل از Start

نمونه‌ها:

• سطح مخزن OK

• شیر خروجی باز

• برق/درایو OK

• خطا وجود ندارد

لایه ۲) فرمان Run و نگه داشتن آن

Start لحظه‌ای است، Run نگه داشته می‌شود.

لایه ۳) تایمر تایید فشار (Feedback Timeout)

مثلاً:

• اگر تا ۸ ثانیه بعد از Run، فشار به حداقل نرسید → Trip

شبه‌منطق شفاف (برای تصور ذهنی)

• Perm_OK = LevelOK AND ValveOpen AND NoFault

• PumpRun = (StartPB OR PumpRun) AND NOT StopPB AND Perm_OK AND NOT Trip

• PressureOK = (PT_PV > MinPressure)

• TON: T_Feedback وقتی PumpRun true شد شروع کند

• اگر T_Feedback.DN و PressureOK هنوز false → Trip = 1

مسیر عیب‌یابی سریع در همین سناریو

قدم ۱) PumpRun فعال می‌شود؟

اگر PumpRun فعال نمی‌شود: permissive ها مشکل دارند.

قدم ۲) PressureOK واقعاً false است یا سنسور مشکل دارد؟

این بخش حیاتی است:

• PT واقعاً فشار نمی‌خواند؟

• کابل/تغذیه/رنج PT درست است؟

• Pressure switch درست تنظیم است؟

قدم ۳) آیا تایم‌اوت منطقی تنظیم شده؟

گاهی تایم‌اوت غیرواقعی است:

• پمپ ۱۰ ثانیه زمان لازم دارد

• اما تایم‌اوت ۵ ثانیه است
  نتیجه: تریپ بی‌دلیل

قدم ۴) آیا وضعیت Valve/Bypass درست است؟

یک شیر بسته یا بای‌پس باز می‌تواند PressureOK را false نگه دارد.

قدم ۵) بعد از رفع مشکل، پیام actionable بسازید

به جای یک آلارم مبهم مثل “Pump Fault”، پیام عملیاتی بدهید:

• «Trip: Pressure not reached within 8s»

• «Check: Valve open / PT signal / Pump suction»

بهترین روش‌ها برای لدرِ تمیز و قابل نگهداری

اگر بخواهم یک «نسخه اجرایی» خیلی خلاصه بدهم، این‌ها را انجام دهید:

• permissive ها را جدا کنید

• Permissive_Pump01

• trip ها را جدا کنید

• Trip_Pump01

• Run را تمیز نگه دارید
  Run فقط تابع permissive و trip باشد.

• زمان‌ها پارامتری باشند
  به جای TON با عدد ثابت، زمان را از Tag/DB بگیرید.

• نام‌گذاری معنی‌دار
  به جای M1 و X5، نام‌هایی مثل:

• PMP_01.RunCmd

• PMP_01.PressureOK

• PMP_01.Trip

چه زمانی لدر به‌تنهایی کافی نیست؟

اگر پروژه شما:

• داده زیاد دارد (Recipe، آرایه، ارتباطات)

• الگوریتم دارد

• توالی‌های مرحله‌ای بزرگ دارد

ترکیب زبان‌ها بهتر است:

• ST برای دیتا و محاسبات

• SFC/State Machine برای سیکل‌های مرحله‌ای

• FBD برای PID و کنترل فرآیند

چک‌لیست تحویل یک پروژه Ladder قابل اعتماد

قبل از تحویل نهایی، این‌ها را چک کنید:

• رَنگ‌ها تک‌هدفه‌اند؟

• permissive و trip تفکیک شده‌اند؟

• تایمرها نام‌گذاری و پارامتری هستند؟

• آلارم‌ها actionable هستند؟

• اپراتور می‌فهمد «چرا استارت نمی‌شود»؟

• تعمیرات می‌تواند در چند دقیقه مسیر تشخیص را طی کند؟

اگر جواب‌ها مثبت است، لدر شما «صنعتی» است—نه صرفاً “فعلاً کار می‌کند”.

جمع‌بندی

لدر را به خاطر ظاهر ساده‌اش دست‌کم نگیرید. در پروژه‌های واقعی، لدر خوب یعنی:

• توقف کمتر

• عیب‌یابی سریع‌تر

• تحویل حرفه‌ای‌تر

• و نگهداری کم‌ریسک‌تر

اگر در پروژه‌های PLC (به‌خصوص زیمنس) نیاز به طراحی ساختار لدر، استانداردسازی permissive/trip، یا بهبود قابلیت عیب‌یابی و تحویل دارید، مارش‌شاپ روی این نوع خدمات مهندسی و اجرایی کار می‌کند؛ اما معیار اصلی همان اصولی است که در این مقاله دیدید: کد باید قابل فهم، قابل ردیابی و قابل نگهداری باشد.