Nejčastěji používaným komunikačním driverem v PLC Domat je Modbus RTU nebo TCP. Může se stát, že u rozsáhlejších projektů začneme narážet na limity systému, ať už na straně klienta (PLC) nebo serveru, kterým může být například čidlo, komunikační převodník, frekvenční měnič, fotovoltaický střídač nebo Modbus TCP / RTU router. Podívejme se, jak driver pracuje a jak komunikaci optimalizovat v případě, že potřebujeme zaintegrovat desítky nebo stovky zařízení.
Počet Modbus TCP kanálů v PLC není omezen počtem fyzických portů, jako je tomu u Modbus RTU komunikace. Každý Modbus TCP kanál představuje pro procesor jedno vlákno. Jelikož v PLC jsou vlákna zpracovávána postupně, nemá smysl dělit zařízení (devices) do více Modbus TCP kanálů. Jen by se tím mírně zvýšila režie pro přepínání mezi vlákny, na rychlost zpracování by to nemělo vliv. Pokud k tomu tedy není zvláštní důvod, v PLC by měl být jediný Modbus TCP kanál, v němž budou umístěna všechna Modbus TCP zařízení.
Různá zařízení mají obvykle různé IP adresy. Každé zařízení (device) navazuje na svou adresu samostatné TCP spojení. Runtime může otevřít až cca. 15 000 odchozích TCP portů (operační systém přiděluje porty v rozsahu 49152 - 65535). Zde tedy omezení nenastane.
V případě, že by více zařízení na jednom kanálu mělo stejnou IP adresu, jejich dotazy se slučují do jednoho TCP spojení. Modbus TCP server tedy není přetěžován několika „paralelními“ TCP spojeními, což je v souladu s požadavkem MODBUS Messaging Implementation Guide V1.0b (2006), kapitola 4.2, TCP Connection Management:
3) It is recommended for a MODBUS Client to open a minimum of TCP connections with a remote MODBUS server (with the same IP address). One connection per application could be a good choice.
Pozor, toto automatické sloučení nemusí nastat, pokud by jedno zařízení mělo nastavenou IP adresu v číselném tvaru (např. 192.168.1.51) a druhé by mělo vyplněno doménové jméno (např. inv1.pvplant.lan), které by PLC muselo přeložit – byť na tutéž IP adresu – pomocí DNS protokolu.
Pokud by ovšem zařízení se stejnými IP adresami byla umístěna na různých Modbus TCP kanálech, které – jak řečeno výše – pracují v různých vláknech, k tomuto sloučení nedojde a každé vlákno navazuje na příslušnou IP adresu samostatné TCP spojení. To by mohlo představovat omezení pro některé Modbus TCP servery, které přijmou jen omezený počet TCP spojení (například jen jediné).
Ano, někdy můžeme kvůli přehlednosti umístit různé proměnné do různých zařízení. Například u FV střídačů můžeme mít standardní zařízení pouze pro čtení hodnot (monitoring) a jiné zařízení s proměnnými pro občasné nastavení střídače či řízení činného výkonu a účiníku. U instalací, kde je vyžadován pouze monitoring, použijeme jen zařízení pro monitoring, zatímco u řízených střídačů vložíme do kanálu i zařízení s proměnnými pro řízení.
Po startu programu se PLC pokusí otevřít všechna TCP spojení a následně vysílá telegramy pro každé zařízení v tom pořadí (odshora dolů), v jakém jsou zařízení vložena do kanálu. V rámci zařízení je od verze 2.7.x.x je možné ručně určit pořadí komunikace skupin změnou parametru Sort Order ve vlastnostech skupiny.
Jsou-li položky Sort Order duplicitní (ve výchozím stavu tomu tak je, všechny mají hodnotu 0), telegramy jsou vysílány v tom pořadí, v jakém byly skupiny zakládány.
Ačkoliv je u Modbusu TCP teoreticky možné „rozehrát“ více dotazů (transakcí) najednou a čekat, až se odpovědi začnou vracet, v PLC je driver implementován tak, že v jednom TCP streamu (tedy v komunikaci na jednu IP adresu) je další dotaz odeslán až poté, co přijde odpověď na dotaz předchozí. Na následujícím příkladu vidíme komunikaci se dvěma servery na různých IP adresách. IP adresy sice nejsou ve výpisu vidět, protože port monitor zobrazuje jen aplikační vrstvu Modbus a ne celou IP komunikaci (ta by byla vidět např. v programu Wireshark), nicméně servery odlišíme podle různých Modbus linkových adres: 01 a 03. Sloupec s linkovou adresou je označen červenou šipkou.
Vidíme, že řada Transaction ID, první dva bajty, je unikátní pro každou z IP adres (tedy pro každý TCP stream). Ve výpisu totiž najdeme dvě nezávislé sekvence Transaction ID. Dotaz je nejprve vyslán na první server (řádek 1), pak na druhý (řádek 2), z toho se ihned vrátí odpověď (řádek 3) a tudíž je na tento server okamžitě vyslán dotaz další – s Transaction ID 00 01 – a vzápětí přijata i odpověď (řádky 4 a 5). Teprve potom dorazí odpověď z prvního serveru (řádek 6). Ta je ovšem díky příslušnému TCP vláknu (a Transaction ID) spárována s dotazem ze řádku 1.
Tato poměrně netypická komunikace vypadá takto díky umělému zpoždění odpovědi prvního serveru na 1000 ms. V praxi bychom viděli podobné chování pouze v případě, že by například jeden ze serverů byl umístěn za částí síťové infrastruktury, která by do komunikace vnášela značnou latenci.
Při komunikaci s Modbus TCP / RTU routerem musíme počítat s tím, že sériová linka nemá zdaleka takovou propustnost jako Modbus TCP na síti Ethernet. Kromě toho, že nesmíme překročit maximální počet současně připojených klientů (což je vlastnost „síťové strany“ routeru), bývá v případě připojení více klientů nutné prodloužit timeout a zejména mezery mezi telegramy. Platí to zejména tehdy, dotazujeme-li se na desítky registrů najednou (optimalizuje to provoz na sběrnici, ale odpovědi jsou pak delší, pakety nelze tolik „rozsekat“ a tím se zvyšuje riziko, že nebude čas na vyřízení dotazu před uplynutím timeoutu). Například tam, kde u jediného klienta postačí 200 ms, při připojení dalšího klienta může původní komunikace začít vypadávat – „koktat“. V programu Wireshark by chyba vypadala takto:
Spojení na router („gateway“) je v pořádku, některé telegramy projdou, ale u jiných router odpovídá, že nemohl komunikovat s Modbus RTU serverem na sériové lince.
Obvykle se problém dá vyřešit
Zvyšovat fyzickou komunikační rychlost na sériové straně, např. z 9600 na 115200 bps, obvykle příliš nepomůže, resp. nevýhody, jako pracnost přenastavení, odklon od výchozích hodnot či riziko problémů při větších délkách linky, převáží nad případnými benefity v podobě časově kratších telegramů.
Když Modbus server neodpovídá, u sériového portu vidíme odcházející telegramy – dotazy, ale místo odpovědí port monitor vypisuje timeouty. Dává nám to celkem jasnou informaci o tom, že PLC vysílá dotazy na sériový port, a můžeme začít pátrat, proč cílové zařízení nereaguje.
V případě Modbus TCP kanálu komunikace probíhá tak, že runtime nejprve naváže TCP spojení a teprve po otevření TCP kanálu po něm začne vysílat dotazy. Pokud tedy u Modbus TCP kanálu nevidíme odchozí dotazy, nemusí to být chyba Modbus TCP driveru – jen se nepodařilo otevřít TCP spojení. Příčinou může být nedostupná IP adresa zařízení nebo nefunkční služba Modbus serveru, případně chybně zadaný TCP port. Doporučuje se ověřit funkci Modbus TCP serveru nějakým nezávislým Modbus klientem, např. ModComTool, Modbus Poll, ModScan a podobně. Pozor, testovacího Modbus klienta obvykle spouštíme na pracovním notebooku a ne na PLC, jehož driver nekomunikuje. Pakliže testovací Modbus klient problém nemá a PLC ano, prověřme, zda v síti nejsou bezpečnostní omezení, která blokují komunikaci mezi IP adresami PLC a Modbus serveru.
Možnost nastavit interval dotazování najdeme na třech místech:
Vlastnosti kanálu – Pauza mezi telegramy: Tímto parametrem je řízeno skutečné (fyzické) vysílání na sběrnici. Dotazy, čekající ve výstupním bufferu, se posílají na sběrnici v tomto intervalu. Na lince se neobjeví telegramy častěji, než je nastaveno zde. Delší interval než 0 ms se nastavuje v případě, že linka nebo zařízení z nějakých důvodů nejsou schopny zpracovat dotazy jdoucí bezprostředně za sebou, nebo že zařízení potřebuje například při zápisovém telegramu nějaký čas na zpracování dat a pak teprve je schopno přijmout další dotaz. To je obvykle popsáno v dokumentaci k zařízení.
Pokud je nastaven interval 0 ms, pauza mezi odpovědí a dalším dotazem je dána možnostmi PLC; obvykle představuje 40 – 50 ms. V ideálním případě se tak přenese cca. 12 – 15 dotazů za sekundu.
Vlastnosti zařízení – Interval čtení / zápis: Hodnota určuje, jak často se budou zapisovat dotazy ze skupin tohoto zařízení do výstupního bufferu komunikačního driveru. Parametr platí pro každou skupinu v zařízení: pokud například máme v zařízení 4 skupiny a ve Vlastnostech zařízení interval 1 s, za sekundu zařízení vyšle 4 dotazy. Lze využít v případě, že některá zařízení mají být v komunikaci upřednostněna (řízení výstupů, omezení střídačů) nebo naopak upozaděna (například odečty energií z elektroměru vůči čtení měřených teplot).
Vlastnosti skupiny – Interval čtení / zápis: Zde lze ještě omezit frekvenci čtení nebo zápisu některých skupin v rámci zařízení a tím například prioritizovat čtení rychle se měnících aktuálních hodnot před čtením parametrů, které se tak často nemění. I když je ale ve vlastnostech skupiny nastaven interval 0 ms, telegramy nejsou vysílány častěji, než povolí omezení ve Vlastnostech zařízení nebo ve Vlastnostech kanálu.
Příklad: Kanál (pauza mezi telegramy = 0 ms) s jedním zařízením (interval čtení / zápis = 1 s), v zařízení jsou čtyři skupiny, skupiny 1 a 2 mají interval čtení / zápis = 0 ms, skupiny 3 a 4 pak interval 2 s. Na sběrnici jsou v tomto případě vysílány přibližně 3 telegramy za sekundu, v pořadí skupin:
1 – 3 – 2 – 1 – 4 – 2 – 1 – 3 – 2 – 1 – 4 – 2 – 1 – 3 – 2 – atd.
Pokud bychom u skupiny 4 zvýšili interval čtení / zápis na 5 s, fyzická frekvence telegramů se nezmění, jen dotazy ze skupiny 4 budou do fronty zařazovány méně často, s intervalem 5 s:
1 – 4 – 2 – 1 – 2 – 3 – 1 – 2 – 1 – 2 – 3 – 1 – 2 – 4 – 1 – atd.
Telegramy, vynechané kvůli delším intervalům čtení / zápis, jsou v port monitoru nahrazeny textem „Čtení skupiny s indexem … přeskočeno“.
U více zařízení na kanále jsou do bufferu kanálu řazeny dotazy postupně ze všech zařízení.
Příklad: Kanál (pauza mezi telegramy = 0 ms) se dvěma zařízeními (u zařízení A je interval čtení / zápis = 1 s, u zařízení B je 0 ms), v každém zařízení jsou dvě skupiny s intervaly 0 ms.
A1 – A2 – B1 – B2 – B1 – B2 – … – B1 – B2 – A1 – A2 – B1 – B2 – atd.
Telegramy A1 a A2 se opakují přibližně po 1 s. Ostatní komunikace je vyplněna telegramy B1 a B2. Mezi telegramy jsou pauzy cca. 50 ms.
Výše popsané principy ukazují, že zadáváním intervalů pro komunikaci nelze ovlivnit pořadí, v jakém budou telegramy odesílány. Časové parametry mají vliv jen na frekvenci dotazů. Někdy je ale potřeba vyslat telegramy buď jednorázově, nebo v určitém pořadí – například pro umožnění zápisu do serveru, když server vyžaduje před zápisem nějaký „odemykací“ telegram, nebo pro vyčítání latchovaných hodnot. K řízení komunikace lze využít proměnné commblock a forcecomm, které jsou dostupné pro každou skupinu (Group):
Nejprve zkontrolujeme, zda mají tyto proměnné povolený Autogen, aby byly namapovány na globální proměnné, které lze použít v programu.
Proměnná commblock má výchozí hodnotu False a pokud ji nastavíme do True, příslušná skupina přestává komunikovat. V port monitoru opět vidíme text „Čtení“ (případně zápis) „skupiny s indexem … přeskočeno“, v tomto případě u dvou skupin:
02.01.2025 14:26:19.7816 => Tx : 01 03 00 00 00 01 84 0A
02.01.2025 14:26:19.8066 <= Rx : 01 03 02 02 00
02.01.2025 14:26:19.8066 <= Rx : B9 24
02.01.2025 14:26:19.8396 => Tx : 01 03 00 01 00 01 D5 CA
02.01.2025 14:26:19.8696 <= Rx : 01 03 02 00 14
02.01.2025 14:26:19.8696 <= Rx : B8 4B
02.01.2025 14:26:19.8996 Čtení skupiny s indexem 0 přeskočeno
02.01.2025 14:26:19.8996 Čtení skupiny s indexem 1 přeskočeno
02.01.2025 14:26:19.9146 => Tx : 01 03 00 00 00 01 84 0A
02.01.2025 14:26:19.9326 <= Rx : 01 03 02 02 00
02.01.2025 14:26:19.9486 <= Rx : B9 24
02.01.2025 14:26:19.9746 => Tx : 01 03 00 01 00 01 D5 CA
02.01.2025 14:26:19.9956 <= Rx : 01 03 02 00 14
02.01.2025 14:26:19.9956 <= Rx : B8 4B
02.01.2025 14:26:20.0346 Čtení skupiny s indexem 0 přeskočeno
02.01.2025 14:26:20.0346 Čtení skupiny s indexem 1 přeskočeno
S proměnnou forcecomm je to složitější. Ta slouží k vyvolání komunikace (k zařazení telegramu do bufferu), ale interval čtení / zápis zde má přednost: Pokud je interval čtení/zápis nastaven například na 20 s a proměnná forcecomm změní hodnotu do True, provede se zápis až po 20 s.
Proměnná forcecomm by se měla používat tak, že forcecomm je nastaven trvale na True. Při běhu programu je commblock = True a tím je vypnutá komunikace skupiny. Ve chvíli, kdy je commblock změněn na False, telegram je odeslán bez ohledu na interval čtení/zápis. Sestupná hrana přivedená na commblock tedy vyvolá odeslání telegramu. Stav commblock nutno vrátit do True dříve, než na kolik je nastaven interval čtení / zápis příslušné skupiny, aby nedocházelo k periodickému odesílání telegramu (pokud to ovšem není žádoucí).
Funkce proměnné forcecomm tedy spočívá v tom, že pokud je v True, po uvolnění komunikace skupiny pomocí nastavení commblock na False je telegram zařazen do bufferu okamžitě, a ne až po uplynutí intervalu čtení / zápis.
Podrobnější porozumění tomu, jak funguje Modbus driver a co znamenají jeho jednotlivé parametry, usnadní nejen optimalizaci programu, ale i hledání chyb v případě, že vše nepracuje na první zapojení. V případě dalších dotazů se neváhejte obrátit na technickou podporu, support@domat.cz.
