info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
1.4.2026
Komunikácia - Ethernet/IP a práca so štruktúrami
Komunikácia - Ethernet/IP a práca so štruktúrami
V dnešnom blogu sa pozrieme na komunikačný protokol Ethernet/IP, resp. na jeho proprietárne služby implementované firmou Rockwell pre obsluhu PLC tried ControlLogix a CompactLogix a ako vedia pracovať so štruktúrami. A, samozrejme, čo dokáže implementácia v Ipesoft D2000.
Šablóna (Template) resp. UDT (User-Defined Type) v PLC rodine ControlLogix/CompactLogix je kľúčový mechanizmus na štruktúrovanie dát — veľmi podobný struct v jazykoch C/C++. Umožňuje zadefinovať v prostredí nástroja Studio 5000 štruktúrovaný typ dát, ktorý sa skladá z jednoduchých typov (napr. BOOL, SINT, DINT), polí (napr. BOOL ARRAY, INT ARRAY) a ďalších štruktúrovaných typov.
Následne programátor vytvorí premenú (často sú to viaceré premenné) takéhoto typu a používa ju.
Príklad definície UDT:
TYPE MOTOR :
STRUCT
Speed : REAL;
Current : REAL;
Running : BOOL;
FaultCode : DINT;
END_STRUCT;
END_TYPE
Nás zaujíma pochopiteľne práca s UDT a ich členmi z pohľadu komunikácie. Dobrá správa je, že každú položku štruktúry je možné adresovať samostatne a vytvoriť tak meraný bod, ktorý pristupuje priamo k jednoduchému typu alebo poľu:
Na obrázku si môžete okrem adresy (symbolického mena FIRQ101.OutOfRange) všimnúť, že hodnota parametra Attribut type je nastavená na NONE/AUTO. Znamená to, že typ hodnoty nie je explicitne udaný, ale zistí sa pri čítaní člena OutOfRange štruktúry FIRQ101.
Aká je nevýhoda čítania po jednotlivých členoch? Môže ňou byť rýchlosť komunikácie. Pokiaľ potrebujeme vyčítavať viaceré členy UDT, prečítanie celej štruktúry môže byť rýchlejšie ako vyčítavanie jednotlivých členov. Samozrejme, záleží na mnohých okolnostiach (výkonnosti a zaťažení PLC a komunikačného počítača, rýchlosti siete, veľkosti UDT a množstve vyčítavaných členov), kedy je optimálne čítať celý UDT a kedy je lepšie pristupovať k jednotlivým položkám. D2000 sa (zatiaľ) nesnaží o heuristiku, ale necháva konfiguráciu na užívateľovi.
Pokiaľ je v meranom bode nakonfigurované aktívne čítanie (parameter Reading mode má hodnotu Active read), číta sa hodnota meraného bodu priamo (člen štruktúry). Pokiaľ je nakonfigurované pasívne čítanie, keď príde hodnota celej štruktúry, tak sa vyparsuje príslušný člen a nastaví sa hodnota meraného bodu. Aby sa čítala celá štruktúra, je nutné vytvoriť samostatný meraný bod pre štruktúru, ktorý bude mať nastavené aktívne čítanie:
Takýto meraný bod nenadobúda hodnotu, ale slúži iba na vybudenie čítania.
Mimochodom, je nutné povedať, že nie každú štruktúru je možné vyčítať priamo. Ak štruktúra obsahuje vnútorné dátové štruktúry (napr. má členy typu TIMER, COUNTER, CONTROL, MESSAGE, MOTION), ku ktorým nie je povolený symbolický prístup, čítanie celej štruktúry zlyhá.
Čitateľovi asi ihneď napadne otázka: ako sa pri čítaní štruktúry zisťujú jednotlivé členy a ich typy – a ako sú v správe organizované?
Odpoveď ponúka Rockwell v dokumente Logix 5000 Controllers Data Access. Odporúča nasledovný postup:
1. Zistenie zoznamu tagov (objektov). Toto sa robí službou Get_Instance_Attribute_List a výsledkom je zoznam objektov a ich typov (jednoduchý typ, pole alebo template). Ak je typ štruktúrovaný (template), obsahuje odpoveď aj 12-bitové TemplateID (identifikátor príslušného UDT).
2. Zistenie atribútov UDT. Na to je určená služba Get_Attribute_List, ktorá pre zadané TemplateID vráti:
• Structure Handle (niečo ako CRC, ktoré sa mení so zmenou štruktúry UDT)
• Počet členov štruktúry
• Veľkosť definície UDT
• Veľkosť dát štruktúry (pri čítaní)
3. Zistenie štruktúry UDT pomocou služby ReadTag. Číta sa (podľa veľkosti definície UDT aj na viackrát) zoznam členov UDT – ich mená, typy, veľkosti a offsety v rámci štruktúry. Pokiaľ je člen typu štruktúra (tj. jedná sa o UDT vnorený v inom UDT), je nutné zopakovať body 2 a 3 pre tuto vnorenú štruktúru.
Tento postup je pomerne komplikovaný a náročný. Výsledkom je zoznam aj niekoľko desiatok tisíc štruktúr a ich položiek, ktorého získanie môže trvať desiatky sekúnd. Z tohto dôvodu sme zaviedli cachovanie tejto informácie v D2000. Pokiaľ je aktívny parameter stanice Optimize Structure Read a zisťujú sa detaily štruktúr a UDT, do textového súboru v podadresári Cache aplikačného adresára sa uložia informácie o šablónach, ich členoch, štruktúrach a všetkých symboloch. Ak je pri štarte komunikačného procesu (alebo pri uložení komunikačnej stanice) nájdený cache súbor, informácie sa čítajú z neho. Ak nie, informácie sa čítajú z PLC.
Práca s UDT bola podporená aj v browser dialógu v D2000 Cnf. Pri konfigurácii adresy meraného bodu je možné vyhľadať štruktúru alebo člen štruktúry v zozname. Zoznam bol rozšírený o stĺpec Comment, ktorý obsahuje informácie o template (meno, TemplateID) , offsete člena v rámci štruktúry a prípadne o bitovom offsete BOOL premennej.
Nasledujúci screenshot ukazuje zoznam meraných bodov so symbolickými adresami, ktoré udávajú členov štruktúry s menom HSAOC109, pričom všetky s výnimkou samotnej štruktúry v prvom riadku sú čítané pasívne (R=1). Vpravo je browsovací dialog, v ktorom sú vyfiltrované položky štruktúry HSAOC109.
Aká je skúsenosť z praxe? Práca s čítaním celej štruktúry niekoľkonásobne zrýchlila čítací cyklus starého CompactLogixu (firmware z roku 2005), ktorý nepodporoval žiadne ďalšie optimalizácie podporené v D2000 (Multiple Service Packet Service, Symbol Instance ID, Connected Messages).
Záver
Podpora práca so šablónami a UDT je ďalším vylepšením v D2000 KOM procese, ktoré uvítajú ľudia používajúci PLC triedy CompactLogix a ControlLogix. Okrem zrýchlenia komunikácie uľahčuje konfiguráciu tým, že umožňuje zobrazovať členov štruktúr v browser dialógu D2000 Cnf a vkladať ich do adries meraných bodov.
27.3.2026, Ing. Peter Humaj, www.ipesoft.com
Iné blogy