CompactLogix és DeltaV Modbus RTU-n keresztül: A szerepkörök megtervezése
Üzembe helyezésre kész CompactLogix–DeltaV Modbus RTU-útmutató, amely kitér a kliens/szerver szerepkörökre, a regiszterszerződésekre, az RS-485 kiépítésére, ...
A CompactLogix–DeltaV Modbus RTU-kapcsolat mindössze néhány tucat értéket is képes cserélni, mégis az üzem egyik legkevésbé kiszámítható interfészévé válhat. A protokoll egyszerű, a mérnöki határfelület azonban nem az. A legtöbb hiba még a bekötés előtt kezdődik, amikor egyik csapat sem határozza meg, ki küldi a kéréseket, ki kezeli a parancsokat, hogyan jelennek meg a címek, illetve mit tegyen bármelyik rendszer az elavult adatokkal.
A stabil soros integrációhoz egyetlen kérésindító, aláírt regiszterszerződés, egyértelmű minőségi állapotok és megfelelően kialakított RS-485-szegmens szükséges.
Az első tervezési döntés az architektúrára vonatkozik. A DeltaV soros interfészen keresztül kommunikálhat, míg a CompactLogix rendszerhez jellemzően vázba szerelhető kommunikációs modulra vagy külső átjáróra van szükség. Az Emerson DeltaV M-series soros interfész adatlapja dokumentálja a Modbus RTU és a Modbus ASCII támogatását. A telepített rendszer esetében azonban továbbra is ellenőrizni kell a pontos modulverziót, a vezérlő firmware-verzióját, az átjáró firmware-verzióját és a támogatott topológiát.
Szegmensenként jelöljön ki egyetlen kérésindítót
A hagyományos Modbus-terminológia a master és slave kifejezéseket használta. A jelenlegi dokumentáció gyakran kliens és szerver megnevezést alkalmaz. Egy Modbus RTU-szegmensen egy kliens kezdeményezi a tranzakciókat, a szerverek pedig a hozzájuk címzett kérésekre válaszolnak. Két egymástól független kliens nem osztozhat biztonságosan ugyanazon a kétvezetékes törzsvonalon, mert egyikük sem hangolja össze az üzenetek időzítését a másikkal.
Ha a DeltaV a kliens, a CompactLogix oldalának Modbus-szerverinterfészen keresztül kell adatokat biztosítania. A PLC-program jóváhagyott értékeket ír egy átjáró-adatterületre, az átjáró pedig válaszol a DeltaV lekérdezéseire. Ha a PLC-nek kell olvasásokat és írásokat kezdeményeznie, használjon külön portot vagy átjáróútvonalat. Ne feltételezze, hogy egy „Modbus-képesként” leírt eszköz mindkét szerepet egyidejűleg el tudja látni.
A Modbus Organization specifikációs oldala megkülönbözteti a jelenlegi soros megvalósítási útmutatót az elavult, 1996-os dokumentumtól. Ez akkor fontos, amikor egy projektleírás egyszerűen csak azt mondja, hogy „használjunk Modbust”, anélkül hogy meghatározná a fizikai réteget és a megvalósítási szabályokat.
Tekintse a regisztertérképet interfészszerződésnek
A hasznos regisztertérkép több, mint a 4xxxx hivatkozások felsorolása. Minden pontnál meg kell határozni a protokoll-eltolást, a megjelenített hivatkozást, a funkciókódot, az adattípust, a szósorrendet, a bájtsorrendet, a skálázást, a mérnöki mértékegységet, az olvasási vagy írási irányt, az érvényes tartományt, a frissítési időszakot, a forrás tulajdonosát és a hibakezelést. Adjon meg verziószámot és jóváhagyási nyilvántartást is, hogy mindkét rendszer ugyanazt a térképet valósítsa meg.
A címzés külön ellenőrzést érdemel. Egyes konfigurációs eszközök a holdingregisztert 40001-ként jelenítik meg, miközben nulla eltolást küldenek. Mások közvetlenül nullától induló eltolásokat kérnek. Ha a térkép mindkét formát rögzíti, elkerülhető a jól ismert egyregiszteres eltolás. A termelési értékek betöltése előtt teszteljen felismerhető mintával.
A több regisztert használó értékek kezelése ugyanilyen egyértelműséget igényel. Egy 32 bites REAL két 16 bites regisztert foglal el, a termékek azonban eltérhetnek a regiszterek sorrendjében. Teszteljen ismert bitmintákkal ahelyett, hogy olyan címkékre hagyatkozna, mint a „big endian”, amelyeket a csapatok időnként eltérően használnak. A jelölt és előjel nélküli egész számokhoz, a logikai értékek csomagolásához és a skálázott egész értékekhez is dokumentált átalakítási szabályok szükségesek.
Válassza külön a parancsokat, az állapotot és a nyugtázást
Soha ne engedje, hogy egy DCS-írás közvetlenül egy fizikai kimenetre kerüljön. Írja a parancsokat a CompactLogix belsejében egy előkészítő területre. A PLC-nek ellenőriznie kell az üzemmódot, az engedélyező feltételeket, a tartományt, a sorrendet, az adatok frissességét és a tulajdonjogot, mielőtt megváltoztatná a vezérelt állapotot. Ezután adjon vissza elfogadott vagy elutasított állapotot, illetve indoklási kódot.
A parancskézfogás különösen hasznos indítási, leállítási, alapjel- és visszaállítási műveleteknél. A sorszám vagy a váltott kérésbit lehetővé teszi, hogy a fogadó megkülönböztesse az új kérést a regiszterben hagyott értéktől. A nyugtának azonosítania kell a feldolgozott sorszámot és az eredményül kapott állapotot. Így a kommunikáció helyreállása nem ismétel meg egy régi parancsot.
Az RS-485-réteget a tényleges üzemhez alakítsa ki
Csillagtopológia helyett használjon láncolt törzsvonalat. Csak a két fizikai végét terminálja, tartsa röviden a leágazásokat, őrizze meg a vezetők polaritását, és a berendezések kézikönyvei szerint, egyetlen ellenőrzött helyen alkalmazzon előfeszítést. Az árnyékolás földelésének a telephely földelési tervét és az eszközök utasításait kell követnie; a rögtönzött bekötések ahelyett, hogy megszüntetnék a problémákat, közös módusú zavarokat okozhatnak.
Minden csomópontnak ugyanazt az átviteli sebességet, paritást, stopbiteket és keretezési módot kell használnia. A Modbus RTU és a Modbus ASCII nem működhet ugyanazon a szegmensen. Ugyanígy a DF1 sem keverhető egyszerűen egy Modbus-törzsvonalra. A protokollátalakító átjáró két külön hálózatot hoz létre, külön időzítéssel, diagnosztikával és felelősségi körrel.
A lekérdezések időzítéséhez költségvetésre van szükség. Számítsa bele a kérés hosszát, a várt válasz hosszát, az átviteli sebességet, a szerver feldolgozási idejét, a keretek közötti késleltetést, az újrapróbálkozásokat és az időtúllépést. Ahol célszerű, csoportosítsa az összefüggő regisztereket. Egy néma szerver miatt ne kelljen minden működőképes pontnak több hosszú újrapróbálkozást kivárnia. Rögzítse a lekérdezési időt normál körülmények között, valamint egy szerver leválasztott állapotában is.
Minden értékblokk mellett biztosítson minőségi információt
Egy hihető szám veszélyesebb lehet, mint egy nyilvánvaló hiba. Minden cserélt blokknak tartalmaznia kell a kommunikáció állapotát, az utolsó sikeres frissítés idejét, az adatok korát és egy meghatározott elavulási küszöböt. A felhasználóknak tudniuk kell, hogy az érték aktuális, megőrzött, helyettesített vagy érvénytelen.
A tartalék viselkedése a folyamat kockázatától függ. Egyes állapotértékeket kommunikációvesztéskor törölni lehet. Más méréseket a kezelői tájékoztatás érdekében meg lehet őrizni, de az automatikus vezérlésből ki kell tiltani. A parancsoknak biztonságos lezárásra, befagyasztásra vagy helyi tulajdonjogra való átadásra lehet szükségük. Ezeket a döntéseket a veszélyelemzésben kell meghozni, nem az átjáró alapértelmezésére bízva.
Az üzembe helyezést a vezetéktől a folyamatazonos műveletig végezze
Kezdje a hálózattal, a termelési parancsoktól elkülönítve. Ellenőrizze a polaritást, a lezárást, az előfeszítést és a soros beállításokat. Olvasson be egy kis diagnosztikai blokkot, majd teszteljen ismert egész és lebegőpontos mintákat. Ellenőrizze a címek illeszkedését és a szósorrendet. Mérje meg a normál lekérdezési időt, kényszerítsen ki időtúllépéseket, és igazolja, hogy az elavult állapot ott jelenik meg, ahol azt a kezelők és a logika is látják.
Ezután minden parancsot a teljes útvonalán teszteljen: DCS-kérés, átjárón keresztüli átvitel, PLC-s ellenőrzés, kimeneti művelet, visszajelzés és nyugtázás. Vegye fel a tesztek közé az elutasított kéréseket, a tartományon kívüli értékeket, a kommunikáció tranzakció közbeni megszakadását, a ki-be kapcsolást és a helyreállást. Az élő adatok sikeres olvasása nem jelenti a vezérlési interfész elfogadását.
A kapcsolódó interfészhardverek a ProSoft gyűjteményben találhatók. A szélesebb körű irányítórendszeri berendezések a DCS- és irányítórendszerek alatt jelennek meg. A kiválasztást ne önmagában a protokoll neve, hanem a támogatott vezérlő, firmware, port, leválasztás és környezeti követelmények alapján végezze.
Mérnöki szempont
A Modbus RTU továbbra is hasznos a behatárolt, lassan változó adatok cseréjére. Gyengesége a beépített szemantikai környezet hiánya. A protokoll nem tudja jelezni a fogadónak, hogy egy regiszter elavult, egy parancs nem biztonságos, vagy a skála karbantartás után megváltozott. Ezeket a védelmeket a regiszterszerződésbe és az alkalmazási logikába kell beépíteni.
Ezért a legjobb interfész nem az, amelyik a legnagyobb térképpel rendelkezik. Hanem az, amelynek tulajdonjoga, időzítése, minősége, tartalék viselkedése és tesztbizonyítékai évekkel később is érthetők maradnak. Ez alakítja át az egyszerű soros kapcsolatot karbantartható irányítórendszeri határfelületté.