فرار متناوب اسلاید یک رویداد ایمنی ماشین است

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

ماشین مورد بررسی در این مورد از یک Siemens SIMATIC S7-200 CPU 226، یک واحد SIMOVERT MASTERDRIVES برای محورهای اسلاید، یک MICROMASTER 440 برای اسپیندل و یک پنل اپراتوری TP 170A استفاده می‌کند. داده‌های فرمان و وضعیت از طریق یک شبکه ارتباط سریال USS منتقل می‌شوند.

مشکل گزارش‌شده در یکی یا هر دو اسلاید رخ می‌دهد. یک رویداد ممکن است در طول یک روز کاری یک یا دو بار ظاهر شود و پس از آن، دو یا سه روز عملکرد عادی ادامه یابد. تلاش‌های قبلی شامل جدا کردن VFD اسپیندل از کابینت کنترل اصلی و بهبود اتصال زمین بوده است. این اقدامات خطا را برطرف نکردند.

این الگو اغلب عیب‌یابی حدسی را تشویق می‌کند. مهندسان ممکن است انکودر را تعویض کنند، مسیر کابل را تغییر دهند، پارامتر درایو را تنظیم کنند یا یک هادی اتصال زمین دیگر اضافه کنند. یک تغییر ممکن است موقتاً علامت مشکل را تغییر دهد و این تصور را ایجاد کند که مشکل برطرف شده است. سپس رویداد دوباره رخ می‌دهد، زیرا مسیر واقعی فرمان هرگز اثبات نشده است.

یک بررسی قابل‌اعتماد باید نخستین نقطه‌ای را شناسایی کند که در آن رفتار موردانتظار غیرعادی می‌شود. تیم باید بداند HMI چه چیزی را درخواست کرده، PLC چه چیزی را پذیرفته، PLC چه چیزی را ارسال کرده، درایو چه چیزی را دریافت کرده، درایو در داخل چه چیزی را فعال کرده و موتور در عمل چه کاری انجام داده است.

با تأیید تک‌تک تجهیزات نصب‌شده شروع کنید

سیستم‌های قدیمی زیمنس اغلب مدت‌ها پس از ترک تیم راه‌اندازی اولیه همچنان در حال کار هستند. نقشه‌ها ممکن است تغییرات دست‌نویس داشته باشند. پشتیبان‌های پارامترها ممکن است ناقص باشند. ماژول‌های جایگزین ممکن است بدون به‌روزرسانی مستندات نصب شده باشند. بنابراین، شناسایی سخت‌افزار باید پیش از تفسیر پارامترها انجام شود.

شماره سفارش کامل را از روی تمام پلاک‌های مشخصات ثبت کنید. تنها به فهرست تایپ‌شده تجهیزات تکیه نکنید. شماره گزارش‌شده CPU مدل S7-200 دارای نویسه‌هایی است که ممکن است به‌اشتباه کپی شده باشند. کنترلر واقعی ممکن است همان Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226 باشد، اما منبع تغذیه و گونه خروجی باید مستقیماً از روی واحد نصب‌شده تأیید شوند.

حتی یک نویسه نادرست می‌تواند به دفترچه راهنما، نمودار ترمینال یا قطعه یدکی اشتباه منجر شود. حرف O اغلب با صفر اشتباه گرفته می‌شود. عدد یک نیز ممکن است با حرف I اشتباه شود. حذف یک پسوند هم می‌تواند یک گزینه سخت‌افزاری مهم را پنهان کند.

همین دقت درباره واحد SIMOVERT MASTERDRIVES نیز اعمال می‌شود. MASTERDRIVES یک خانواده گسترده است، نه یک طراحی ثابت برای یک درایو. بردهای کنترلی، نسخه‌های نرم‌افزار، گزینه‌های انکودر، بردهای فناوری و پیکربندی‌های Vector Control یا Motion Control می‌توانند پارامترهای موجود و مسیریابی داخلی سیگنال‌ها را تغییر دهند.

شماره سفارش MICROMASTER 440 را نیز بررسی کنید. اگرچه MM440 اسپیندل را کنترل می‌کند نه اسلایدها را، با محیط کابینت مشترک است و ممکن است مسیر ارتباطی USS مشترکی داشته باشد. رویدادهای سوئیچینگ، مسیر کابل‌ها، پیکربندی نشانی و زمان‌بندی ارتباطی آن می‌تواند بر کل سیستم اثر بگذارد.

مدل TP 170A، نسخه پروژه HMI، تنظیمات ارتباطی و نشانی‌های PLC متصل را ثبت کنید. پنل ممکن است رویدادهای دکمه، توابع دستور ساخت، مقادیر راه‌اندازی یا رفتار تگ‌هایی داشته باشد که فقط از روی برنامه PLC قابل شناسایی نیستند.

پیش از تغییر هر پارامتر، از برنامه PLC، پروژه HMI، مجموعه پارامترهای MASTERDRIVES و مجموعه پارامترهای MM440 پشتیبان‌گیری کامل ایجاد کنید. از شیلد کابل‌ها، کلیدهای روی برد، اتصالات ترمینال و ماژول‌های اختیاری عکس بگیرید. این خط مبنا امکان می‌دهد هر تغییر بعدی با وضعیت قبلی مقایسه و در صورت نیاز برگردانده شود.

مشخص کنید اپراتورها از «حرکت خارج از کنترل» چه منظوری دارند

واژه «حرکت خارج از کنترل» می‌تواند چند رویداد متفاوت را توصیف کند. شتاب‌گیری با سرعت کامل با حرکت دستی ناخواسته و کوتاه متفاوت است. حرکت هنگام راه‌اندازی با حرکت در حین یک توالی خودکار تفاوت دارد. مسیر عیب‌یابی بر اساس رویداد دقیق تغییر می‌کند.

با هر فردی که شاهد خطا بوده است مصاحبه کنید. به‌جای نتیجه‌گیری، درباره مشاهده‌ها سؤال کنید. «انکودر خراب شد» یک نتیجه‌گیری است. «اسلاید در جهت مثبت با سرعت زیاد حرکت کرد، در حالی که HMI سرعت صفر را نشان می‌داد» یک مشاهده است.

محور درگیر، جهت، سرعت تخمینی، مدت‌زمان، موقعیت شروع، حالت ماشین، وضعیت اسپیندل، مرحله فعال برنامه و روشی را که حرکت را متوقف کرده است ثبت کنید. مشخص کنید حرکت از حالت سکون آغاز شده یا در حین حرکتی که از قبل در جریان بوده شکل گرفته است.

اگر اسلاید به‌سمت حداکثر سرعت شتاب می‌گیرد، قطبیت فیدبک، منابع فعال نقطه‌تنظیم، ترتیب فعال‌سازی و تنظیم درایو را بررسی کنید. اگر فقط مسافت کوتاهی حرکت می‌کند، بیت‌های حرکت دستی، تریگرهای لبه‌ای تکراری، فرمان‌های قدیمی و انتقال‌های وضعیت توالی را بررسی کنید.

اگر رویداد فقط در حالت خودکار رخ می‌دهد، منطق توالی اهمیت بیشتری پیدا می‌کند. اگر در حالت دستی نیز رخ می‌دهد، بر داوری فرمان مشترک میان هر دو حالت تمرکز کنید. اگر محور هنگام روشن‌شدن، تغییر وضعیت CPU، ریست درایو یا اتصال مجدد HMI حرکت می‌کند، مقداردهی اولیه هنگام راه‌اندازی باید فوراً بررسی شود.

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

همچنین مشخص کنید که آیا درایو هشدار یا خطایی ایجاد کرده است. بدون خطا بودن رویداد ثابت نمی‌کند که درایو سالم بوده است، اما نشان می‌دهد که درایو ممکن است فرمان و بازخورد را معتبر تشخیص داده باشد.

ماشین را به‌عنوان یک زنجیره کامل فرمان در نظر بگیرید

فرمان حرکت ممکن است از پنل اپراتوری TP 170A آغاز شود. یک دکمه، ورودی عددی، رسپی، رویداد صفحه یا توالی خودکار مقداری را در حافظه PLC تنظیم می‌کند. S7-200 آن درخواست را تأیید کرده و مقدار مرجع سرعت یا حرکت را محاسبه می‌کند. سپس یک روال ارتباطی USS تلگرامی شامل داده‌های کنترلی و فرایندی ایجاد می‌کند.

واحد MASTERDRIVES تلگرام را دریافت می‌کند و کلمه کنترلی و مقدار مرجع را از ساختار سیگنال داخلی خود عبور می‌دهد. فرمان نهایی فعال ممکن است شامل سرعت‌های ثابت، ورودی‌های آنالوگ، فرمان‌های ترمینالی، مقادیر مرجع تکمیلی، ورودی‌های جاگ یا بلوک‌های تابع داخلی نیز باشد.

مسیر بازگشت نیز به همان اندازه مهم است. موتور یا بار ممکن است از انکودر افزایشی، ریزولور، تاکومتر یا وسیله بازخورد دیگری استفاده کند. درایو این سیگنال را به‌عنوان سرعت یا موقعیت تفسیر می‌کند. سپس ممکن است برخی مقادیر واقعی به PLC ارسال شوند.

میکروسوئیچ‌های حد مکانیکی، حسگرهای نقطه صفر، کلیدهای عبور از حد، کنتاکتورها، ترمزها و کنتاکت‌های آماده‌به‌کار درایو مسیرهای بیشتری ایجاد می‌کنند. هر مسیر می‌تواند بر آغاز، ادامه یا توقف حرکت اثر بگذارد.

هر مرحله باید مقداری قابل‌اندازه‌گیری داشته باشد. در PLC، درخواست خام HMI، حالت عملیاتی انتخاب‌شده، وضعیت توالی، مقدار مرجع نهایی تأییدشده، جهت، فرمان فعال‌سازی و نتیجه ارتباط را ثبت کنید. در درایو، کلمه کنترلی دریافتی، مقدار مرجع دریافتی، مقدار مرجع داخلی فعال، سرعت واقعی، وضعیت بازخورد، جریان، هشدارها و خطاها را بررسی کنید.

نمایش صفر در HMI ثابت نمی‌کند که PLC صفر را ارسال کرده است. صفر بودن یک ثبات PLC ثابت نمی‌کند که منبع فرمان دیگری غیرفعال بوده است. درست بودن تلگرام USS ثابت نمی‌کند که درایو برای استفاده از آن تلگرام به‌عنوان تنها منبع مقدار مرجع پیکربندی شده است.

بررسی باید نخستین نقطه‌ای را شناسایی کند که در آن مقدار مورد انتظار با مقدار ثبت‌شده مطابقت ندارد. این نقطه، مشکل را به یکی از بخش‌های منطق HMI، برنامه کاربردی PLC، ارتباطات، پیکربندی درایو، بازخورد، سخت‌افزار قدرت یا مکانیک تقسیم می‌کند.

مهم‌ترین تفکیک تشخیصی

نخستین پرسش فنی ساده است: آیا درایو فرمان معتبر حرکت را دریافت کرده است؟

چهار مقدار را در طول رویداد مقایسه کنید:

• ست‌پوینت نهایی حرکت در PLC.
• ست‌پوینتی که درایو دریافت می‌کند.
• ست‌پوینت داخلی فعال درایو.
• حرکت واقعی اندازه‌گیری‌شده موتور یا اسلاید.

اگر ست‌پوینت نهایی PLC غیرصفر شود و درایو از آن پیروی کند، ممکن است درایو به‌درستی کار کند. حرکت ناخواسته در بخش بالادست تولید شده است. رویدادهای HMI، منطق توالی، مقادیر حفظ‌شده، تغییر حالت‌ها و چندین نوشتن روی فرمان نهایی را بررسی کنید.

اگر ست‌پوینت نهایی PLC همچنان صفر بماند اما درایو مقدار غیرصفری دریافت کند، ساختار تلگرام، نگاشت حافظه، مقیاس‌بندی، مدیریت بافر و اجرای بلوک ارتباطی را بررسی کنید. مقدار دقیق غیرمنتظره ممکن است سازوکار را مشخص کند. مقدار ثابت تکرارشونده اغلب نشان‌دهنده داده حفظ‌شده یا قدیمی است. مقدار بسیار بزرگ مثبت یا منفی ممکن است نشان‌دهنده مشکل عدد علامت‌دار یا ترتیب بایت‌ها باشد.

اگر درایو مقدار صفر دریافت کند اما ست‌پوینت داخلی فعال آن غیرصفر شود، پیکربندی درایو را بررسی کنید. ممکن است سرعت ثابت، مرجع آنالوگ، تابع جاگ، ورودی ترمینال، ست‌پوینت تکمیلی، پتانسیومتر موتوردار یا گزینه فناوری فعال باشد.

اگر ست‌پوینت PLC، ست‌پوینت دریافتی و ست‌پوینت داخلی همگی در طول شتاب‌گیری موتور صفر بمانند، رویداد جدی‌تر است. رفتار فیدبک، رگولاسیون درایو، تغذیه برد کنترل، سخت‌افزار درایو، رفتار طبقه خروجی و کوپلینگ مکانیکی را بررسی کنید.

این روش چهارسیگناله از تعویض بدون کنترل قطعات جلوگیری می‌کند. همچنین به ایجاد یک نتیجه‌گیری فنی قابل دفاع کمک می‌کند. خطا بر اساس شواهد ثبت‌شده تعیین می‌شود، نه فرضیات.

فیدبک مظنون اصلی است، اما حکم قطعی خودکار نیست

بروز متناوب خطای انکودر یا تاکومتر محتمل است، به‌ویژه وقتی رویداد با لرزش، دما، حرکت کابل یا موقعیت اسلاید تغییر می‌کند. بااین‌حال، این فرض که هرگونه قطع فیدبک به‌طور خودکار باعث حداکثر سرعت می‌شود، بیش از حد کلی است.

درایوی که به‌درستی پیکربندی شده باشد، معمولاً باید فیدبک مفقود یا غیرقابل‌قبول را تشخیص دهد و مطابق تنظیمات پایش و خطای خود واکنش نشان دهد. پاسخ دقیق به نسخه کنترل، گزینه فیدبک، پیکربندی و کاربرد بستگی دارد.

ممکن است رفتار خطرناک همچنان رخ دهد، حتی وقتی سیگنال فیدبک وجود دارد اما نادرست است. قطبیت معکوس، توالی فاز نادرست، دامنه ناپایدار سیگنال، کانال‌های آسیب‌دیده، نوع انکودر نادرست، مقیاس‌بندی نادرست، کوپلینگ‌های شل یا پیکربندی نامناسب رگولاتور ممکن است باعث شوند درایو در جهت اشتباه واکنش نشان دهد.

کابل دارای قطعی متناوب به‌ندرت مانند یک مدار کاملاً باز از کار می‌افتد. ممکن است یک هادی فقط هنگام خم شدن کابل جدا شود. ممکن است پایه یک کانکتور فقط هنگام ارتعاش زیاد تماس خود را از دست بدهد. ممکن است منبع تغذیه انکودر هنگام عملکرد کنتاکتور افت کند. جریان شیلد ممکن است بدون حذف کامل سیگنال، یک کانال تفاضلی را دچار اعوجاج کند.

سرعت واقعی گزارش‌شده توسط درایو را با یک اندازه‌گیری مستقل مقایسه کنید. تاکومتر دستی، حسگر موقتِ تأییدشده یا اندازه‌گیری مناسب با اسیلوسکوپ می‌تواند مشخص کند که آیا مقدار واقعی داخلی با حرکت فیزیکی مطابقت دارد یا خیر.

اگر درایو هنگام چرخش شفت، سرعت صفر را گزارش می‌کند، مسیر فیدبک مشکوک است. اگر درایو سرعت صحیح را گزارش می‌کند، اما فرمان نادرست می‌شود، ممکن است فیدبک به‌طور عادی کار کند.

هرگز آزمون فیدبک را با قرار دادن افراد در معرض اسلاید متحرک انجام ندهید. از موانع حفاظتی، سرعت کاهش‌یافته، شرایط آزمون کنترل‌شده و یک روش مستقل برای توقف استفاده کنید.

کل مدار فیدبک را بررسی کنید

یک سیستم فیدبک چیزی بیش از انکودر است. حسگر، کوپلینگ مکانیکی، کابل، کانکتور، منبع تغذیه، شیلد، آرایش اتصال زمین، برد ورودی و پیکربندی درایو همگی در مقدار اندازه‌گیری‌شده نقش دارند.

از اتصال مکانیکی شروع کنید. تأیید کنید که شفت انکودر، تسمه، چرخ‌دنده یا کوپلینگ انعطاف‌پذیر نمی‌تواند بلغزد. توپی‌های کوپلینگ، خارها، پیچ‌های مغزی، ترک‌ها، آلودگی و ناهم‌راستایی را بررسی کنید. انکودری که از نظر مکانیکی جدا شده است ممکن است همچنان سیگنالی تولید کند که دیگر نشان‌دهنده حرکت واقعی بار نیست.

همه کانکتورها را با نور مناسب و بزرگ‌نمایی بررسی کنید. به‌دنبال کنتاکت‌های عقب‌رفته، پرس‌های ضعیف، پایه‌های خم‌شده، خوردگی، آلودگی روغنی، گلند یا مهار کابل شکسته و کشش کابل باشید. تأیید کنید که کانکتورهای جایگزین از نوع کنتاکت صحیح استفاده می‌کنند.

پیوستگی را در حالی آزمایش کنید که ماشین ایزوله است، اما فقط به آزمایش مقاومت ایستا تکیه نکنید. یک هادی ترک‌خورده ممکن است در حالت صاف جریان را عبور دهد و هنگام خم شدن قطع شود. در یک آزمایش کم‌خطرِ تأییدشده، هنگام حرکت زنجیر کابل در مسیر عادی خود، سیگنال فیدبک را پایش کنید.

منبع تغذیه انکودر را در محل انکودر و تحت بار کاری اندازه‌گیری کنید. پایدار بودن ولتاژ داخل تابلو ثابت نمی‌کند که ولتاژ در حسگر نیز پایدار می‌ماند. کمینه مقدار را هنگام شتاب‌گیری اسپیندل، معکوس شدن محور، ترمزگیری و عملکرد کنتاکتور ثبت کنید.

برای یک انکودر افزایشی، دامنه کانال، تقارن کانال، رابطه فاز و در صورت استفاده، پالس ایندکس را بررسی کنید. زوج‌های تفاضلی باید متعادل بمانند. جهش‌های نویزی، پالس‌های ازدست‌رفته یا کاهش دامنه ممکن است نشان‌دهنده مشکلات کابل، شیلد، منبع تغذیه یا حسگر باشند.

نوع انکودر، تعداد پالس، قطبیت، مقیاس‌بندی و منبع فیدبک را در مجموعه پارامترهای درایو نصب‌شده بررسی کنید. فرض نکنید شماره پارامتری از دفترچه راهنمای دیگری برای MASTERDRIVES روی این برد کنترلی نیز کاربرد دارد.

خطاهای USS نباید به تغییرات تصادفی بیت‌ها تقلیل داده شوند

ارتباط USS از طریق یک تلگرام ساختاریافته انجام می‌شود. این پروتکل شامل بررسی خطاست؛ بنابراین یک تلگرام آسیب‌دیده معمولاً باید رد شود، نه اینکه به‌عنوان یک مقدار مرجع سرعت معتبر اما نامرتبط پذیرفته شود.

این به معنای نادیده گرفتن USS نیست. مشکلات ارتباطی همچنان می‌توانند از طریق رفتار برنامه به حرکت خارج از کنترل منجر شوند. PLC ممکن است کلمهٔ نادرست دادهٔ فرایند را بسازد. یک مقدار علامت‌دار ممکن است به‌اشتباه تفسیر شود. بایت‌های پرارزش و کم‌ارزش ممکن است جابه‌جا شوند. دادهٔ قدیمی ممکن است در بافر ارسال باقی بماند. نبود پاسخ ممکن است باعث فعال ماندن مقدار مرجع قبلی شود.

آدرس‌های تکراری اسلیو نیز می‌توانند رفتار گیج‌کننده‌ای ایجاد کنند. هر درایو موجود در شبکه باید آدرس منحصربه‌فردی داشته باشد. توالی پایش PLC باید هر پاسخ را به اسلیو و ناحیهٔ حافظهٔ درست مرتبط کند.

کلمهٔ کنترلی به اندازهٔ مقدار مرجع سرعت اهمیت دارد. ممکن است یک درایو همچنان فعال بماند، درحالی‌که برنامهٔ PLC تصور می‌کند متوقف شده است. تأیید خطا، فرمان‌های روشن/خاموش، بیت‌های جهت و منطق راه‌اندازی مجدد ممکن است هنگام بازیابی ارتباط به‌درستی پردازش نشوند.

تراکنش‌های موفق، زمان‌مهلت‌ها، فریم‌های ردشده، خطاهای متوالی و رویدادهای بازیابی را شمارش کنید. یک بیت منفرد «خطای ارتباطی» اطلاعات بسیار کمی ارائه می‌دهد. داده‌های عیب‌یابی باید مشخص کنند کدام اسلیو در حال پایش بوده و کدام تراکنش شکست خورده است.

در MICROMASTER 440، پارامتر P2010 به پیکربندی نرخ بود USS مربوط است. نباید با آن مانند تنظیم عمومی زمان‌مهلت تلگرام رفتار کرد. P2011 معمولاً با آدرس USS مرتبط است. بااین‌حال، معنای همهٔ پارامترها باید در دفترچهٔ صحیح MM440 و پیکربندی رابط تأیید شود.

افزایش زمان‌مهلت به‌طور خودکار ایمنی بیشتری ایجاد نمی‌کند. اگر درایو هنگام انتظار برای پایان مهلت، همچنان از یک مقدار مرجع غیرصفر قبلی استفاده کند، افزایش این تأخیر می‌تواند حرکت ناخواسته را طولانی‌تر کند. ابتدا پاسخ موردنیاز به قطع ارتباط را تعیین کنید.

لایهٔ فیزیکی RS-485 همچنان اهمیت دارد

حتی اگر فریم‌های خراب رد شوند، یک شبکهٔ ناپایدار RS-485 می‌تواند باعث تلاش‌های مجدد مکرر، داده‌های منقضی، از دست رفتن به‌روزرسانی‌های وضعیت و زمان‌بندی نامنظم برنامه شود. بنابراین شبکهٔ فیزیکی به یک ممیزی کامل نیاز دارد.

گذرگاه را از پورت ارتباطی S7-200 تا هر درایو مستندسازی کنید. تأیید کنید که سیم‌کشی از توپولوژی خطی مناسب استفاده می‌کند. انشعاب‌های ستاره‌ای طولانی می‌توانند بازتاب ایجاد کنند و باید از آن‌ها اجتناب شود، مگر اینکه مستندات رابط نصب‌شده صراحتاً استفاده از آن‌ها را مجاز دانسته باشد.

تأیید کنید که همه دستگاه‌ها از تنظیمات ارتباطی یکسان استفاده می‌کنند. این تنظیمات شامل نرخ بود، پریتی، ساختار تلگرام، طول دادهٔ فرایند و آدرس اسلیو هستند. تنظیمات را ثبت کنید و آن‌ها را بر اساس حافظه تغییر ندهید.

ترمینیشن باید مطابق الزامات رابط‌ها و کانکتورهای واقعی زیمنس انجام شود. نباید یک مقاومت عمومی ۱۲۰ اهم به‌صورت خودکار اضافه شود. ترمینیشن یا بایاس‌گذاری نادرست می‌تواند سیگنال را بدتر کند.

نوع کابل ارتباطی، پیوستگی شیلد، اتصال بدنهٔ کانکتورها و مسیر کابل‌کشی را بررسی کنید. کابل RS-485 نباید در مسیرهای طولانی در کنار کابل‌های خروجی موتور، هادی‌های مقاومت ترمز، سیم‌کشی کنتاکتورها یا دیگر مدارهای قدرت با فرکانس بالا عبور کند.

هرجا فاصله‌گذاری محدود است، کابل‌های قدرت و سیگنال را با زاویهٔ تقریباً قائمه از روی یکدیگر عبور دهید. هم‌بندی هم‌پتانسیلِ عمدی را بین تابلوها و بخش‌های دستگاه حفظ کنید. از دُم‌سیمی‌های بلند شیلد که اثربخشی فرکانس بالا را کاهش می‌دهند، پرهیز کنید.

در صورت لزوم، برای بررسی شکل‌موج از یک پرُب اسیلوسکوپ تفاضلی مناسب استفاده کنید. به بازتاب‌ها، ولتاژ بیش‌ازحد مد مشترک، زنگ‌زدگی، لبه‌های کند، جهش‌های نویزی و تغییرات دامنه هنگام شتاب‌گیری اسپیندل یا ترمزگیری محور توجه کنید.

یک لپ‌تاپ متصل یا مبدل USB ممکن است اتصال زمین و بارگذاری گذرگاه را تغییر دهد. ثبت کنید که آیا با اتصال تجهیزات عیب‌یابی، خطا تغییر می‌کند یا نه.

اجزای مورد استفاده در ارتباطات و شبکه‌سازی صنعتی باید همراه با توپولوژی، شیلدینگ، ترمینیشن، آدرس‌دهی و مدیریت تراکنش‌های PLC ارزیابی شوند. تعویض یک کانکتور، ماشین حالت ضعیف ارتباطات را اصلاح نمی‌کند.

برنامهٔ S7-200 را به‌عنوان یک ماشین حالت بررسی کنید

خطاهای مقطعی راه‌اندازی اغلب هنگام تغییر وضعیت‌ها، نه در عملکرد پایدار، ظاهر می‌شوند. ممکن است دستگاه هنگام کار مداوم درست رفتار کند، اما هنگام تغییر بین حالت دستی و خودکار، تکمیل بازگشت به مبدأ، بازیابی از هشدار، تغییر دستور ساخت یا برقراری دوبارهٔ ارتباط دچار مشکل شود.

در ارجاع متقابل برنامه، همهٔ دستورهایی را که در متغیرهای نهایی سرعت، جهت و فعال‌سازی می‌نویسند جست‌وجو کنید. برنامه‌های قدیمی اغلب در چندین شبکه، یک کلمهٔ حافظهٔ V یکسان را می‌نویسند. آخرین نوشتنِ اجراشده نتیجه را کنترل می‌کند و این مسئله می‌تواند رفتاری ایجاد کند که تصادفی به نظر برسد.

یک مرحلهٔ روشن برای داوری فرمان ایجاد کنید. حرکت دستی، حرکت خودکار، بازگشت به مبدأ، توابع راه‌اندازی و فرمان‌های تعمیر و نگهداری باید به‌صورت درخواست‌های جداگانه وارد این مرحله شوند. مقدار مرجع نهایی فقط پس از اعتبارسنجی حالت، محدودیت‌ها، بازخورد، ارتباطات و مجوزهای ایمنی تولید شود.

منطق تک‌اجرایی و تشخیص لبه را بررسی کنید. فرمانی که قرار است فقط در یک اسکن فعال باشد، ممکن است به این دلیل همچنان فعال بماند که حافظهٔ لبهٔ آن دوباره استفاده شده، حفظ شده یا بازنویسی شده است. همچنین ممکن است با تغییر بیت حالت، فرمان دوباره فعال شود.

همهٔ لَچ‌ها را بررسی کنید. شرایطی را که آن‌ها را تنظیم می‌کند و همهٔ شرایطی را که بازنشانی‌شان می‌کند، شناسایی کنید. یک لَچ حرکتی که فقط به یک مرحلهٔ بعدی توالی وابسته است، ممکن است وقتی توالی بر اثر خطا متوقف می‌شود همچنان فعال بماند.

نحوهٔ مدیریت داده‌های علامت‌دار را بررسی کنید. ممکن است یک عدد صحیح منفی که به‌صورت کلمهٔ بدون علامت تفسیر شده است، به یک مقدار مثبت بزرگ تبدیل شود. ضرب ممکن است سرریز کند. کلمه‌ای که با ترتیب بایت نادرست کپی شود می‌تواند یک مقدار تنظیمی بسیار بزرگ ایجاد کند.

مقیاس‌بندی از واحدهای مهندسی به مقدار فرایندی USS را تأیید کنید. محدودیت‌های مثبت و منفی را پس از محاسبهٔ نهایی اعمال کنید، نه فقط در ورودی HMI.

سیستم‌های کنترلی Siemens SIMATIC S7 قدیمی می‌توانند دهه‌ها به‌طور قابل‌اعتماد کار کنند، اما برنامه‌های کاربردی آن‌ها اغلب شامل اصلاحاتی از چندین مرحلهٔ راه‌اندازی هستند. بازبینی ساختاریافتهٔ ارجاع متقابل ارزشمندتر از این فرض است که سخت‌افزار CPU ناپایدار شده است.

وضعیت‌های راه‌اندازی و بازیابی به آزمایش‌های جداگانه نیاز دارند

داده‌های مقداردهی‌نشده یا ماندگار می‌توانند پس از قطع برق، دانلود نرم‌افزار، تغییر وضعیت CPU از STOP به RUN، ریست درایو یا اتصال مجدد HMI باعث حرکتی نادر شوند.

تمام نواحی حافظهٔ ماندگار مورد استفادهٔ برنامهٔ حرکت را شناسایی کنید. مقدار اولیهٔ فرمان سرعت، جهت، فعال‌سازی، حالت، مرحلهٔ توالی، بیت‌های حرکت لحظه‌ای و وضعیت ارتباط را پس از هر نوع راه‌اندازی مجدد تعیین کنید.

روال راه‌اندازی باید همهٔ درخواست‌های حرکت را به صفر اجباری کند. این روال باید فرمان‌های حرکت لحظه‌ای و خودکارِ در انتظار را پاک کند، بازخورد را اعتبارسنجی کند، وضعیت محدودکننده‌ها را تأیید کند، ارتباط را برقرار کند و به یک توالی فعال‌سازی جدید و عمدی نیاز داشته باشد.

مقدار تنظیمی غیرصفری که حفظ شده است، هرگز نباید صرفاً به این دلیل مؤثر شود که درایو پیش از تکمیل مقداردهی اولیه توسط PLC آماده شده است.

راه‌اندازی سرد، راه‌اندازی مجدد گرم، تغییر وضعیت CPU از STOP به RUN، ریست درایو، اتصال مجدد HMI و بازیابی یک نود USS ازکارافتاده را آزمایش کنید. این آزمایش‌ها را در حالی انجام دهید که ماشین از نظر مکانیکی مهار شده و سرعت موجود کاهش یافته باشد.

منبع تغذیهٔ کنترلی ۲۴ ولت را هنگام رخدادهای مربوط به توان پایش کنید. PLC، انکودر، HMI، رابط ارتباطی، کنتاکتورها و مدارهای الکترونیکی کنترل درایو ممکن است در آستانه‌های ولتاژی متفاوتی ریست شوند. افت کوتاه ولتاژ می‌تواند باعث شود یک دستگاه همچنان کار کند، در حالی که دستگاه دیگر راه‌اندازی مجدد می‌شود.

ترتیب روشن شدن توان کنترلی، اجرای PLC، سالم بودن ارتباط، آماده بودن درایو، آزاد شدن ترمز و فعال شدن حرکت را ثبت کنید. این ترتیب باید صریح و تکرارپذیر باشد.

HMI می‌تواند فرمان‌هایی تولید کند که دیگر قابل مشاهده نیستند

پروژهٔ TP 170A باید همراه با برنامهٔ PLC بازبینی شود. ممکن است فرمان HMI هنگام فشردن دکمه، رها کردن دکمه، باز شدن صفحه، بسته شدن صفحه، دانلود دستور پخت، به‌روزرسانی تگ یا بازیابی ارتباط نوشته شود.

وقتی عملکرد فشردن یک دکمهٔ حرکت لحظه‌ای یک بیت را تنظیم و عملکرد رها کردن آن بیت را پاک می‌کند، ممکن است وضعیت خطرناکی ایجاد شود. اگر هنگام فشرده بودن دکمه ارتباط قطع شود، فرمان پاک‌کردن ممکن است هرگز به PLC نرسد.

اپراتور بعداً دکمه را رهاشده می‌بیند، اما بیت PLC همچنان فعال است. سپس یک تغییر حالت یا مجوز دیگر ممکن است درخواست جاگِ باقی‌مانده را به فرمان نهایی حرکت منتقل کند.

یک عملکرد جاگ قابل‌اعتماد نباید فقط به یک جفت فشردن و رها کردن دکمه متکی باشد. PLC باید به‌روزرسانی پیوسته فرمان را الزامی کند، زمان انقضای کوتاهی اعمال کند، حالت کاری را اعتبارسنجی کند و هنگام نامعتبر شدن ارتباط، فرمان را حذف کند.

هر رویداد HMI مرتبط با جاگ، ورود سرعت، جهت، ریست، انتخاب حالت، بازگشت به مبدأ و کنترل چرخه خودکار را بررسی کنید. تگ‌های تکراری اشاره‌کننده به یک آدرس PLC را جست‌وجو کنید.

ورودی‌های عددی هم در پنل و هم در PLC به بررسی محدوده نیاز دارند. PLC باید مقادیر خارج از محدوده مهندسی مجاز را رد کند، حتی اگر فیلد HMI به‌درستی پیکربندی شده باشد.

سیستم‌های قدیمی HMI زیمنس SIMATIC ممکن است رفتاری در سطح صفحه داشته باشند که در منطق PLC قابل مشاهده نیست. ثبت جداگانه تگ خام HMI از فرمان اعتبارسنجی‌شده PLC به شناسایی منبع واقعی فرمان کمک می‌کند.

MM440 ممکن است بدون کنترل محور لغزنده بر رویداد اثر بگذارد

MICROMASTER 440 اسپیندل را کنترل می‌کند، اما همچنان می‌تواند بر محیط کنترل محور لغزنده اثر بگذارد. یکسوساز ورودی، لینک DC، خروجی موتور، مدار ترمز و فرکانس سوئیچینگ آن می‌توانند تداخل هدایتی یا تشعشعی ایجاد کنند.

قوی‌ترین اختلال ممکن است هنگام شتاب‌گیری، کاهش سرعت، پیک‌های جریان یا ترمزگیری اسپیندل رخ دهد، نه هنگام کارکرد پایدار. زمان‌مهرهای حرکت ناخواسته را با وضعیت اسپیندل مقایسه کنید.

راه‌اندازی، توقف، تغییر سرعت، جریان، وضعیت گذرگاه DC، تاریخچه خطا و فعالیت ترمز اسپیندل را ثبت کنید. مشخص کنید آیا هر رویداد در حین انتقال مشابهی در وضعیت اسپیندل رخ می‌دهد یا خیر.

اگر واحدهای MM440 و MASTERDRIVES از گذرگاه USS مشترک استفاده کنند، اسپیندل بر زمان‌بندی ارتباطات نیز اثر می‌گذارد. PLC باید هر اسلیو را به‌صورت قابل پیش‌بینی پایش کند و هر پاسخ را در ساختار حافظه صحیح پردازش کند.

بررسی کنید که نواحی داده USS اسپیندل و محور لغزنده با هم هم‌پوشانی نداشته باشند. در برخی کاربردهای فشرده S7-200، حافظه V بدون جداسازی روشن دوباره استفاده می‌شود. ممکن است بلوکی که برای اسپیندل نوشته شده، بخشی از فرمان محور لغزنده را بازنویسی کند.

قرار دادن MM440 در خارج از تابلو، تأثیر آن را به‌طور کامل از بین نمی‌برد. ممکن است کابل‌های موتور، مسیرهای اتصال به زمین، مسیر کابل‌های ارتباطی و منابع تغذیه مشترک همچنان متصل باشند.

به‌جای جابه‌جایی‌های مکرر، از اندازه‌گیری استفاده کنید. جداسازی کابل‌ها، اتصال شیلد به زمین، راکتورهای خط یا فیلترهای تعیین‌شده برای درایو، هم‌بندی تابلو، اتصال انتهایی کابل موتور و رابطه زمانی بین رویدادهای سوئیچینگ و خطاهای ارتباطی را بررسی کنید.

ممیزی MASTERDRIVES بر اساس عملکرد سیگنال

ممیزی پارامترهای MASTERDRIVES باید کل مسیر سیگنال را دنبال کند. کار را با فهرستی از شماره پارامترها که از نصب دیگری کپی شده‌اند آغاز نکنید.

ابتدا نسخهٔ کنترل نصب‌شده، انتشار نرم‌افزار، برد کنترل و گزینهٔ فیدبک را تأیید کنید. سپس حالت کنترل، داده‌های موتور، نوع فیدبک، مقیاس‌بندی فیدبک و منبع فیدبک را بررسی کنید.

هر منبعی را که می‌تواند فرمان‌های روشن/خاموش درایو را کنترل کند شناسایی کنید. این منابع ممکن است شامل کلمات کنترلی USS، ورودی‌های ترمینال، فرمان‌های ثابت، اتصالات باینکتور داخلی یا عملکردهای فناوری باشند.

هر منبعی را که می‌تواند در نقطهٔ تنظیم نهایی سرعت یا موقعیت سهم داشته باشد شناسایی کنید. نقطهٔ تنظیم اصلی، نقاط تنظیم تکمیلی، سرعت‌های ثابت، عملکردهای حرکتِ دستی، ورودی‌های آنالوگ، عملکردهای پتانسیومتر موتوردار و بلوک‌های عملکرد داخلی را بررسی کنید.

حدود سرعت مثبت و منفی، رمپ‌های شتاب‌گیری، رمپ‌های کاهش سرعت، محدودیت‌های جریان، محدودیت‌های گشتاور و محدودیت‌های جهت را بررسی کنید. تنظیمات موقت محافظه‌کارانه ممکن است خطر تشخیصی را کاهش دهند، اما جایگزین حفاظت ایمنی مستقل نیستند.

پایش فیدبک و پاسخ به خطا را بررسی کنید. مشخص کنید درایو هنگام مفقودشدن، ناپایداری، معکوس‌شدن یا نامعقول‌شدن فیدبک، برای انجام چه کاری پیکربندی شده است.

پیش از پاک‌کردن تاریخچهٔ هشدارها و خطاهای درایو، آن را بخوانید. هشداری که ظاهراً بی‌ارتباط است ممکن است لحظهٔ تغییر وضعیت کنترلی را ثبت کرده باشد.

برای مشاهدهٔ کانکتورهای داخلی و مقادیر واقعی، از روش مهندسی نصب‌شده، مانند DriveMonitor، PMU، OP1S یا رابط تأییدشدهٔ دیگری استفاده کنید. مقادیر را بر اساس نسخهٔ خاص کنترل انتخاب کنید.

این رویکرد عملکردی برای سیستم‌های درایو و کنترل حرکت زیمنس قدیمی و فعلی کاربرد دارد. نرم‌افزار کنترل، گزینه‌های فیدبک و مسیریابی داخلی ممکن است متفاوت باشند، حتی وقتی دو درایو از نظر فیزیکی مشابه به نظر می‌رسند.

یک ثبت‌کنندهٔ رویدادِ تریگرشده بسازید

رویدادی که روزی یک‌بار رخ می‌دهد، با مشاهدهٔ پیوستهٔ HMI حل نمی‌شود. سیستم به یک ثبت‌کنندهٔ تشخیصی نیاز دارد که بازهٔ پیش و پس از حرکت غیرعادی را ثبت کند.

یک بافر حلقوی PLC ایجاد کنید که شامل فرمان خام HMI، فرمان اعتبارسنجی‌شده، نقطهٔ تنظیم نهایی سرعت، جهت، فعال‌سازی، حالت، وضعیت توالی، ورودی‌های محدودکننده، وضعیت آماده‌به‌کار درایو، نتیجهٔ تراکنش USS و شمارندهٔ نمونه باشد.

در درایو، کلمهٔ کنترلی دریافتی، نقطهٔ تنظیم دریافتی، نقطهٔ تنظیم داخلی فعال، سرعت واقعی، وضعیت فیدبک، جریان خروجی، و در صورت موجود بودن جریان تولیدکنندهٔ گشتاور، هشدارها و خطاها را ثبت کنید.

تریگر می‌تواند بر اساس سرعت واقعیِ بالاتر از یک آستانهٔ کوچک، در حالی که فرمان نهایی PLC صفر است، فعال شود. تریگر دیگری می‌تواند حرکت خارج از وضعیت تأییدشدهٔ توالی را تشخیص دهد. ناهماهنگی بین جهت فرمان‌داده‌شده و جهت اندازه‌گیری‌شده نیز می‌تواند ثبت داده را فعال کند.

داده‌های پیش از فعال‌شدن تریگر را حفظ کنید. اگر ثبت فقط پس از حرکت اسلاید آغاز شود، ممکن است شرط آغازکننده دیگر وجود نداشته باشد.

تشخیص ارتباط باید بین تراکنش‌های موفق، پاسخ‌های ازدست‌رفته، پیام‌های ردشده، خرابی‌های متوالی و رویدادهای بازیابی تمایز قائل شود. مشخص کنید هنگام وقوع خطا کدام برده فعال بوده است.

منطق تشخیصی را فشرده نگه دارید. S7-200 حافظه و ظرفیت اسکن محدودی دارد. تأیید کنید که ثبت گزارش، زمان‌بندی روال‌های USS موجود را مختل نمی‌کند.

پس از هر رویداد، داده‌ها را صادر کنید. آن‌ها را همراه با تاریخ، وضعیت ماشین، گزارش شاهد و هرگونه مشاهده فیزیکی ذخیره کنید. توالی چندین رویداد ممکن است الگویی را آشکار کند که یک رویداد به‌تنهایی نمی‌تواند.

از شمارنده‌های تشخیصی استفاده کنید که به پرسش‌های مشخص پاسخ می‌دهند

شمارنده‌ها فقط زمانی مفید هستند که معنای آن‌ها روشن باشد. یک شمارنده عمومی فرمان و یک شمارنده عمومی بازخورد ممکن است به دلایل عادی متعددی با هم اختلاف داشته باشند.

هر درخواست حرکت پذیرفته‌شده از HMI را بشمارید. هر فرمان حرکتی پذیرفته‌شده توسط داوری نهایی PLC را بشمارید. هر انتقال USS که با موفقیت تکمیل شده است را بشمارید. هر پاسخ معتبر دریافت‌شده از درایو محور را بشمارید.

همچنین وقفه‌های زمانی ارتباط، رویدادهای آماده‌نبودن درایو، فعال‌شدن محدودکننده‌ها، تغییر حالت‌ها و انقضای فرمان‌ها را بشمارید.

آخرین مقدار سرعت ارسال‌شده و کلمه کنترل را ذخیره کنید. آخرین مقدار واقعی معتبر دریافت‌شده و کلمه وضعیت را ذخیره کنید. هرجا عملی است، یک شماره توالی به ساختار فرمان اضافه کنید.

هنگام وقوع یک رویداد، شمارنده‌ها می‌توانند به چندین پرسش پاسخ دهند:

• آیا HMI یک درخواست ایجاد کرد؟
• آیا PLC آن درخواست را تأیید کرد؟
• آیا PLC یک تلگرام جدید ارسال کرد؟
• آیا درایو یک پاسخ معتبر برگرداند؟
• آیا حرکت واقعی بدون یک فرمان جدید و تأییدشده آغاز شد؟

نباید شمارنده در هر راه‌اندازی به‌طور خودکار بازنشانی شود، مگر اینکه مقدار تاریخی آن ضرورتی نداشته باشد. ذخیره شمارنده رویداد را در حافظه ماندگار در نظر بگیرید و در عین حال خودِ همه فرمان‌های حرکت را به یک مقدار امن برای راه‌اندازی اجباری کنید.

حفاظت مستقل در برابر عبور از محدوده نمی‌تواند به منطق عادی وابسته باشد

محدودیت‌های موقعیت نرم‌افزاری ارزشمند هستند، اما نمی‌توانند تنها لایه دفاعی در برابر خطایی باشند که ممکن است از برنامه PLC، مسیر ارتباطی یا کنترل‌کننده عادی درایو ناشی شود.

هر محور باید به حفاظت مناسب و به‌درستی طراحی‌شده در انتهای مسیر مجهز باشد. بسته به ارزیابی ریسک ماشین، این حفاظت ممکن است شامل کلیدهای محدودکننده سیم‌کشی‌شده، حسگرهای موقعیت دارای رده ایمنی، رله‌های ایمنی، مدارهای مهار درایو، کنتاکتورها، ترمزها یا معماری اعتبارسنجی‌شده دیگری باشد.

یک ورودی استاندارد PLC که فرمان سرعت صفر را می‌نویسد، به‌طور خودکار یک عملکرد ایمنی محسوب نمی‌شود. همان خطای منطقی که باعث حرکت شده است، ممکن است مانع پردازش آن فرمان توقف شود.

حذف نقطه تنظیم سرعت نیز تضمین‌کننده حذف گشتاور نیست. درایو ممکن است همچنان فعال بماند، یک نقطه تنظیم ثانویه همچنان فعال باشد، یا انرژی مکانیکی ذخیره‌شده همچنان بار را به حرکت درآورد.

توقف اضطراری، اینترلاک‌های حفاظتی، کلیدهای بیش‌ازحدحرکت، کنتاکت‌های خطای درایو، ترمزها و کنتاکتورها را به‌طور مستقل آزمایش کنید. پس از عمل‌کردن حفاظت، تأیید کنید که راه‌اندازی مجدد به اقدام عمدی نیاز دارد.

هنگام اجرای تشخیصی، حداکثر سرعت، شتاب، گشتاور و مسیر قابل‌دسترس را در صورت امکان فنی کاهش دهید. از توقف‌گاه‌های مکانیکی موقت فقط زمانی استفاده کنید که برای انرژی ضربه احتمالی طراحی شده باشند.

هیچ هدف تشخیصی، قرار دادن فرد در معرض محوری را که پیش‌تر حرکت کنترل‌نشده نشان داده است، توجیه نمی‌کند.

نمونه موردی: کابلی که فقط هنگام معکوس‌کردن از کار می‌افتد

اسلایدی را در نظر بگیرید که در آزمون ایستای آهسته عادی رفتار می‌کند، اما هنگام معکوس‌کردن سریع جهت به‌شدت حرکت می‌کند. گزارش PLC فرمانی پایدار را نشان می‌دهد. ردپای درایو اختلالی ناگهانی در سرعت اندازه‌گیری‌شده و سپس خروجی اصلاحی بزرگی را نشان می‌دهد.

آزمون پیوستگی کابل انکودر در حالت توقف دستگاه موفق است. اما کابل از یک زنجیر متحرک عبور می‌کند. یکی از رشته‌ها نزدیک حداقل شعاع خم شکستگی دارد و فقط وقتی زنجیر به موقعیت خاصی می‌رسد، مدار آن باز می‌شود.

اندازه‌گیری اسیلوسکوپ در ورودی درایو نشان می‌دهد که یکی از کانال‌های انکودر هنگام معکوس‌شدن فرو می‌ریزد. فرمان همچنان صحیح است و هیچ خطای USS ثبت نمی‌شود.

کابل با نوع صحیحِ مناسب برای خم‌شدن پیوسته تعویض می‌شود. مهار کششی و اتصال شیلد به حالت صحیح بازگردانده می‌شوند. تغذیه انکودر و کیفیت شکل موج در سراسر مسیر حرکت اسلاید آزمایش می‌شوند.

تأیید نهایی شامل معکوس‌کردن‌های مکرر در سرعت کاهش‌یافته و سپس کارکرد کنترل‌شده با سرعت عادی تولید است. یک شکل موج سالم جدید به‌عنوان خط مبنا ذخیره می‌شود.

این مورد نشان می‌دهد چرا خطای بازخورد باید به‌صورت پویا اثبات شود. آزمون مقاومت ایستا ممکن است موفق باشد، حتی وقتی کابل در حین کار از کار می‌افتد.

نمونه موردی: باقی ماندن فرمان حرکت دستی پس از قطع ارتباط HMI

در دستگاهی دیگر، فشردن دکمه حرکت دستی یک بیت PLC را تنظیم می‌کند. با رها کردن دکمه، بیت پاک می‌شود. هنگام فشرده بودن دکمه، ارتباط HMI قطع می‌شود؛ بنابراین فرمان رهاسازی هرگز به PLC نمی‌رسد.

در آن لحظه، اینترلاک دیگری از حرکت جلوگیری می‌کند. بیت حرکت دستیِ قدیمی پنهان باقی می‌ماند. بعداً اپراتور حالت دستگاه را تغییر می‌دهد. منطق نهایی PLC اکنون درخواست قدیمی حرکت دستی را می‌پذیرد و اسلاید به‌طور غیرمنتظره حرکت می‌کند.

درایو از یک مقدار مرجع معتبر PLC پیروی می‌کند. هنگام آغاز حرکت، ارتباط USS سالم است. تعویض انکودر یا افزودن اتصال دیگری به شیلد، مشکل را برطرف نمی‌کند.

منطق اصلاح‌شده PLC به یک درخواست حرکتِ دستی نیاز دارد که پیوسته به‌روزرسانی شود. فرمان پس از مدت کوتاهی منقضی می‌شود. این فرمان فقط در حالت صحیح، با ارتباط معتبر و وجود شرط فعال‌سازی لازم پذیرفته می‌شود.

منطق راه‌اندازی همه درخواست‌های حرکت را پاک می‌کند. عمل رهاسازی در HMI باقی می‌ماند، اما دیگر تنها سازوکاری نیست که فرمان را حذف می‌کند.

ثبت‌کننده رویداد تأیید می‌کند که بیت خام HMI پس از خرابی ارتباطی قبلی همچنان فعال بوده است. علت اصلی، خرابی ارتباطات نبود؛ بلکه مدیریت ناایمن یک فرمان معتبر اما قدیمی بود.

نمونه موردی: نویز، ضعف در مدیریت بافر USS را آشکار می‌کند

یک دستگاه سوم هنگام شتاب‌گیری اسپیندل، با وقفه‌های زمانی USS مواجه می‌شود. تلگرام‌های آسیب‌دیده رد می‌شوند؛ بنابراین شبکه مستقیماً یک فرمان سرعت را به فرمانی دیگر تبدیل نمی‌کند.

بااین‌حال، برنامه کاربردی PLC پس از یک تراکنش ناموفق، فرمان قبلی محور را نامعتبر نمی‌کند. روال USS نیز به‌صورت شرطی اجرا می‌شود و در نتیجه، فواصل نظرسنجی نامنظم ایجاد می‌شوند.

در طول گذار توالی، فرمان صفر جدید در یک محل حافظه نوشته می‌شود، در حالی که بافر انتقال همچنان حاوی مقدار قدیمیِ ناصفر است. تلگرام موفق بعدی، داده‌ای معتبر اما قدیمی را ارسال می‌کند.

درایو فرمانی با ساختار صحیح را دریافت می‌کند و به‌طور عادی پاسخ می‌دهد. اختلال لایه فیزیکی، یک ضعف نرم‌افزاری را آشکار کرد، نه اینکه مستقیماً مقدار تنظیمی را ایجاد کرده باشد.

اقدام اصلاحی، مسیر کابل و اتصال شیلد را بهبود می‌دهد. سپس روال ارتباطی PLC بازطراحی می‌شود تا هر درایو از حافظه اختصاصی خود استفاده کند. مقدار تنظیمی نهاییِ اعتبارسنجی‌شده بلافاصله پیش از تراکنش در بافر انتقال کپی می‌شود.

عدم دریافت پاسخ، داده را نامعتبر علامت‌گذاری می‌کند. پاسخ برنامه‌ریزی‌شده به قطع ارتباط از طریق آزمایش‌های کنترل‌شده تأیید می‌شود.

این مورد نشان می‌دهد که چرا عیب‌یابی ارتباطات باید هم شکل موج الکتریکی و هم چرخه عمر داده‌های کاربردی را پوشش دهد.

یک توالی عملی برای بررسی در محل

مرحله ۱: دستگاه را ایمن کنید. حفاظت مستقل در برابر حرکت بیش‌ازحد، کاهش انرژی آزمایش و محدودکردن دسترسی افراد را برقرار کنید.

مرحله ۲: سخت‌افزار را تأیید کنید. شماره‌های سفارش کامل، نسخه‌های نرم‌افزار، بردهای اختیاری، تجهیزات بازخورد و ماژول‌های رابط را ثبت کنید.

مرحله ۳: نسخه‌های پشتیبان ایجاد کنید. برنامه S7-200، پروژه TP 170A، مجموعه پارامترهای MASTERDRIVES و پارامترهای MM440 را ذخیره کنید.

مرحله ۴: رویداد را تعریف کنید. جهت، سرعت، مدت، حالت کاری، موقعیت، وضعیت اسپیندل و رفتار توقف را ثبت کنید.

مرحله ۵: زنجیره فرمان را ترسیم کنید. هر منبع مقدار تنظیمی، فعال‌سازی، جهت، سرعت ثابت، حرکت گام‌به‌گام و مرجع تکمیلی را شناسایی کنید.

مرحله ۶: ثبت همگام‌سازی‌شده را اضافه کنید. فرمان‌های PLC، داده‌های USS، مقادیر داخلی درایو، بازخورد، جریان، محدودیت‌ها، هشدارها و خطاها را ثبت کنید.

مرحله ۷: وضعیت‌های راه‌اندازی را آزمایش کنید. راه‌اندازی سرد، راه‌اندازی مجدد گرم، گذارهای CPU RUN، اتصال مجدد HMI و بازیابی ارتباطات را بررسی کنید.

مرحله ۸: بازخورد را به‌صورت پویا بررسی کنید. ولتاژ تغذیه، کیفیت شکل موج، کوپلینگ، کانکتورها، شیلدینگ و خم‌کردن کابل را آزمایش کنید.

گام ۹: USS و RS-485 را ممیزی کنید. آدرس‌دهی، توپولوژی، ترمینیشن، نواحی داده، زمان‌بندی و مدیریت خطا را بررسی کنید.

گام ۱۰: ارجاع متقابل PLC را بازبینی کنید. همه نویسنده‌های نقطه تنظیم نهایی، جهت و فعال‌سازی درایو را پیدا کنید.

گام ۱۱: مسیر سیگنال‌های درایو را ممیزی کنید. هر منبع فرمان و هر عامل مؤثر بر نقطه تنظیم فعال را بررسی کنید.

گام ۱۲: هر بار فقط یک مورد را تغییر دهید. وضعیت قبلی، وضعیت جدید، دلیل، نتیجه آزمون و روش بازگشت را ثبت کنید.

سخت‌سازی بلندمدت باید معماری را هدف قرار دهد

پس از یافتن علت فوری، بپرسید چرا یک خطا می‌توانسته حرکتی آسیب‌زا ایجاد کند. یک مهلت‌انقضای ارتباطی، پارگی کابل یا خطای HMI نباید بتواند از همه لایه‌های حفاظتی عبور کند.

تولید فرمان، اعتبارسنجی فرمان، انتقال ارتباطی، کنترل درایو و حفاظت ایمنی را از هم جدا کنید. هر لایه باید مسئولیتی مشخص داشته باشد.

PLC باید فرمانی محدود و اعتبارسنجی‌شده بر اساس وضعیت تولید کند. روال ارتباطی باید داده‌های جاری را با اعتبار و تازگیِ مشخص ارسال کند. درایو باید محدودیت‌های عملیاتی پیکربندی‌شده و پایش بازخورد را اعمال کند. عملکردهای ایمنی مستقل باید حرکت خطرناک را کنترل کنند.

بررسی کنید که آیا معماری S7-200 و USS همچنان قابل پشتیبانی است یا نه. مهاجرت به پلتفرم جدیدتر PLC و درایو ممکن است عیب‌یابی، ثبت زمان، دسترس‌پذیری قطعات، مشاهده‌پذیری شبکه و مدیریت پشتیبان‌گیری را بهبود دهد.

شبکه جدیدتر به‌طور خودکار ماشین را ایمن نمی‌کند. PROFINET به‌تنهایی ضعف در داوری فرمان‌ها، منطق نامناسب راه‌اندازی یا حفاظت ناکافی در برابر حرکت بیش‌ازحد را اصلاح نمی‌کند.

نوسازی باید HMI، نقشه‌ها، کنترل نسخه نرم‌افزار، معماری ایمنی، راهبرد قطعات یدکی و آموزش کارکنان را نیز شامل شود. تعویض تنها PLC ممکن است مشکل را به پلتفرمی دیگر منتقل کند.

برای کاربردهای موقعیت‌یابی دشوار، بررسی کنید که آیا پروفایل حرکت باید داخل یک درایو اختصاصی یا کنترلر حرکت اجرا شود، نه از طریق ارسال مکرر فرمان‌های سرعت سریال. تصمیم درست به دقت موقعیت‌یابی، همگام‌سازی، زمان چرخه، معماری بازخورد و ریسک ماشین بستگی دارد.

راستی‌آزمایی چیزی فراتر از انتظار برای بازگشت خطا است

هفت روز بدون رخداد امیدوارکننده است، اما ثابت نمی‌کند که علت ریشه‌ای برطرف شده است. راستی‌آزمایی باید عمداً شرایطی را بازتولید کند که پیش‌تر خطر را افزایش داده بودند.

چرخه‌های کامل حرکت را با سرعت کنترل‌شده به‌طور مکرر اجرا کنید. معکوس‌کردن‌های سریع، شتاب‌گیری اسپیندل، ترمزگیری اسپیندل، شرایط گرم کابینت، حداکثر بار عادی و حرکت زنجیر کابل را نیز در آزمون بگنجانید.

آزمون‌های راه‌اندازی و بازیابی را تکرار کنید. برق کنترل را طبق یک رویه تأییدشده قطع‌و‌وصل کنید. توقف تا اجرای CPU، بازنشانی درایو، اتصال مجدد HMI، از دست رفتن یکی از اسلیوهای USS و بازیابی ارتباط را آزمایش کنید.

واکنش به خرابی فیدبک را با استفاده از روش آزمون تأییدشده بررسی کنید. هنگامی که افراد در معرض حرکت هستند، انکودر تولیدی را قطع نکنید.

هر محدودکننده سخت‌افزاری، محدودکننده نرم‌افزاری، ورودی خطای درایو، توقف اضطراری، ترمز و دستگاه مستقل محدودکننده حرکت اضافی را آزمایش کنید. واکنش توقف و رفتار راه‌اندازی مجدد موردنیاز را تأیید کنید.

فرمان نهایی PLC، فرمان دریافتی درایو، مقدار تنظیمی داخلی فعال و حرکت واقعی را در سراسر هر آزمون با یکدیگر مقایسه کنید.

معیارهای پذیرش را پیش از آزمون تعریف کنید. معیارهای مناسب می‌توانند شامل موارد زیر باشند:

• در هیچ وضعیت راه‌اندازی یا بازیابی، حرکت ناخواسته‌ای رخ ندهد.
• هیچ خرابی ارتباطی USS بدون رسیدگی باقی نماند.
• پس از قطع ارتباط HMI هیچ فرمان حرکتی باقی‌مانده‌ای وجود نداشته باشد.
• پایداری تغذیه فیدبک و شکل موج آن در سراسر مسیر حرکت.
• عملکرد صحیح هر دستگاه مستقل محدودکننده حرکت اضافی.
• تطابق ثبت‌شده میان فرمان، مقدار تنظیمی دریافتی، مقدار تنظیمی فعال و حرکت واقعی.

ثبت‌کننده رویداد را در مراحل اولیه بهره‌برداری تولید حفظ کنید. یک اقدام اصلاحی موفق باید هم علامت فیزیکی و هم الگوی تشخیصی غیرعادی ایجادکننده آن را برطرف کند.

علت ریشه‌ای در جایی آشکار می‌شود که سیگنال‌ها برای نخستین بار با یکدیگر اختلاف پیدا می‌کنند

نباید حرکت ناگهانی متناوب اسلاید در یک سیستم Siemens S7-200 و MASTERDRIVES را بدون شواهد به «نویز»، «انکودر» یا «USS» نسبت داد.

روش تعیین‌کننده، تطبیق فرمان نهایی PLC، فرمان دریافتی درایو، مقدار تنظیمی داخلی فعال و واکنش مکانیکی واقعی است.

اگر فرمان PLC نادرست می‌شود، HMI و منطق برنامه را بررسی کنید. اگر مقدار ارسالی یا دریافتی نادرست می‌شود، مدیریت حافظه، مقیاس‌بندی، ساخت تلگرام و شبکه RS-485 را بررسی کنید.

اگر درایو منبع فرمانی را فعال می‌کند که PLC قصد آن را نداشته است، پیکربندی داخلی درایو را ممیزی کنید. اگر همه فرمان‌ها در حالی که موتور شتاب می‌گیرد ایمن باقی می‌مانند، فیدبک، تغذیه برد کنترل، سخت‌افزار درایو و بخش‌های مکانیکی را بررسی کنید.

خرابی‌های فیدبک همچنان محتمل‌اند، اما باید به‌صورت مدارهای کامل آزمایش شوند. مشکلات USS نیز همچنان محتمل‌اند، اما داده معتبر قدیمی و منطق بازیابی ضعیف، اغلب از تبدیل تصادفی یک تلگرام آسیب‌دیده به فرمان حداکثر سرعت، محتمل‌تر هستند.

ماشین تنها زمانی باید به سرویس عادی بازگردد که حفاظت مستقل مؤثر باشد، سازوکار آغازگر با شواهد ثبت‌شده پشتیبانی شود و آزمون کنترل‌شده هم اقدام اصلاحی و هم واکنش به خطاهای آینده را تأیید کرده باشد.

این رویکرد منضبط به آماده‌سازی بیشتری نسبت به تعویض حدسی قطعات نیاز دارد. همچنین نتیجه‌ای ارزشمندتر به همراه می‌آورد: ماشینی که مسیر حرکت آن درک، ثبت، مستندسازی و در برابر خرابی منفرد بعدی محافظت شده است.