Následující tipy se na problematiku dívají z hlediska výkonu ne PLC, ale programátora. Zejména ve firmách, kde se na jedné zakázce podílí více programátorů, nebo se projekty předávají mezi oddělením realizace a servisním oddělením, je vhodné při tvorbě programů dodržovat několik pravidel, která usnadní práci autorům programů i jejich následovníkům.
Za normálních okolností u hardwarových (HW) proměnných využíváme funkci Autogen, která automaticky generuje k I/O bodu globální proměnnou, kterou již můžeme použít v programu a napojit na ni další funkční bloky. Pokud proměnná vznikne použitím Autogenu, má unikátní ID. Je-li projekt včetně globálních proměnných využíván jako výchozí pro další podobné projekty, můžeme při přepojování hardwarových I/O bodů na program postupovat takto:
Tímto způsobem můžeme využít nějakou standardizovanou programovou strukturu v projektu, jehož osazení vstupů a výstupů nemůžeme ovlivnit – udělal to již dříve projektant.
Domat IDE umožňuje do schémat vkládat textové a obrázkové poznámky. Textové pole mohou mít různé barvy. Například žlutou píšeme komentáře k funkcím, aby bylo jasné, co která část programu dělá – vždy ve vztahu k technologii nebo její funkci, tedy například „zimní kompenzace požadované hodnoty“, určitě ne „k proměnné tSetpoint se přičte výstup z dvoubodové funkce“ – to je jasné na první pohled. Červeně pak může být označena část programu, která ještě vyžaduje úpravy („Dopojit po zprovoznění chladicího stroje“); po jejich dokončení poznámku můžeme smazat. Někdy je jeden obrázek lepší než mnoho slov, do schématu proto můžeme vložit i například vzorec, podle něhož probíhá výpočet, a podobně.
Je vhodné, když poznámky jsou u neobvyklých nebo na první pohled nesrozumitelných funkcí. Rozhodně se vyplatí například u vícestavové proměnné popsat významy jednotlivých hodnot („ 0 = vypnuto, 1 = zapnuto, 2 = časovač, 3 = automatika“). Podobná pravidla platí pro komentáře v strukturovaném textu. Tam jsou popisy funkce ještě důležitější, protože jazyk ST nebývá tak přehledný, jako bloková schémata FUPLA. Mysleme na to, že program při výjezdu otevře servisní technik, který ho v možná životě neviděl. Bude se v něm muset rychle zorientovat a k tomu řešit technologické či hardwarové problémy. Poslední, co potřebuje, je zkoumat, co náš program má vůbec dělat a jak to programátor myslel.
Již při zakládání proměnných a tvorbě algoritmů je vhodné označovat proměnné, které budou (nebo by mohly být) v budoucnu využity pro import do nadřazených systémů – obslužných panelů, OPC serveru, aplikace SCADA atd. Značení se v Domat IDE využívá například při (polo)automatickém generování šablon textového menu. Zároveň je možné u bloků, označených pro HMI import, rovnou přiřadit název displeje a textový gadget. Drobné doplnění při psaní programu zautomatizuje a sjednotí uživatelské menu, což dále usnadní tvorbu uživatelských návodů a zaškolení obsluhy.
Nemá-li měřená veličina fyzikální jednotku, vlastně nevíme, co měříme. U teplot jsou sice intuitivní °C, ale například pro tlaky už nemusí být na první pohled jasné, zda je hodnota v barech nebo kPa. U měřičů tepla se často řeší MWh versus GJ, vodoměry mohou udávat hodnoty v litrech nebo m3 atd.
Jednotky je vhodné poctivě vyplňovat zejména u vstupů a výstupů, ale také u požadovaných hodnot, parametrů, spočítaných proměnných zobrazovaných v grafice atd. Nezapomeňme, že jednotky se při importu do vizualizace automaticky přenášejí do tabulky datových bodů! Ušetřme si tak práci nejen při oživování, ale i při tvorbě grafiky a HMI. Vyplňováním fyzikálních jednotek už u globálních proměnných sledujeme koncept „enter data only once“ – vyhýbáme se duplicitnímu zadávání dat, které představuje ztrátu času i riziko chyby. Je snad zbytečné připomínat, že čidla, měřící stejné veličiny, by měla mít stejné jednotky. Někdy vídáme tlak vody na chlazení v kPa a na topení v bar, což přehlednosti také neprospívá.
Tento bod se může jevit poněkud sporným, jdou zde proti sobě dva požadavky: snaha zjednodušit práci sobě i druhým a tendence chránit systém proti neoprávněnému přístupu. Někdy je praktické do poznámek ve Vlastnostech PLC zapsat výrobní číslo PLC (S/N) nebo kód (Code:) ze štítku, aby se hesla nemusela hledat v další dokumentaci a PLC bylo vždy dosažitelné. Na druhou stranu, pokud by došlo k úniku programu s kompletními přístupovými údaji a předdefinovanou veřejnou adresou, možnému zneužití lze zabránit jen těžko.
Snaha o sjednocení názvů proměnných je tak stará, jako programování samo. Starší řídicí systémy mívaly omezený počet znaků pro název proměnné (např. 8 nebo 16), a tím nutily autory projektů k určité kázni. Vznikaly názvoslovné systémy se jmény datových bodů jako „Bld1AHU1FilSuAlr“, „LA1HzgVe“ atd.
Doporučujeme do názvu proměnné nezapracovávat fyzickou adresu vstupu I/O modulu nebo PLC, protože ta jednak je vidět v tabulce I/O bodů v zařízení, jednak se může změnit, pokud by došlo například k poškození vstupu a přepojení periferie a proměnné na jiný, rezervní vstup. Dále je vhodné se alespoň u větších projektů vyhnout číslování periferií podle projektu (např. čidlo B31, ventil Y10), neboť z toho není na první pohled jasná funkce (co měří B31? Y je ventil nebo klapka? Ventil je na topení nebo na chlazení?) a u různě vybavených zařízení se může číslování měnit (tedy např. Y2 je jednou ventil předehřevu, jindy chlazení), podle toho, jak dopadne automatické číslování periferií v prováděcím projektu. To může být problém zejména u projektů, kdy desítky podobných budov přivedených na společnou centrálu kreslí několik projektantů v různých projekčních programech.
Asi jako nejužitečnější se ukázal systém, kombinující název zařízení (VZT1) s názvem datového bodu, který obsahuje i měřenou veličinu (tVenk, pPrivod). Takové značení je dobře srozumitelné pro programátora i servisního technika. Nesmíme ale opomenout ani internacionální aspekt: nadnárodní společnosti mohou trvat na některém ze standardů popsaných výše.
Funkční bloky z knihoven mají výchozí jména typu „B110_Shift_Register_4“, přičemž na konci je automaticky doplněno číslo instance, pokud je stejných typů bloků v programu více. Tam, kde víme, že vstupní, výstupní nebo vnitřní proměnné bloku budou integrovány do vyšších vrstev systému – LCD, ovládacích panelů nebo vizualizace, je dobré blok přejmenovat, aby název odrážel jeho technologickou funkci.
Špatně: B35_Reverse_PI_Controller (výchozí název)
Správně: RegulaceTeplotyPrivod nebo RegTPriv
Název by zase neměl být zbytečně dlouhý, aby souhrnný název proměnné vč. celé cesty byl čitelný v dialozích pro její výběr u různých programů. Cesta by měla být srozumitelná, např. „vetev2.ekviterma.x1“.
ZávěremDoporučení, která jste si právě přečetli, nejsou žádná dogmata. Osvědčila se však ve firmě s 8-12 programátory (projektovými techniky) v realizačním oddělení a servisním oddělením, které je od realizačního odděleno. Podstatné je, že po předání zakázky odběrateli (v některých případech až po uplynutí záruční doby) předá realizační technik zakázku do servisního oddělení. Servisní technik si ve vlastním zájmu kontroluje, zda je dokumentace úplná, zda jsou zálohy softwaru, přístupové údaje a kontakty na zákazníka aktuální a zda na akci nejsou nějaké nedodělky. Pokud najde chybu nebo nejasnost, akci nepřebírá. To je velmi silná motivace pro realizačního technika, aby věci dotahoval do konce, jinak se zakázky nezbaví – a plynulému přechodu zakázky do servisního oddělení napomáhá mimo jiné právě dodržování výše uvedených pravidel.
