Výtah z komunikace se suportem AMiT - Chtěl bych znát Váš názor na řešení sítě DB-Net z hlediska propustnosti sítě. Mám síť s 10 stanicemi a jedním PC vizualizací, kam se přenáší hodně dat a též stanice si mezi sebou musí předávat data. Chtěl bych znát váš názor na varianty řešení, nebo dokud znáte lepší.
1) Protože si stanice musí předávat mezi sebou data, udělám je všechny jako aktivní, což je už 11 masterů na síti a proměnnou přenáším jen při změně nebo výpadku komunikace či restartu stanice. Výhoda je, že proměnná se přenáší jen při změně, ale nevím, jaká je režie předávání komunikace s 11 maestry. Síť je zatěžována jen požadavky PC a změnami proměnných.
2) 9 stanic udělám pasivní a jen jednu aktivní, která se bude periodicky ptát na proměnné a bude je též periodicky (možno i při změně) rozesílat do určených stanic. Nevýhoda je, že síť je periodicky zatěžována, aniž data jsou potřeba, pokud nebyla změna dat.

Oba dva způsoby komunikace jsou v principu možné. Idea komunikace při změně proměnných je zajímavá, ale velmi by zde záleželo na množství dat a četnosti požadavků na jejich přenos, což zatím nejsme schopni (z vašich informací) odhadnout. Pokud se však data budou komunikovat s malou četností, např. jen několikrát za hodinu, není vyloučeno, že by komunikace fungovala bez jakýchkoliv problémů. Takže toto řešení bych moc nedoporučoval. U druhého způsobu můžete vhodně zvolenou periodou pro vyčítání dat pravidelně postupně "obvolávat" různé stanice, ze kterých chcete data získat, případně jiná data zapsat. Periodu je opět nutno zvolit v závislosti na množství vyčítaných dat. Pokud máte všechny řídicí systémy s ethernetovým rozhraním, tak pro komunikaci mezi stanicemi i pro komunikaci s vizualizací můžete využít ethernet. Při tomto typu komunikace nemusíte rozlišovat, zda je stanice aktivní či pasivní.
> Zároveň jsem chtěl poprosit o vzorový příklad propojení 3 DB-Netů, přes rozhraní ethernet
Jak již bylo uvedeno v předchozí korespondenci. Variantu se všemi aktivními stanicemi nedoporučujeme. Při velkém množství masterů na síti může dojít k dlouhému čekání na obdržení tokenu (bez kterého nemůže stanice vysílat). Obecně se doporučuje stav, kdy na síti DB-Net není více jak poloviční množství aktivních stanic. Periodické obvolávání stanic (s vhodně zvolenou periodou) by tedy ve vašem případě bylo vhodnější. Pokud navíc chcete vytvořit routování do sítě DB-Net (soudím tak na základě vaší žádosti o komunikaci po ethernetu) tak si musíte uvědomit, že systém již bude značně vytížen jak periodickým obvoláváním, tak komunikací po ethernetu. Regulační část programu na takovémto ŘS proto musíte vhodně zvolit s ohledem na vytížení ethernetovou a sériovou komunikací. Pro snížení režie na komunikaci je také výhodné používat matice, zvláště pak pro vizualizaci, kdy jedním požadavkem vyvoláte přenos celé matice a nemusíte se tak opakovaně ptát na jednotlivé proměnné/bity. Ukázkovou aplikaci routování do sítě DB-Net přikládám.
> Variantu přenášení dat po síti při změně mám vyzkoušenou a zdá se mi hospodárnější než periodické vyčítání dat, která jsou pořád stejná. Pokud se proměnná rychle mění tak je určitě výhodné ji vyčítat periodicky, ale pokud se mi změní párkrát do hodiny, tak se mi zdá systém ,,při změně" hospodárnější a pořád nechápu problém kombinace s více mastery na síti a komunikace, při změně". Chápu, že pokud bude hodně masterů a každý bude chtít hodně komunikovat, tak zpoždění bude velké, ale pokud mám sice 10 masterů, ale protože posílají při změně, tak každý bude komunikovat 10x do hodiny tak v tom nevidím problém. Je ten problém v počtu masterů, nebo v komunikování při změně?
V první odpovědi na váš dotaz bylo uvedeno, že pokud se data budou komunikovat s malou četností, např. jen několikrát za hodinu, není vyloučeno, že by komunikace fungovala bez jakýchkoliv problémů. Protože jste nepopsal četnost komunikace, nebylo možné se doposud přesněji vyjádřit, zda tento způsob komunikace je vhodný či ne. V druhé odpovědi jsem pouze naznačil, že pokud vám nastanou havarijní stavy na všech stanicích najednou (což nikdy nemůžete vyloučit), může nastat situace, kdy budou stanice čekat na přidělení tokenu od stanic, které jej získaly dříve, a tím může dojít ke zpoždění přenosu informace zvláště při větším množství komunikovaných dat. Když se navíc mezi tím PC zeptá na velké množství dat (jak uvádíte), tak bude samozřejmě prodleva, mezi nastalým havarijním stavem a jeho odesláním narůstat. Co se týká časování, v příloze vám posílám kompletní popis protokolu DB-Net (Nejedná se o DB-Net/IP). (posláno později)
> Můj dotaz směřoval spíše k tomu, že by bylo vhodné popsat komunikaci DB-Net a DB-Net/IP, protože jsem nikde nenašel alespoň polo-podrobný popis jeho funkce, tj. to o čem si píšeme. Nejsem schopen nasimulovat chování třeba 20 stanic. Stačila by mi jednoduchá tabulka. Každá stanice posílá 10 proměnných a 10 čte a počet stanic narůstá - hodnoty- časy předání tokenu, čas vykomunikování zápisu, čas vykomunikování čtení, vhodnost nasazení, s 2,5,10,15 mastery.
V příloze přikládám taktéž soubor XLS > ze kterého lze snadno určit nezbytně nutnou dobu pro přenos proměnných z jedné stanice na síti DB-Net. Množství přenášených dat, obsluha sériových linek, obsluha displejů a struktura a časování programu ovlivňují vytížení procesoru ŘS. Zahrnout všechny tyto vlivy do jednoduché tabulky je prakticky nereálné. Z tohoto důvodu zatím žádné takovéto tabulky vytvořeny nemáme.
> Nyní si vymýšlím, prostě takovou tabulku, nebo popis, s kterého by se dalo vyhodnotit chování DB-Netu a DB-Netu/IP
v rozsáhlejších systémech, popřípadě určit variantu komunikace.
Pokud potřebujete sledovat ŘS na více PC je z hlediska komunikace rozhodně výhodnější do sítě DB-Net zapojit jen jedno PC a z něj pak distribuovat data pro libovolné množství dalších počítačů. Zatěžování řídicích systémů, které mají regulovat, duplicitní či několikanásobnou komunikaci jen proto, abyste dostal data do několika počítačů je z hlediska komunikace neefektivní. Vizualizace by snad měla sloužit k zobrazení hodnot technologie a nikoliv k online řízení v reálném čase (toto již provádějí řídicí systémy samy).
> Nemám z čeho vycházet. Co komunikovat po DB-Netu co ethernetu, jak to rozdělit na sítě, aby průchodnost byla co největší a kde udělat obě komunikace, jednu pro stanice a jednu pro PC.
Pokud požadujete maximální průchodnost sítě (největší objem dat do vizualizace na PC), pak řešením je buď využití spojení ethernetem s každým jednotlivým řídicím systémem (po ethernetu mohou komunikovat systémy i mezi sebou), nebo do PC použít víceportové komunikační karty a na jejich jednotlivé porty připojit co nejmenší podsítě DB-Netu (v tomto případě komunikaci mezi ŘS z různých sítí musí zprostředkovat PC).
> Ze souboru XLS si mohu odvodit čas komunikování proměnných, ale co čas pro předání tokenu? Jaký objem dat mám připočítat na režii tokenu? Jaký čas na předání tokenu pokud žádná stanice nevysílá?
Toto je popsáno v dokumentaci protokolu DB-Net, který přikládám.
> Má vliv na zatížení sítě umístění modulu NETStat v procesech s různou periodou (jedna sekunda, 10sekund)? (je jedno v jakém procesu je modul).
Umístění modulu NeTStat nemá vliv na zatížení sítě. Hodnoty stavů stanic v maticích tohoto modulu se aktualizují dle vyřízení komunikací s příslušnými stanicemi.
> Dále co říkáte na kombinaci - komunikace mezi stanicemi DB-Net - komunikace s PC DB-Net/IP.
Toto je samozřejmě možné. Opět je nutno zvolit vhodné parametry obou komunikací (četnost vyčítání, množství dat, atd.). Pokud by však byla možnost využití ehernetové komunikace na všech stanicích, tak jak již bylo uvedeno v předchozí korespondenci, doporučuji využít pro všechny stanice komunikaci DB-Net/IP. Pro snížení režie na přenos dat také doporučujeme přenášet matice na místo jednotlivých proměnných či bitů. Pokud máte na mysli routování do sítě DB-Net, opět již bylo popsáno v předchozí korespondenci, musíte brát v úvahu vytíženost systému jak sériovou tak ethernetovou komunikací. Regulační část programu na takovémto ŘS proto musíte vhodně zvolit s ohledem na tyto komunikace.
> Dále by mě zajímalo, jestli existuje možnost ,,prioritního vysílání", tj. potřebuji něco rychle odeslat a potom ať komunikace probíhá jako před zásahem.
Toto možné není.