Проектиране на ролите при Modbus RTU връзка между CompactLogix и DeltaV

Връзката CompactLogix към DeltaV по Modbus RTU може да обменя само няколко десетки стойности и въпреки това да се превърне в един от най-непредвидимите интерфейси в предприятието. Протоколът е прост; инженерната граница не е. Повечето повреди започват още преди окабеляването, когато нито един от екипите не е определил кой изпраща заявките, кой управлява командите, как се представят адресите или какво трябва да прави всяка система с остарели данни.

Стабилната серийна интеграция изисква един инициатор на заявките, подписан регистров договор, изрично дефинирани състояния на качеството и правилно изграден сегмент RS-485.

Първото проектно решение е архитектурно. DeltaV може да комуникира чрез сериен интерфейс, докато CompactLogix обикновено се нуждае от комуникационен модул в шасито или външен шлюз. Информационният лист за серийния интерфейс от серия M на DeltaV на Emerson документира поддръжка на Modbus RTU и Modbus ASCII. Точната ревизия на модула, фърмуерът на контролера, фърмуерът на шлюза и поддържаната топология все пак трябва да бъдат потвърдени за инсталираната система.

Определете един инициатор на заявките за всеки сериен сегмент

Традиционната терминология на Modbus използваше „главно устройство“ и „подчинено устройство“. В съвременната документация често се използват „клиент“ и „сървър“. В сегмент Modbus RTU един клиент инициира транзакциите, а сървърите отговарят на заявките, адресирани към тях. Два независими клиента не могат безопасно да споделят един и същ двупроводен магистрален кабел, защото никой от тях не синхронизира времето на съобщенията с другия.

Ако DeltaV е клиентът, страната на CompactLogix трябва да предоставя данните чрез интерфейс на Modbus сървър. Програмата на PLC записва одобрените стойности в област от данни на шлюза; шлюзът отговаря на заявките от DeltaV. Ако PLC трябва да инициира четения и записи, използвайте отделен порт или път през шлюза. Не приемайте, че устройство, описано като „съвместимо с Modbus“, може едновременно да изпълнява и двете роли.

Страницата със спецификациите на Modbus Organization разграничава актуалното ръководство за серийната реализация от остарелия документ от 1996 г. Това има значение, когато проектната спецификация просто казва „използвайте Modbus“, без да посочва физическия слой и правилата за реализация.

Третирайте регистровата карта като договор за интерфейса

Полезната регистрова карта е повече от списък с препратки 4xxxx. За всяка точка трябва да бъдат определени протоколното отместване, показваната препратка, кодът на функцията, типът данни, редът на думите, редът на байтовете, мащабирането, инженерната единица, посоката на четене или запис, допустимият диапазон, периодът на обновяване, собственикът на източника и поведението при отказ. Включете номер на ревизията и запис за одобрение, за да гарантирате, че и двете системи използват една и съща карта.

Адресирането заслужава отделна проверка. Някои конфигурационни инструменти показват регистър за задържане 40001, докато предават отместване нула. Други изискват директно отмествания, започващи от нула. Карта, която записва и двете форми, предотвратява познатото разместване с един регистър. Тествайте разпознаваем шаблон, преди да заредите производствени стойности.

Многорегистровите стойности изискват също толкова ясна спецификация. 32-битов REAL заема два 16-битови регистъра, но различните продукти използват различен ред на регистрите. Тествайте известни битови шаблони, вместо да разчитате на обозначения като „big endian“, които различните екипи понякога използват по различен начин. Знаковите и беззнаковите цели числа, пакетирането на булеви стойности и мащабираните целочислени стойности също се нуждаят от документирани правила за преобразуване.

Разделяйте командите, състоянието и потвърждението

Никога не позволявайте запис от DCS да управлява директно физически изход. Записвайте командите в междинна област в CompactLogix. PLC трябва да проверява режима, разрешаващите условия, диапазона, последователността, актуалността и собствеността, преди да промени управляваното състояние. След това трябва да връща състояние „прието“, състояние „отхвърлено“ или код на причината.

Ръкостискането на командите е особено полезно за действия като стартиране, спиране, задаване на стойност и нулиране. Пореден номер или превключващ бит на заявката позволява на приемника да различи нова заявка от стойност, останала в регистъра. Потвърждението трябва да посочва обработената последователност и полученото състояние. Така се предотвратява повторното изпълнение на стара команда при възстановяване на комуникацията.

Изградете слоя RS-485 за реалните условия в предприятието

Използвайте магистрален кабел с последователно свързване, а не звездообразна топология. Терминирайте само двата физически края, поддържайте къси отклоненията, спазвайте полярността на проводниците и приложете поляризация на едно контролирано място съгласно ръководствата на оборудването. Заземяването на екрана трябва да следва проектното решение за заземяване на обекта и инструкциите на устройствата; импровизираните връзки могат да създадат проблеми с общия режим, вместо да ги отстранят.

Всеки възел трябва да използва еднакви скорост на предаване, четност, стопови битове и режим на кадриране. Modbus RTU и Modbus ASCII не могат да съществуват едновременно в един и същ сегмент. DF1 също не може просто да се смеси в магистрала Modbus. Шлюзът за преобразуване на протоколи създава две отделни мрежи с различни времеви параметри, диагностика и отговорности.

Времето за запитване трябва да бъде изчислено. Включете дължината на заявката, очакваната дължина на отговора, скоростта на предаване, времето за обработка от сървъра, паузата между кадрите, повторните опити и таймаута. Където е практично, групирайте съседни регистри. Мълчалив сървър не бива да принуждава всяка изправна точка да чака няколко дълги повторни опита. Записвайте времето за сканиране при нормални условия и при изключен един сървър.

Предоставяйте качеството заедно с всеки блок от стойности

Правдоподобното число може да бъде по-опасно от очевидната повреда. Всеки обменян блок трябва да включва състоянието на комуникацията, времето на последния успешен обмен, възрастта на данните и определен праг за остаряване. Потребителите трябва да знаят дали стойността е актуална, запазена, заместена или невалидна.

Резервното поведение зависи от риска за процеса. Някои статусни стойности може да се изчистват при загуба на комуникация. Други измервания може да се запазват за информация на оператора, но да се блокират за автоматично управление. Командите може да трябва да се изпълняват при безопасно затворено състояние, да се замразяват или да предават управлението към локален оператор. Тези решения принадлежат на анализа на опасностите, а не на настройките по подразбиране на шлюза.

Въвеждайте в експлоатация от кабела до действието в процеса

Започнете с мрежа, изолирана от производствените команди. Проверете полярността, терминирането, поляризацията и серийните настройки. Прочетете малък диагностичен блок, след което тествайте известни шаблони за цели и стойности с плаваща запетая. Потвърдете подравняването на адресите и реда на думите. Измерете нормалното време за сканиране, предизвикайте таймаути и потвърдете, че статусът за остарели данни се появява там, където операторите и логиката могат да го видят.

След това тествайте всяка команда по целия ѝ път: заявка от DCS, прехвърляне през шлюза, проверка от PLC, действие на изхода, обратна връзка и потвърждение. Включете отхвърлени заявки, стойности извън допустимия диапазон, загуба на комуникация по време на транзакция, изключване и включване на захранването и възстановяване. Успешното прочитане на текущи данни не означава, че интерфейсът за управление е приет.

Подходящият интерфейсен хардуер е представен в колекцията ProSoft. По-широк набор оборудване за хост системи ще намерите в DCS и системи за управление. Изборът трябва да се основава на поддържаните контролер, фърмуер, порт, изолация и изисквания към средата, а не само на името на протокола.

Инженерна перспектива

Modbus RTU остава полезен за обмен на ограничен обем бавно променящи се данни. Неговата слабост е липсата на вграден семантичен контекст. Протоколът не може да каже на приемника, че даден регистър е остарял, че команда е опасна или че мащабирането е променено след техническо обслужване. Тези защити трябва да бъдат проектирани в регистровия договор и приложната логика.

Следователно най-добрият интерфейс не е този с най-голямата карта. Това е интерфейсът, чиито собственост, времеви параметри, качество, резервно поведение и доказателства от изпитванията остават разбираеми и след години. Именно това превръща простата серийна връзка в поддържана граница на система за управление.