Jaký je koncept DbNet komunikace mezi řídicím systémem a LookDetem?

Pro pochopení tohoto textu je potřeba, aby čtenář byl seznámen s principy fungování LookDetu, DetStudia a DbNet komunikace. Toto řešení popisuje postup v LookDetu verze 6.x a DetStudiu verze 3.4.25.

Jak to s tím konceptem tedy je?

Z pohledu DbNet komunikace lze obě komunikující strany považovat za stanici. Obě stanice sdílí proměnné ke komunikaci. Každá sdílená proměnná má svůj unikátní WID.

Na straně řídicího systému jsou komunikované proměnné a jejich WIDy specifikovány v DetStudiu prostřednictvím tabulky v rámci komunikačního objektu DbNet v sekci Vlastnosti objektů jako proměnné do DbNetu. Toto jsou proměnné, ke kterým může LookDet vzdáleně přistupovat (zapisovat i číst). Jedná se pouze o výběr ze všech proměnných a vlastností řídicího systému. To, které proměnné a vlastnosti jsou ve výsledku zahrnuty do výběru ke komunikaci záleží na potřebě tvůrce aplikace. Může být například zahrnuta pouze jedna proměnná či vlastnost, nebo mohou být například zahrnuty všechny proměnné a vlastnosti řídicího systému.

Na straně LookDetu jsou sdílené proměnné a jejich WIDy specifikovány prostřednictvím tabulky kanálů a jejich jednoznačného čísla. Toto jsou proměnné, ke kterým může řídicí systém vzdáleně přistupovat (pouze zapisovat). V případě LookDetu jsou všechny tyto proměnné k dispozici řídicímu systému pro zápis.

Je vidět, že každá strana definuje svoje proměnné, které sdílí protější straně.
Každá strana přistupuje k proměnným, které sdílí protější strana.

Existují dva směry komunikace. Komunikace, kterou iniciuje LookDet a komunikace, kterou iniciuje řídicí systém.
Pokud LookDet iniciuje komunikaci, LookDet čte a nebo zapisuje do proměnných, které sdílí řídicí systém. Tato komunikace se také nazývá parametrizace řídicího systému.
Pokud řídicí systém iniciuje komunikaci, řídicí systém zapisuje do proměnných, které sdílí LookDet. Tato komunikace se také nazývá aktivní zápis do LookDetu.

Tyto dva směry komunikace jsou vzájemně nezávislé, proto čísla kanálů na straně LookDetu a WIDy sdílených proměnných na straně řídicího systému se mohou shodovat, aniž by došlo ke kolizi.

Sdílené proměnné jsou definovány pouze ve stanici, která proměnné sdílí. Je však potřeba zajistit, aby stanice, která komunikaci iniciuje, měla informaci, které proměnné sdílí protější strana – odkud číst, kam zapisovat.
Na straně řídicího systému existuje pro tento účel druhá tabulka. Tato tabulka je definována v rámci objektu DbNet v sekci Vzdálené stanice.
Na straně LookDetu žádná taková tabulka neexistuje. V LookDetu v rámci náhledu u funkcí, které iniciují čtení nebo zápis do řídicího systému se přímo zadává WID proměnné v řídicím systému.

Dobře, ale už v tom začínám mít trochu zmatek. Můžete to vysvětlit na příkladu?

Jasně.

Komunikaci, kterou iniciuje LookDet vysvětlím na příkladu s objektem časového plánu DayPlan.
Komunikaci iniciuje LookDet, a z toho podle předchozího popisu plyne, že se budou komunikovat proměnné, které sdílí řídicí systém.
To, které proměnné řídicí systém sdílí, je definováno v DetStudiu prostřednictvím tabulky v rámci komunikačního objektu DbNet v sekci Vlastnosti objektů jako proměnné do DbNetu.
V našem případě se jedná o vlastnosti MtxTime a MtxValue objektu DayPlan, proto je potřeba tyto vlastnosti přidat do tabulky.

LookDet ale tuto tabulku nezná, proto je potřeba LookDet dodatečným způsobem informovat, ke kterým proměnným má přistupovat.
V případě časového plánu je postup následující. Principiálně je ale stejný pro všechny případy, kdy LookDet iniciuje komunikaci.
V náhledu otevřete editaci grafického objektu, vyberte Nastavení časových plánů a nastavte hodnoty pro parametry Kanál časů (ML) a Kanál hodnot (MF/MI).

Tímto jsme LookDetu sdělili: „Pokud chceš přistupovat k časovému plánu v řídícím systému, přečti proměnné s WIDem 1001 a 1002.“

Komunikace, kterou iniciuje řídicí systém je v principu stejná, jen forma je trochu odlišná.
Komunikaci iniciuje řídicí systém, a z toho opět podle předchozího popisu plyne, že se budou komunikovat proměnné, které sdílí LookDet.
V řídicím systému je tabulka, která definuje obraz všech proměnných, které LookDet sdílí a které jsou řídicím systémem komunikovány. Ale ne všechny proměnné sdílené LookDetem musí být komunikovány jedním řídicím systémem a ne všechny proměnné musí být komunikovány vůbec. To, které obrazy proměnných bude tabulka obsahovat závisí na potřebě programátora a aplikaci řídicího systému. Tato tabulka je v objektu DbNet v rámci definované stanice v sekci Vzdálené DB-Net stanice.

V rámci našeho příkladu předpokládejme, že LookDet v kanálu s číslem 1000 očekává hodnotu teploty topného okruhu kotelny, kterou měří čidlo připojené k řídicímu systému.
V DetStudiu tedy přidáme do tabulky obraz této proměnné / tohoto kanálu.

Zápisem této proměnné (resp. jejího obrazu – v našem případě pojmenovaném „teplota“) iniciuje řídicí systém komunikaci s LookDetem, a tím zápis do odpovídajícího kanálu v LookDetu.

A to je v principu vše.

Shrnutí a doplnění

Z pohledu DbNetu jsou LookDet i řídicí systém považovány za stanici v síti DbNet.

Každá stanice sdílí komunikované proměnné.

Stanice musí znát sdílené proměnné protější stanice.

Rozlišuje se, která stanice iniciuje komunikaci

• Parametrizace řídicího systému (iniciuje LookDet)
• Aktivní zápis do LookDetu (iniciuje řídicí systém)

Stanice, která iniciuje komunikaci, komunikuje proměnné, které sdílí protější stanice.

Aktivní zápis do LookDetu je preferovaný způsob komunikace, který efektivně zajistí pravidelný přenos velkých objemů dat aniž by příliš vytěžoval server LookDetu.
Parametrizace řídicího systému se používá nárazově při potřebě LookDetu zapsat nebo vyčíst z řídicího systému parametrizační údaje. Jedná se o jednorázový přenos malého objemu dat.
Existuje ještě třetí způsob komunikace, který se nazývá Cyklické čtení. Tento způsob je v principu stejný jako Parametrizace řídicího systému – komunikaci iniciuje řídicí systém – s tím rozdílem, že se nepoužívá pro nárazovou komunikaci, ale pro pravidelné vyčítání procesních hodnot z řídicího systému. Jeho nevýhodou je, že výrazně zvyšuje vytížení serveru LookDetu, proto se používá především v případě komunikace typu M-Bus, které Aktivní zápis do LookDetu nepodporuje.