Jak psát efektivně software v Merbon IDE
Příprava aplikačního programu pro zařízení VVK by měla být efektivní nejen proto, abychom minimalizovali čas na ni potřebný. Jde i o to, maximálně využít možností hardwarových platforem, ale na druhou stranu nechat si určitou rezervu pro případné rozšiřování systému. Zdroje v PLC nejsou neomezené a u některých platforem je musíme alokovat s rozmyslem. V následujícím textu najdete několik tipů, jak se k této úloze postavit.
Zakládání projektů
Již při zakládání projektu a jeho rozvrhování si musíme uvědomit rozdíl mezi projektem (Project) a sestavou (Solution). Projektem se rozumí soubor programů, funkcí a funkčních bloků. Asi nejdůležitější je uvědomit si, že každý projekt má své globální proměnné (které jdou mapovat – připojovat – na hardwarové vstupy a výstupy PLC). Projekt je vlastně něco jako „kontejner“, do něhož přiřazujeme vlastní programy i odkazy (reference) na knihovny atd. Sestava je pak něco, co zahrnuje
- PLC, tedy popisy hardwaru (regulátorů),
- projekty, tedy popisy, co mohou nebo mají tato PLC dělat, a
- vazby mezi PLC a projekty, tedy přiřazení programů jednotlivým regulátorům.
Je to především kvůli tomu, že jeden program může běžet na více PLC. Jak je to možné a proč bychom to měli chtít?
Za normálních okolností vystačíme s tradiční představou, že v sestavě je jedno nebo více PLC a v každém z nich běží jiný program (nebo více programů).
Všechny programy mohou být založeny v jediném projektu. V nastavení PLC v definici tasků se pak pro každé PLC definuje, které programy dané PLC zpracovává.
Představme si nyní, že nějaký program popisuje řízení určité technologie, která je obsažena v několika různých PLC – například v budově je více stejných VZT jednotek nebo ekvitermních větví. Může být výhodné spravovat program pro řízení VZT jednotky nebo ekvitermy pouze na jednom místě (v nějakém projektu) a v jednotlivých PLC ho „volat“, samozřejmě vždy s jinými přiřazenými fyzickými vstupy a výstupy. Vstupy a výstupy programu jsou přiřazeny k příslušným fyzickým vstupům a výstupům v I/O modulech každého PLC. Když v programu upravíme nějakou funkci, stačí nahrát sestavu do regulátorů a změny se projeví ve všech PLC, do nichž je program přiřazen.
Kdy používat v sestavě více projektů
Rozdělení programů do několika projektů (v rámci jedné sestavy) má smysl tehdy, chceme-li některé programy spravovat pohromadě. Je například možné založit zvlášť projekt pro klimatizaci a zvlášť projekt pro řízení osvětlení, vždy s příslušnými knihovnami a programy, které využívají bloky a funkce z těchto knihoven. Celý projekt osvětlení pak můžeme například použít v jiné sestavě, samostatně zálohovat, poslat mailem atd.
Další případ nastane v situaci, kdy v sestavě je několik PLC, které nemají žádné společné programy. Každé PLC by potom mělo mít svůj samostatný projekt, neboť to dosti zásadním způsobem zpřehlední strukturu sestavy. Je to výhodnější pro správu jednotlivých programů – zrychlí se následné vyčítání hodnot proměnných z PLC do IDE a místo jednoho velkého definičního souboru s proměnnými vznikne několik menších souborů, pro každé PLC samostatný.
Proč mít všechna PLC v jedné sestavě
Je to vhodné proto, že PLC se spravují a konfigurují společně. Při změně v programech lze všechna PLC přehrát najednou jediným stiskem tlačítka. Dále je možné posílat hodnoty z jednoho PLC do jiného pomocí SSCP komunikace mezi podstanicemi. (V dalších verzích Merbon IDE bude možné komunikovat i s PLC z jiné sestavy, stejně jak je tomu u SoftPLC IDE.)
Maximální počet PLC v sestavě je dán tím, jak jsou rozsáhlé projekty v PLC. Doporučený počet s dostatečnou rezervou je 5 PLC.
V jedné sestavě obvykle zakládáme PLC umístěná v jedné budově nebo technologickém celku, kde spolu mají vzájemné funkční vazby.
Základní rozdíly proti SoftPLC IDE
Pokud přecházíme ze SoftPLC IDE na Merbon IDE, zjistíme, že Merbon IDE obsahuje několik rozdílů. Ty nejvýznamnější jsou:
Vnořování bloků, tvoření složených bloků
Tato dlouho poptávaná funkce na jednu stranu umožňuje výrazné zpřehlednění softwaru, protože algoritmy lze dobře segmentovat a opakující se kusy kódu použít v podobě instancí zákaznických bloků. Pokud se ale vnořování přežene, jednak se čitelnost programu naopak sníží, jednak se neúměrně zvýší zatížení PLC. Doporučujeme proto s ohledem na méně výkonné platformy (mark100, mark150,...) používat maximálně dvě úrovně vnořování, tedy složený blok se může skládat z dalších složených bloků, ale tyto vnitřní bloky už by měly být složeny jen ze základních bloků z knihoven.
Možnost použití strukturovaného textu (ST podle normy IEC 61131-3)
Strukturovaný text přináší na rozdíl od funkčních bloků elegantní řešení cyklů, podmínek a zápisů do proměnných z více procesů. Na druhou stranu je program psaný v ST méně přehledný a tedy obtížněji udržovatelný – pokud není důkladně komentován, ani sám autor se v něm po nějaké době nevyzná. V typickém programu pro řízení technologických zařízení budov je doporučovaným postupem používat pro přehlednost funkční bloky, pokud možno standardní, které ale mohou být doplněny „zákaznickými“ funkčními bloky, vytvořenými na míru – buď z jiných funkčních bloků, nebo právě pomocí strukturovaného textu.
Více PLC v jedné sestavě
Jak již bylo popsáno výše, v jedné sestavě (Solution) můžeme definovat více PLC. Výhodou je mj. to, že PLC mohou sdílet společné programy: při úpravě programu se změna po nahrání projeví ve všech PLC, které program obsahují.
Nahrávání projektů do všech PLC je možné spustit najednou. To pomáhá udržet celý systém konzistentní i při úpravách v různých PLC, která mají vzájemné komunikační vazby.
Menší počet komunikačních driverů
V SoftPLC IDE, především u platforem založených na Windows (IPCT.1) a Linuxu (IPLC510), uživatelé oceňují několik desítek komunikačních driverů pro nejrůznější protokoly, používané v řízení budov, včetně proprietárních protokolů pro cizí nebo starší řídicí systémy. Merbon naproti tomu nyní obsahuje pouze Modbus, M-Bus, SoftPLC Link a protokol pro odečet elektroměrů podle IEC62056-21. Je to proto, že Merbon runtime musí fungovat i na malých platformách s omezenou kapacitou paměti. Integrace cizích systémů lze realizovat přes SoftPLC (IPLC510) ve funkci převodníku s následným čtením do prostředí Merbon pomocí driveru SoftPLC Link. Na druhou stranu Merbon IDE umožňuje psát vlastní drivery v jazyce ST – viz dále.
Používání více tasků
Programy nejsou spouštěny neměnným způsobem jeden za druhým, ale jsou přiřazeny do tzv. tasků. Task, neboli skupina programů spouštěných najednou, obsahuje jeden nebo více programů a je spouštěn periodicky, na základě změny stavu proměnné, nebo je „volně běžící“ – provede se, když PLC má čas. Je tak možné méně důležité úlohy (např. odečet měřičů, statistické funkce) provádět méně často nebo s nižší prioritou, aby se optimalizoval výkon PLC.
Psaní driverů v ST
Drivery pro jednodušší komunikační protokoly je možné psát i zákaznicky, jako funkce v jazyce ST. Tato možnost je otevřená pro zkušenější programátory, je nutné počítat s tím, že odlaďování může zabrat více času, než se původně plánovalo. Někdy je nutná podpora ze strany dodavatele cizího zařízení. Vývoj lze v některých případech i objednat u firmy Domat Control System – záleží na momentálních kapacitách vývojového oddělení.
ST neobsahuje funkce pro parsování textových řetězců, takže protokoly založené na XML dotazech nejsou dobře zpracovatelné. Naopak binární nebo znakové přenosy dat s pevnou strukturou telegramu by měly jít implementovat poměrně snadno. Obraťte se na oddělení technické podpory s popisem protokolu, který plánujete zaintegrovat.
Volba programovacího jazyka
Při rozhodování obecně platí, že program v jazyce FUPLA je přehlednější, ale náročnější na výpočetní výkon. Programování je jednodušší a názornější, řada procedur se děje automaticky na pozadí.
Naproti tomu nelze ovlivňovat pořadí vykonávání bloků (při kompilaci IDE vytvoří program, kde je určeno pořadí bloků. Je zaručeno, že při zpracování funkce nebo funkčního bloku jsou vypočteny všechny příslušné vstupy. Není ale zaručeno nějaké konkrétní pořadí bloků). Vždy se vykonává celý program – v jazyce FUPLA se používají bloky, které mohou být poměrně komplikované a využívá se z nich jen malá část funkce. Naproti tomu v strukturovaném textu by si uživatel pro stejnou funkci netvořil novou instanci FB, ale napsal jednoduchý konstrukt v ST.
Strukturovaný text poskytuje maximální kontrolu nad programem, dobře řeší cykly a podmínky, práci s poli, vektory, strukturami. Umožňuje důkladnější debugging.
Na druhou stranu je ST méně přehledný a složitější na používání, není to „klikací“ software, byť obsahuje IntelliSense – automatické návrhy na doplňování klíčových slov. Autor programu si musí hlídat veškeré deklarace, jmenné prostory atd.
Velikost programu a metodika měření
U méně výkonných platforem je klíčovou otázkou, zda se aplikace „vejde“ do PLC. Systém Merbon je velmi flexibilní, umožňuje mnoho kombinací funkcí v PLC a nemá nastaveny „ostré limity“, které by způsobily, že nebude možné plně využít zdroje platforem (zejména paměť). Nároky na paměť běžícího runtimu bohužel nelze jednoduchým algoritmem ze zdrojového textu určit. Jsme schopni stanovit, kolik paměti zabere zkompilovaný program v PLC, tj. zda vůbec půjde nahrát do paměti. Není ale možné stoprocentně odhadnout, kolik paměti RAM bude kompilát vyžadovat po spuštění: každý definovaný komunikační kanál zabere část paměti a různé kombinace kanálů a bloků zabírají u některých platforem různě velké sektory paměti. Přesný stav využití zdrojů je vidět ve statistikách PLC v záložce System status, viz dále.
Na druhou stranu jsme schopni určit, kolik místa zbývá v NVRAM paměti pro proměnné RETAIN (uchovávají se i po výpadku napájení). (Hodnoty zůstanou po výpadku napájení uloženy i v klasické paměti Flash, jen je třeba počítat s tříhodinovým intervalem zápisu, který prodlužuje životnost paměti, nebo ukládání spouštět manuálně.)
Výkonnostní třídy PLC
PLC, která lze programovat pomocí programovacího prostředí Merbon IDE, lze rozdělit do tří výkonnostních kategorií. Kategorie se liší jak výkonem a pamětí pro SW a pro web, tak také počtem klientů, které jsou schopny obsloužit, a rychlostí reakcí například na webovém serveru.
- Základní PLC
Mezi tato základní PLC patři podstanice mark100, mark150/485, mark120, IMIO100 a ICIO200.
Typický aplikační program pro nejslabší platformy obsahuje funkce pro řízení VVK pro cca. 50 fyzických datových bodů. Nejvíce místa v paměti zabírají časové programy, zejména ty s výjimkami. Proto doporučujeme jejich počet omezit na 2–3 a zejména používat typy schedulerů …Basic, které mají pouze týdenní tabulku s max. 42 změnami a neobsahují výjimkové programy. Pokud by podstanice sloužila pouze pro sběr dat a jejich následné odeslání do jiného systému, hranice počtu datových bodů se zásadním způsobem posouvá. V tomto režimu fungování např. PLC mark100 zvládne zkomunikovat cca. 150 fyzických datových bodů.
PLC z této kategorie dokáží obsloužit maximálně 5 klientů na kanálu SSCP (jde např. o komunikaci mezi PLC navzájem, o vizualizaci – SCADA, OPC server, případně další programy jako Merbon Menu Reader, tedy o „serverové“ kanály). Vždy je ale potřebovat nechat si jeden kanál rezervu pro komunikaci se samotným Merbon IDE. Reálný limit je tedy na hodnotě 4 klientů na kanálu SSCP.
Kapacita paměti pro webový server je cca. 1,1 MB – toto je nutné respektovat zvláště při přípravě obrázků – volte úsporné formáty, jako .png! - Základní PLC se zvýšenou kapacitou RAM
Mezi tato PLC patří podstanice mark125, IMIO105, IMIO110 a ICIO205.
U podstanic se zvýšenou kapacitou RAM (IMIO105, ICIO205, mark125) se limit počtu datových bodů posouvá cca. na trojnásobek, tedy 150 pro regulaci a 400–450 pro sběr dat. PLC z této kategorie dokáží také obsloužit maximálně 5 klientů na kanálu SSCP. Kapacita paměti pro webový server je stejná jako u předchozí kategorie, tedy cca. 1,1 MB. - PLC nejvýkonnější třídy
Mezi tyto podstanice se řadí mark220, mark320, markMX a podstanice wall. Zde počet časových programů již není kritický. Musíme spíše dbát na to, aby bloky nebyly vnořovány ve více než cca. 3 úrovních – viz dále. Limit počtu datových bodů je tu opět asi trojnásobný oproti základním PLC se zvýšenou kapacitou RAM a pohybuje se tedy na cca. 450 fyzických datových bodech. PLC z této kategorie mají také větší kapacitu paměti pro proměnné typu „retain“.
Podstanice z tého kategorie dokáží naráz komunikovat až s 20 klienty na kanálu SSCP, což je hodnota, kterou lze v praxi překročit jen velmi obtížně.
Kapacita paměti pro webový server je minimálně 8,3 MB.
Zatížení PLC, neboli počet fyzických datových bodů, které PLC zvládne ovládat, a rychlost odezvy celého systému, je ale závislá především na složitosti, komplexnosti a způsobu tvorby regulačního softwaru. Omezení počtem fyzických datových bodů je tedy spíše orientační, vždy záleží na způsobu práce konkrétního autora programu.
Ukazatele míry zatížení PLC
Při tvorbě softwaru je možné se orientovat jak podle počtu fyzických datových bodů, tak podle informací, které jsou v Merbon IDE viditelné po každé kompilaci sestavy. V okně „Výstup“ se po kompilaci vypíšou informace o zaplnění paměti PLC. Hodnoty zaplnění paměti by tedy měly být pod hranicí 100 %, ideálně by neměly přesáhnout hodnotu 90 %.
Dalším ukazatelem, který lze použít k určení míry zatížení PLC, je délka jednoho výpočetního cyklu. Pokud je již sestava na podstanici nahrána a je spuštěno ladění, délku cyklu nalezneme v okně „Stav systému“. Maximální délka jednoho cyklu by se měla bez ohledu na platformu pohybovat ideálně pod hranicí 0,5 s, v případech větších projektů pak pod hranicí 0,7 s. Delší trvání jednoho cyklu zapříčiní například pomalejší odezvy systému pro vnější klienty (webserver, Merbon Menu Reader, terminály HT102/HT200, komunikace s Merbon IDE atd.), systém bude hůře reagovat na krátkodobé změny na vstupech a v extrémních případech může nepřiměřeně dlouhý cyklus snižovat stabilitu běhu celého systému.
Zákaznické bloky a vnořování
Zákaznické bloky jsou skvělým nástrojem pro zefektivnění práce programátora. Jsou ideální pro standardizaci softwaru napříč firmou, dají se napsat univerzální varianty pro použití na většině projektů. Použití vysoce komplexních funkčních bloků (velké desítky až stovky bloků uvnitř) a vícenásobné vnoření bloků ale zvyšuje zátěž PLC. Pro nejslabší platformy (ICIO, IMIO, mark100, 120, 150) doporučujeme maximálně dvojnásobné vnoření.
Uživatelské FB by neměly obsahovat schémata celé technologie, obecně vzato měly by obsahovat spíše jednodušší věci: ideální blok je např. řízení čerpadla, kotle, směšovací větve atd., ne však blok „Kotelna“, „Vzduchotechnika“, nebo v extrémním případě např. „budova 1“, kdy by byly v sestavě čtyři totožné budovy a každý FB poté obsahoval 80 vstupů a 80 výstupů a uvnitř ukrýval kompletní regulaci.
Ideální je použít kompromis mezi FB a programy – rozdělit projekt do více programů, které obsahují jednodušší FB. Komplexní funkční bloky sice ulehčí práci tvůrci SW, ale přitíží PLC regulátoru. Nejvýkonnější typy PLC lze zatížit více, pokud je však potřeba například rychlá reakce na sběrnicích nebo celkově rychlá odezva, je potřeba přizpůsobit styl programování i zde. U základních PLC je vždy potřeba pamatovat, že se jedná o slabší platformu, komplexnost FB tomu tedy musí být přizpůsobena.
Tasky a jak s jejich pomocí optimalizovat výkon PLC
U periodických tasků nemívá smysl volat task častěji, než je perioda freewheeling tasku a než je PLC schopno občerstvovat vstupy a výstupy na sběrnici – častější volání u běžných algoritmů stejně nezrychlí reakci a zbytečně zatěžuje procesor, který obsluhuje ještě další procesy, jako je např. webový server. Výhodnější je ale použít volně běžící task, při němž si PLC plánuje optimální využití samo – task je spouštěn, „když má PLC čas“. Je tak zaručena nejkratší možná perioda zpracování při dostatečné rezervě pro ostatní procesy (web, komunikace...). Viz také výše.
V PLC vždy musí být definovaný minimálně jeden task jakéhokoli typu. Dalších tasků poté může být více, ale je potřeba vědět, že nemá smysl nastavovat u periodických tasků periodu kratší, než byla původní změřená doba cyklu. Task se tak rychle stejně spouštět nebude. Periodický task tedy má smysl pro algoritmy, které se mají pouštět pouze jednou za určitý (delší) čas. Neslouží pro věci, které mají být spouštěny častěji. K tomu slouží typ „freewheeling“, který je spouštěn co nejrychleji to jde. (Je ovšem možné nastavit pauzu, která se provede vždy po ukončení jednoho cyklu.)
Obecně se u většiny aplikací doporučuje používat pouze jeden task. Velmi lehce bychom se totiž mohli dostat do situace, kdy se pro střídání netriviálních výpočetních tasků nedostane na další úlohy, jako je komunikace, webový server atd. Druhý a další task by měly být s co nejkratší dobou výpočtu. U Jednoduchého módu je definován jen jeden task, a to volně běžící (freewheeling), a všechny programy jsou spouštěny v něm. Funkce tak odpovídá konceptu SoftPLC IDE.
Další pravidla
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.
Autogen a jeho použití
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:
- v nové sestavě osadíme I/O body v zařízeních (I/O modulech) podle zapojovacích schémat
- přikopírujeme výchozí projekt
- vypneme Autogen u příslušného vstupu nebo výstupu
- přesuneme (Ctrl-X, Ctrl-V) název proměnné ze starého vstupu/výstupu na nový
- zapneme Autogen u nové proměnné a zkontrolujeme, příp. vybereme cílový projekt.
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.
Poznámky
Merbon 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.
Označování proměnných pro HMI import, OPC atd.
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 Merbon 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.
Vyplnění fyzikálních jednotek
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á.
Přístup do PLC
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.
Standardní názvy datových bodů
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.
Pojmenovávání funkčních bloků
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ěrem
Doporuč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.
Domat Control System s.r.o. patří k evropské špičce dodavatelů řídicích systémů a regulací pro inteligentní budovy, průmysl a energetiku. Cílem této ryze české společnosti je vyvíjet, vyrábět a dodávat řídící systémy v mezinárodním měřítku.