Ako funguje komunikácia - Ethernet/IP v praxi? Tento tutorial vám to ukáže

Pred časom v blogu Komunikácia - Ethernet/IP ste si mohli prečítať o vlastnostiach tohto rozšíreného komunikačného protokolu. Minulý týždeň bolo potrebné rozbehať komunikáciu medzi MES systémom postaveným na technológii D2000 a riadiacim systémom kogeneračnej jednotky u konkrétneho zákazníka. Riadiaci systém je postavený na PLC firmy Rockwell (hlavná riadiaca jednotka triedy ControlLogix 1756 a menšie pomocné jednotky triedy CompactLogix 1769). Takže – ako na komunikáciu?

Zvažovali sme postupne 3 možné cesty:

komunikácia cez OPC DA (OPC Classic). Keďže MES systém je prevádzkovaný na Linuxových serveroch, KOM proces komunikujúci s OPC serverom by musel byť spustený vzdialene (ideálne na počítači, kde je spustený aj OPC server).
komunikácia cez OPC UA. Tento spôsob sa spočiatku javil ako najperspektívnejší, ale nakoniec sa ukázalo, že OPC UA server nie je k dispozícii (či už pre licenčné alebo iné dôvody).
natívna komunikácia Ethernet/IP protokolom.

Chcel by som sa dnes s Vami podeliť o rozbehávanie komunikácie s použitím protokolu Ethernet/IP.

Komunikácia s CompactLogix

Nakomunikovať malé PLC CompactLogix bolo triviálne.

Najskôr bolo vytvoriť linku typu TCP/IP-TCP a zadať IP adresu PLC. Port je 44818, čo je štandardný port protokolu Ethernet/IP:

Na záložke s protokolovými parametrami sme nemenili nič:

Na stanici sme zvolili protokol Ethernet/IP:

a vytvorili textový meraný bod, ktorý vyčítava hodnotu atribútu Product Name inštancie č. 1 triedy Identity Object – čo je názov zariadenia. Na obrázku je vidieť, že komunikujeme so zariadením “1769-L16ER/A LOGIX5316ER”.

Bez problémov fungovalo aj browsovanie – vyčítanie zoznamu symbolických mien zo zariadenia:

Komunikácia s ControlLogix

Rozbehávanie komunikácie s ControlLogix bolo o čosi dobrodružnejšie. Začali sme tiež konfiguráciou linky – zadaním IP adresy a portu:

V parametroch linky sme zapli optimalizáciu práce so symbolickými menami. Optimalizácia spôsobí, že symbolické mená sa prevedú na čísla inštancií, ktoré sú jednak kratšie a jednak s nimi vie PLC pracovať rýchlejšie. PLC triedy ControlLogix na rozdiel od CompactLogix optimalizáciu podporujú.

Nakonfigurovali sme stanicu a priamo začali s konfiguráciou meraných bodov so symbolickými adresami, ktoré boli dohodnuté. Ale nepodarilo sa nám ich načítať. Dotazy vracali chybu “General Status = Path destination unknown [x05]”, ktorá znamená, že také symbolické meno sa v zariadení nenachádza.

Nefungovalo ani browsovanie – pri snahe o čítanie attribútu Object_list z inštancie 1 triedy Message Router Object sme dostávali chybu “General status: Attribute not supported [x14]”.

Nedá sa ale povedať, že nefungovalo nič – po nakonfigurovaní meraného bodu, ktorý vyčítava hodnotu atribútu Product Name, sme dostali korektnú odpoveď – komunikujeme s 1756-EN2TR-C, čo je “ControlLogix EtherNet/IP bridge Module”.

Spočiatku sme podozrievali nejake bezpečnostné nastavenie (podobne, ako Simatic S7-1200 a S7-1500 potrebujú explicitne povoliť prístup treťostranných produktov). Ale dodávateľ technológie nás uistil, že nič také tam zapnuté nie je.

Po dlhšom (a neúspešnom) laborovaní sme pomocou WireShark-u urobili záznam funkčnej komunikácie medzi PLC a Rockwell programom ABCIP.exe, ktorý zrejme slúži ako ekvivalent D2000 KOM procesu (a poskytuje dáta Rockwell OPC serveru).

Najskôr sme zistili, že protokolové správy (Read Tag Service) sú balené do správy Multiple Service Packet Service. Táto správa je určená na optimalizáciu výkonu –do jedného dotazu je možné zabaliť viacero správ.

Takže sme pokračovali implementovaním parametra stanice Use Multiple Service Packet Service, ktorý by riadil balenie správ. V priebehu dňa bola funkcionalita vyvinutá a otestovaná voči CompactLogix, ktorý tieto správy takisto dokázal spracovať. Nasadenie patchu u zákazníka ale prinieslo sklamanie – ControlLogix stále vracal chyby, tentokrát “General Status = Service not supported [x08]”. To vyzeralo, akoby správu Multiple Service Packet Service ani nepodporoval!

Takže sme sa pozreli na záznam komunikácie detailnejšie.

Jednak sme si všimli, že na rozdiel od D2000 KOM procesu, ktorý posiela správy ako Unconnected messages, používa ABCIP.exe Connected messages (čo vyžaduje najskôr nadviazať “spojenie” – táto funkcionalita v D2000 KOM procese nie je implementovaná, keďže doteraz nebola potrebná).

Čo bolo dôležitejšie, pri nadväzovaní komunikácie bolo vidieť pakety typu Unconnected Send, ktoré umožňujú zabaliť iný paket a smerovať ho na konkrétnu “adresu”. Pričom adresa môže byť napr. komunikačný port zariadenia a adresa cieľového zariadenia (napr. sériový port + MAC adresa zariadenia na sériovej linke alebo Ethernet port + IP adresa cieľa).

V tomto konkrétnom prípade bola cieľová adresa 01, čo podľa normy znamená “back-plane port”. (V skutočnosti bola adresa 01 00, ale druhý bajt slúžil ako vypchávka – padding – keďže adresa musí mať párny počet bajtov).

V tomto bode sme začali chápať príčinu problémov. PLC ControlLogix je zrejme modulárne – a keďže sme priamo pripojení na komunikačný modul, až zadaním adresy “back-plane port” sa dostaneme na centrálny procesor. Bez explicitného smerovania sa bavíme iba s komunikačným modulom, ktorý nepozná žiadne symbolické mená, nepodporuje browsovanie .. pozná iba pár objektov, ktoré vyžaduje norma.

Takže sme pokračovali implementovaním parametra stanice Route Path for Unconnected Send, ktorý by umožňoval zadanie cesty. Pokiaľ je tento parameter zadaný, správy na čítanie resp. zápis hodnôt sa zabalia do obálky Unconnected Send a pošlú na špecifikovanú cestu.

Po implementácii sme nastavili parameter na hodnotu 01 00 a napäto čakali na výsledok.

‍

Bingo! Merané body so symbolickými adresami ožili hodnotami.

Na obrázku je vidieť, že meraný bod M..ProductName má hodnotu „1756-L85E/B“ – čo zodpovedá „Allen-Bradley 1756-L85E Logic Controller“. Takže už nekomunikujeme s komunikačným modulom, ale s hlavným procesorom PLC.

Prečo sme parameter Route Path for Unconnected Send implementovali na úrovni stanice a nie na úrovni linky? Takto môžme v rámci jednej linky vytvoriť viacero staníc a komunikovať s centrálnym procesorom, s komunikačným modulom a prípadne aj s ďalšími modulmi, ktoré sa nachádzajú v rámci modulárneho PLC, prípadne so zariadeniami, ktoré sa nachádzajú za PLC!

V skutočnosti sme neskôr potrebovali komunikovať aj s pomocným procesorom umiestneným v slote 1, pre ktorý sme vytvorili ďalšiu stanicu s hodnotou parametra Route Path for Unconnected Send rovnou “01 01”.

Fungovalo aj browsovanie – na rozdiel od CompactLogixu, ktorý mal zadefinovaných iba 33 symbolických tagov, ControlLogix ich mal takmer šesť tisíc.

Záver

Podpora routovania pre protokol Ethernet/IP, ktorá je potrebná pre komunikáciu s ControlLogix, bola implementovaná vo verzii 12.0.60 a je dostupná na požiadanie vo forme patchov (cnf.exe a kom.exe). Veríme, že ďalšie rozširovanie možností KOM procesu uvítajú nielen kolegovia v Ipesofte, ale aj naši OEM partneri a zákazníci. Konkrétne vylepšenie protokolu Ethernet /IP umožňuje prístup na PLC triedy ControlLogix priamo z D2000 (či už na platfome Windows, Linux alebo Raspberry PI), bez potreby kupovania ďalšieho komunikačného softvéru (napr. OPC Classic alebo OPC UA servera).