Komunikácia - ovládací panel váh DINI ARGEO DFW06

Pred nedávnom vznikla požiadavka konkrétneho zákazníka nakomunikovať váhy – konkrétne sa jednalo o plošinové váhy Pentimex PREMOVA 60-2-8 a Pentimex PREMOVA 60-3-8 s kapacitou 60 ton slúžiace na váženie nákladných vozidiel. Tieto váhy boli pripojené k ovládaciemu panelu DINI Argeo DFW06, ktorý komunikoval s aplikáciou Cestná váha firmy VTnet na PC cez sériový port. Požiadavkou zákazníka bolo paralelné načítanie dát z váhy do webového rozhrania, ktoré poskytuje naša aplikácia EMS (Energy Management System) postavená na technológii IPESOFT D2000.

Obrázok 1 - aplikácia Cestná váha firmy VTnet

Obrázok 1 - aplikácia Cestná váha firmy VTnet

 

Ako prvú som našiel dokumentáciu k ovládaciemu panelu DINI Argeo DFW06. Z nej vyplývalo, že existuje niekoľko módov, ktorými ovládací panel môže komunikovať. Buď reaguje na výzvy programu a posiela rôzne informácie (včítane naváženej hmotnosti), alebo posiela dáta spontánne, prípadne po stlačení tlačidla.

 

2Obrázok 2 - ovládací panel DINI ARGEO DFW06

 

Posielanie naváženej hmotnosti môže byť v štandardnom alebo rozšírenom formáte. Štandardný formát obsahuje hodnotu (8-miestne číslo s desatinnou bodkou), jednotky a informáciu o stave váhy (napr. stabilizovaná hodnota, príliš veľká alebo príliš malá hmotnosť).

3

Obrázok 3 - popis štandardného formátu z príručky DFW06

Rozšírený formát obsahuje nie jednu ale dve hodnoty (čistá váha a tara – 10 miestne čísla s desatinnou bodkou), počet navážených kusov (pre váhy, ktoré podporujú takúto funkcionalitu) a všetky ostatné dáta, ktoré obsahuje štandardný formát.

 

V móde reagovania na dotazy navyše môže byť aktívny ešte tzv. 485 mód, keď sa predpokladá niekoľko váh pripojených k RS-485 linke (cez prevodník RS-232 na RS-485) a na začiatku dát sa nachádza dvojciferné číslo zariadenia, ktoré musí mať každá váha na linke unikátne. Váha reaguje iba na dotazy, ktoré sú posielané na ňu.

 

Zároveň podporuje ovládací panel rôzne rýchlosti komunikácie cez sériovú linku a rôzne nastavenia parity a počtu bitov na bajt.

 

Na základe informácií z dokumentácie zistili pracovníci zákazníka, že dva z troch ovládacích panelov posielajú dáta spontánne, tretí na výzvu. Vo všetkých prípadoch váhy používajú štandardný formát správ. Komunikačné rýchlosti boli vo všetkých prípadoch 9600 baudov, 8 bitov, 1 stop bit, bez parity.

 

Chcel by som zároveň poďakovať pánovi Juliusovi Pastorekovi – konateľa spoločnosti Pentimex – za to, že promptne odpovedal na moje technické otázky (paralelne s hľadaním dokumentácie k ovládaciemu panelu som napísal e-mail priamo do firmy Pentimex).

 

Ako najjednoduchšie riešenie získania hodnôt sa javí odposluch existujúcej komunikácie. Pomocou sériovej “rozdvojky” sa vyvedú signály TX a GND z ovládacieho panela. Rozdvojku si vyrobil priamo technicky zdatný zákazník a pripojil ju do sériového portu Moxa NPort 5110. Tento obľúbený (a nielen nami) prevodník zákazník následne pripojil na lokálnu sieť. NPort umožňuje prevod sériovej komunikácie na TCP dátový tok, UDP pakety, prípadne vie pracovať v móde virtuálneho portu, keď sa pomocou Moxa ovládačov vytvorí na strane servera virtuálny sériový port (napr. COM99), ktorý reprezentuje konkrétne zariadenie. My uprednostňujeme UDP mód komunikácie – nevyžaduje nadväzovanie spojenia (a teda na rozdiel od TCP módu netrpí problémami s timeoutami pri rôznych sieťových problémoch) ani inštaláciu ovládača na vytvorenie virtuálneho sériového portu (v minulosti sme zažili „zamrznuté“ porty). Navyše sa dá komunikácia ľahko zaznamenávať napr. pomocou nástroja Wireshark.

 

Zákazník mal existujúcu EMS aplikáciu postavenú na IPESOFT D2000 verzie 11.2.57. Bude teda treba implementovať (do novej verzie IPESOFT D2000) nový komunikačný protokol a kvôli tomu aktualizovať aj IPESOFT D2000? Alebo radšej implementujeme protokol ako OEM protokol vo forme dynamickej knižnice (napr. v jazyku C) s využitím KomAPI a vyhneme sa aktualizácii?

 

Aj keď sú obidva prístupy možné, najjednoduchšia a najmenej namáhavá cesta je tretia – použijeme Generic User Protocol, ktorý je určený presne na toto – na rýchlu a jednoduchú implementáciu triviálnych protokolov priamo v prostredí skriptov v IPESOFT D2000, s použitím ESL jazyka. Mimochodom, tento protokol bol implementovaný v roku 2015, takže je dostupný v IPESOFT D2000 od verzie 10.1.39.

 

O Generic User Protocol-e som už písal blog – v ňom boli demonštrované možnosti protokolu na spracovaní dát z GPS prijímača. Komunikácia s váhou nebola o nič komplikovanejšia, akurát sme serverovský skript postavili na štruktúrovaných premenných (takže jeden skript obsluhuje všetky tri váhy) a boli ošetrené aj neplatné vstupy ako aj detekcia rozpadu komunikácie. Pokiaľ za definovaný čas (napr. 5 sekúnd) nepríde k získaniu naváženej hodnoty z komunikácie, je to vyhodnotené ako chyba komunikácie.

 

4

Obrázok 4 - časť ESL skriptu analyzujúceho namerané hodnoty

 

Výhodou použitia ESL skriptov je aj jednoduché ladenie a oprava chýb, prípadne úpravy funkcionality v dôsledku zmien v protokole (napr. novšie verzie protokolu používané v novších váhach môžu obsahovať dodatočné informácie). Všetky zmeny je možné vykonávať online, priamo na produkčnej aplikácii. Zároveň je možné využiť funkcionalitu XML exportu na odzálohovanie jednotlivých verzií skriptu, aby sa v prípade problémov dala dohľadať jeho história a prípadne vrátiť sa ku funkčnej verzii.

 

5

Obrázok 5 - štruktúra použitá pre komunikáciu.

Zvýraznený riadok obsahuje vyextrahovanú váhu, ktorá sa mení niekoľkokrát za sekundu

 

 

Ing. Peter Humaj, www.ipesoft.com

Topics: D2000, communication, komunikacne_protokoly

Za IPESOFT pre Vás napísal

Peter Humaj

Peter Humaj

e-mail: humaj.peter@ipesoft.com