یک لینک Modbus RTU بین CompactLogix و DeltaV می‌تواند تنها چند ده مقدار را مبادله کند و همچنان به یکی از غیرقابل‌پیش‌بینی‌ترین رابط‌ها در یک کارخانه تبدیل شود. پروتکل ساده است؛ مرز مهندسی چنین نیست. بیشتر خرابی‌ها پیش از سیم‌کشی آغاز می‌شوند؛ زمانی که هیچ‌یک از تیم‌ها مشخص نکرده‌اند چه کسی درخواست‌ها را ارسال می‌کند، مالک فرمان‌ها چه کسی است، آدرس‌ها چگونه نمایش داده می‌شوند، یا هر سیستم در برابر داده‌های قدیمی چه رفتاری باید داشته باشد.

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

نخستین تصمیم طراحی، معماری است. DeltaV ممکن است از طریق یک رابط سریال ارتباط برقرار کند، در حالی که CompactLogix معمولاً به یک ماژول ارتباطی داخل شاسی یا یک درگاه خارجی نیاز دارد. برگه اطلاعات رابط سریال سری M دلتاوی پشتیبانی از Modbus RTU و Modbus ASCII را مستند کرده است. بااین‌حال، نسخه دقیق ماژول، میان‌افزار کنترلر، میان‌افزار درگاه و توپولوژی پشتیبانی‌شده همچنان باید برای سیستم نصب‌شده تأیید شوند.

برای هر بخش سریال، یک آغازگر درخواست تعیین کنید

در اصطلاحات سنتی Modbus از master و slave استفاده می‌شد. در مستندات امروزی اغلب از client و server استفاده می‌شود. در یک بخش Modbus RTU، یک کلاینت تراکنش‌ها را آغاز می‌کند و سرورها به درخواست‌هایی که به آن‌ها آدرس‌دهی شده است پاسخ می‌دهند. دو کلاینت مستقل نمی‌توانند به‌طور ایمن یک خط دوسیمه مشترک را به اشتراک بگذارند، زیرا هیچ‌یک زمان‌بندی پیام‌ها را با دیگری هماهنگ نمی‌کند.

اگر DeltaV کلاینت باشد، سمت CompactLogix باید داده‌ها را از طریق یک رابط سرور Modbus ارائه کند. برنامه PLC مقادیر تأییدشده را در ناحیه داده درگاه می‌نویسد؛ درگاه به درخواست‌های پیمایش DeltaV پاسخ می‌دهد. اگر PLC باید خواندن و نوشتن‌ها را آغاز کند، از یک پورت یا مسیر جداگانه درگاه استفاده کنید. فرض نکنید تجهیزی که «قابلیت Modbus» دارد می‌تواند هر دو نقش را هم‌زمان انجام دهد.

صفحه مشخصات سازمان Modbus راهنمای فعلی پیاده‌سازی سریال را از سند منسوخ‌شده سال ۱۹۹۶ متمایز می‌کند. این تمایز زمانی اهمیت دارد که مشخصات پروژه صرفاً بگوید «از Modbus استفاده کنید» و لایه فیزیکی و قواعد پیاده‌سازی را مشخص نکند.

نقشه ثبات‌ها را به‌عنوان قرارداد رابط در نظر بگیرید

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

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

مقادیر چندثباتی نیز به همین اندازه به مدیریت صریح نیاز دارند. یک REAL ۳۲بیتی دو ثبات ۱۶بیتی را اشغال می‌کند، اما محصولات در ترتیب ثبات‌ها با یکدیگر تفاوت دارند. الگوهای بیتی شناخته‌شده را آزمایش کنید و تنها به برچسب‌هایی مانند «big endian» تکیه نکنید؛ زیرا تیم‌ها گاهی این اصطلاح را به شکل‌های متفاوتی به کار می‌برند. قواعد تبدیل برای اعداد صحیح علامت‌دار، اعداد صحیح بدون علامت، بسته‌بندی بولی و مقادیر صحیح مقیاس‌شده نیز باید مستند شوند.

فرمان‌ها، وضعیت و تأیید را از هم جدا کنید

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

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

لایه RS-485 را برای شرایط واقعی کارخانه بسازید

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

همه گره‌ها باید نرخ بود، زوجیت، بیت‌های توقف و حالت فریم‌بندی یکسانی داشته باشند. Modbus RTU و Modbus ASCII نمی‌توانند در یک بخش مشترک وجود داشته باشند. DF1 نیز نمی‌تواند به‌سادگی روی یک خط Modbus ترکیب شود. یک درگاه مبدل پروتکل، دو شبکه جداگانه ایجاد می‌کند که هرکدام زمان‌بندی، عیب‌یابی و مسئولیت جداگانه دارند.

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

کیفیت را در کنار هر بلوک مقدار ارائه کنید

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

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

راه‌اندازی را از سیم تا اقدام فرایندی انجام دهید

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

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

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

دیدگاه مهندسی

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

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