cz
en

Oživování integrace u VZT a klimatizačních jednotek

Vzduchotechnické jednotky a klimatizační systémy s vlastní regulací jsou čím dál oblíbenější. Mezi jejich jasné výhody patří zejména fakt, že regulační systém s řídicími algoritmy dodává jejich výrobce, který by měl nejlépe vědět, jak má zařízení pracovat, a mohl si algoritmy odladit na desítkách stejných zařízení na jiných akcích. Zjednodušuje se i montáž periferií, neboť většinu z nich je možné zapojit již v dílně, a vyhneme se tedy instalaci ve složitém prostředí stavby. Na druhou stranu je obvykle vyžadováno propojení s řídicím systémem budovy nebo vizualizací, které slouží i pro další technologie, a dodavatel klimatizace by měl být kvalifikovaným partnerem pro profesi měření a regulace, která právě tyto integrace řeší.

Komunikačních standardů, které se v současnosti používají, je více. Každý z nich vyžaduje poněkud specifický přístup. Postup prací a nejčastější problémy si ukážeme na jednom z nejoblíbenějších protokolů, kterým je Modbus RTU (po sériové lince) nebo TCP (po síti Ethernet).

Projekce

Již v projekční fázi je nutné upřesnit několik zásadních informací, které mají vliv na celý další průběh dodávek a prací:

Sériová linka nebo Ethernet?

Dodavatel zařízení musí sdělit, zda komunikuje po sériové lince (typicky rozhraní RS232 nebo RS485) protokolem Modbus RTU, či po síti Ethernet protoklem Modbus TCP. Pro převod protokolu Modbus mezi sériovou linkou a Ethernetem existují sice převodníky (tzv. Modbus RTU/TCP routery), ale jsou to další komponenty v systému, které někdo musí dodat, nainstalovat, nakonfigurovat a zaplatit. Proto se snažíme obejít se bez nich a pokud to situace vyžaduje, projektant by měl určit, kdo bude jejich dodavatelem a kdo zodpovídá za jejich řádné nastavení.

Zároveň se ujistíme, že pokud jednotka pro komunikaci potřebuje doplnit komunikační kartou nebo externím rozhraním, je toto zařízení součástí dodávky jednotky. Někteří výrobci používají společné rozhraní pro více jednotek, což může šetřit náklady.

U komunikace přes Ethernet počítejme s tím, že síťová karta jednotky musí mít nastavenu IP adresu. Stanovení rozsahu adres a přiřazování jednotlivým zařízením je obvykle v kompetenci dodavatele nadřazeného systému – nebo IT oddělení zákazníka, jedná-li se o firemní síť.

Sériová linka: RS232 nebo RS485?

Má-li klimatizační jednotka nebo její komunikační karta sériovou linku, měli bychom vědět, jaké je na ní fyzické rozhraní. Pro přímé spojení dvou zařízení a kratší vzdálenosti do 15 m je vhodný standard RS232, pro delší vzdálenosti (až 1 km) a připojení více jednotek se používá sběrnice RS485. V obou případech ověříme, zda u obou stran komunikace bude možné nastavit shodné komunikační parametry (přenosovou rychlost, paritu atd.).

Projektant by dále měl popsat připojení až na úroveň svorek, což znamená, že dodavatel zařízení musí poskytnout dokumentaci, kde je uvedeno značení svorek a další požadavky na stínění, délku vodičů, maximální počet jednotek na sběrnici apod. Potřebné údaje se dají už dobře získat na internetu, ale musíme vědět, jaký typ rozhraní nebo jaká karta jsou použity.

Master – slave?

Protokol Modbus rozlišuje dvě role: master a slave. Na sběrnici je jedno zařízení ve funkci master, obvykle to je nadřazené PLC nebo vizualizace, které řídí komunikaci a dotazuje podřízené (slave) jednotky. Na sběrnici vždy musí být právě jeden master a jedno nebo více zařízení slave. Ten dodavatel, který dodává zařízení slave, musí poskytnout tzv. Modbusovou tabulku se seznamem proměnných, viz dále. Někdy se používá terminologie klient – server, další informace najdeme například zde.

Před vlastním oživováním se snažíme získat maximum informací – Modbusové tabulky, katalogové listy, upozornění na zvláštnosti systému od dodavatele. Odzkoušené tipy a triky si poznamenáváme pro příští akci, protože člověk průběžně zapomíná. Je vhodné zapisovat veškerá provedená nastavení do projektu skutečného provedení, usnadní to práci servisním technikům. Pokud dodavatel poskytne zařízení na vyzkoušení předem, určitě této možnosti využijeme, v kanceláři na stole se zkoumá lépe než na štaflích s hlavou v podhledu.

Na stavbě: hardware

Při uvádění do provozu je výhodné postupovat po částech, „odspodu“ po jednotlivých krocích, a vždy ověřit, že předchozí část je kompletně v pořádku. Nemá smysl postavit najednou celý řetězec a pak hledat náhodně chybu v jeho částech. V případě sériové komunikace protokolem Modbus to tedy bude:

  1. Kontrola propojení obou systémů – celistvost kabelů (podle potřeby prozvonit), polarita vedení.
  2. Nastavení ukončovacích odporů sběrnice, obvykle přepínačem, podle pokynů výrobce. Neukončená nebo špatně ukončená sběrnice není impedančně přizpůsobená a může být pro komunikaci fatální překážkou.
  3. Nastavení komunikačních parametrů, tedy přenosové rychlosti, parity, počtu datových bitů a počtu stopbitů. Tyto hodnoty musejí být u všech účastníků komunikace nastaveny shodně.
  4. U zařízení slave nastavení Modbusových linkových adres. Tyto adresy musejí být na sběrnici unikátní, tedy žádná dvě zařízení nesmějí mít nastavenou stejnou adresu. Adresy se nastavují většinou pomocí DIP switchů, otočných přepínačů, nebo softwarově v menu, pokud má zařízení ovládací panel. Obyčejně začínáme od 1 a pokračujeme bez mezer, aby byl v číslování pořádek.
  5. Lokalizace indikačních LED diod (vysílání / příjem dat), které v další fázi pomohou při diagnostice.
  6. U zařízení s rozhraním Ethernet kontrola fyzického připojení síťové karty pomocí LED na switchi a zásuvkách RJ45 – u mikroprocesorových zařízení se mohou vyskytnout problémy s navazováním spojení, pokud jsou karty připojeny pomocí ethernetového kabelu jen mezi sebou. Doporučuje se vždy používat switch, který zároveň indikuje fyzické připojení i přenos dat.

Na stavbě: komunikace

Dále zkusíme navázat (jakoukoli) komunikaci se zařízením slave. K tomu slouží pomocné programy – utility, které poskytují větší flexibilitu než předem připravený projekt v PLC. Ostatně i v projektu můžeme mít chybu, která by nás zbytečně mátla. Postup je následující:

  1. Zvolíme program a komunikační převodník (USB – RS485 nebo USB – RS232), které dobře známe a s kterými jsme již dříve úspěšně pracovali. Je vždy dobré mít v řetězci jen jednu neznámou.
  2. U zařízení s rozhraním Ethernet zkontrolujeme nastavení IP adresy a ověříme dostupnost například příkazem ping. Často bývá problém v tom, že na testovacím PC nemáme nastavenou pevnou IP adresu ze stejného rozsahu, jaký používá jednotka, nebo IP adresa je shodná s adresou jednotky.
  3. Připravíme si Modbusovou tabulku, kterou dodal výrobce zařízení.
  4. Ověříme, že komunikační program má nastaveny komunikační parametry, které jsou nastaveny na zařízení. Jako první zkoušíme výchozí nastavení, i když později budeme chtít pracovat s jinými parametry (např. s vyšší komunikační rychlostí).
  5. Zkontrolujeme časové parametry komunikačního programu – pokud je timeout, neboli doba čekání na odpověď, nastaven jako příliš krátký (řekněme méně než 100 ms), může dojít k tomu, že master se nedočká odpovědi včas a vyhlásí poruchu. Pro začátek můžeme nastavit timeout na 1000 s, později ho zkrátíme na 200 – 300 ms. Mezera mezi telegramy může být cca. 1 s, abychom viděli sekvence blikání LED pro vysílání a příjem, později ji zkrátíme třeba i na 20 ms.
  6. V Modbusové tabulce si vybereme registr, který obsahuje proměnnou, jež bude pravděpodobně dostupná a budeme ji umět interpretovat. Je dobré, když tato hodnota je dostupná i na displeji jednotky, abychom mohli kontrolovat její velikost a případně změnu. Typicky je to třeba skutečná (měřená) teplota v místnosti. Na obrázku 1 vidíme Modbusové registry pro tři jednotky Toshiba. Všechny jednotky jsou dostupné přes společné rozhraní a jejich data jsou v Modbusové tabulce vždy posunuta o 100 registrů výše, tj. například teplotu na nasávaném vzduchu u jednotky 2 najdeme v registru 223 – tak se dají dopočítat i registry pro jednotky 3 až 7.
  7. V komunikačním programu nastavíme Modbusovou funkci podle dokumentace k jednotce (zde se jedná o Input registers, F04) a zkusíme vyslat a přijmout telegram. Program by měl mít výpis dat ze sběrnice, abychom viděli, zda zařízení odpovídá – a případně jaká data vrací.
  8. V úspěšně přijatém telegramu zkontrolujeme, zda přijatá hodnota odpovídá hodnotě očekávané.


Obr. 1: Modbusová tabulka pro rozhraní FDP3 (jednotky Toshiba)

Může dojít k následujícím problémům:

Zařízení vůbec neodpovídá

Asi nejčastější potíž. Zkontrolujeme body z části Hardware, zejména nastavení komunikačních parametrů. Pokud nejsou známy, můžeme zkusit použít program ModComTool a jeho skenovací funkci, která automaticky postupně zkouší všechny kombinace přednastavených parametrů a zastaví se ve chvíli, kdy zařízení odpoví.

Obr. 2: Skenovací funkce v programu ModComTool

V krajním případě můžeme vyzvat dodavatele zařízení, aby si „zvolil zbraň“ a předvedl libovolným Modbus klientským programem, a to i vlastním firemním, že zařízení odpovídá podle očekávání. Pokud toto prokáže, nezbývá než hledat chybu na vlastní straně. U sériové komunikace pomohou LED diody indikující vysílání a příjem dat, vidíme alespoň, zda master vysílá a slave mu „něco“ odpovídá.

U TCP komunikace zkontrolujeme, zda pro Modbus je v zařízení nastaven TCP port 502, a můžeme zkusit změnit Modbusovou (linkovou) adresu v dotazu. Podle standardu by sice zařízení mělo linkovou adresu ignorovat, setkali jsme se však s případy, kdy Modbus server vyžadoval adresu 1, jinak vůbec neodpověděl. Zajímavě se chovaly střídače Advanced Energy, které pro čtení reagovaly na adresu 1, zatímco pro zápis vyžadovaly adresu 0. Výrobce to zdůvodňoval jako ochranu před nechtěným zápisem, tzv. security by obscurity, tedy bezpečnost díky použití nestandardních vlastností.

Zařízení odpovídá s chybou

Pokud je hlášena standardní chyba Modbus, obvykle jde o dotaz neplatnou funkcí (např. Read Holding Registers F03 místo Read Input Registers F04) nebo dotaz na neexistující číslo registru, což může být způsobeno záměnou formátu HEX a DEC (např. 200 hexadecimálně je 512 dekadicky; pokud je tabulka v HEX a zadáváme číslo 200 do formátu DEC, jde o zcela jiný registr). Pozor také na notaci „40012“, což většinou neznamená „registr 40012“, ale „registr 12 čtený funkcí F04“ (nebo dokonce „čtený funkcí F03“, což je zajímavé a zrádné zároveň).

Zařízení vrací hodnotu, ale podivnou

Pokud je hodnota zcela nepodobná očekávané, např. 0 místo 21, nejspíše čteme jiný registr. Někteří dodavatelé číslují tabulky od 1 (tzv. registry), jiní od 0 (tzv. adresy). Zkusme adresu registru o jednu zvětšit nebo zmenšit. Můžeme i vyčíst celý blok registrů najednou a z něj snadno zjistit, která hodnota kam patří. Možná ale také používáme jinou funkci (např. F04 místo F03) a čteme zcela jiná data! Pozor také u hodnot menších než 0 (venkovní teplota): podtečení formátu word způsobí, že např. -1 čteme jako 65535.

Zařízení vrací hodnotu podobnou, ale řádově jinou

V tomto případě jsme již na správné cestě, potíž je nejspíše ve škálování. Výsledek je nutné vydělit, obvykle 10 nebo 100: Modbus neumí přenášet desetinná čísla a hodnoty, u nichž je to žádoucí, se v zařízení před přenosem do tabulky nejprve vynásobí a po načtení klientem je třeba je vydělit. Dodavatel by na to měl upozornit v Modbusové tabulce, jako je tomu na Obr. 1, kde teplota je udávána v °C × 100. Je tedy ji nutné po vyčtení vydělit 100.

Jakmile se podaří zakomunikovat první hodnotu, je napůl vyhráno. Ostatní se obvykle chovají podobně. Pro zápis hodnot platí obdobná pravidla, navíc se ale může stát, že pro povolení zápisu je nutné změnit hodnotu jiného registru – to se používá jako ochrana proti nechtěnému zápisu. Na podobné triky by měl upozornit dodavatel v návodu nebo Modbusové tabulce.

Datová integrace nejen šetří fyzické datové body v řídicím systému, ale umožňuje i přenos hodnot, které by binárními nebo spojitými signály bylo možné sdělovat jen obtížně. Jde zejména o spotřeby energií, provozní hodiny (kumulované hodnoty), čísla poruch a jiné diskrétní vícestavové veličiny. Pro zájemce o hlubší zvládnutí problematiky pořádá firma Domat bezplatná školení, kde si účastníci mohou vyzkoušet komunikaci v praxi a zaintegrovat i vlastní přinesená zařízení. Správně naprojektovaná a oživená vazba mezi systémy přináší transparentní pohled na technologie a tím může zvýšit komfort v budovách a snížit servisní náklady.