Vítej, Host. Prosím přihlaš se nebo se zaregistruj.
24.09.2022, 19:54:50

Domů Nápověda Vyhledávání Přihlásit Registrovat
 
Fórum k produktům firmy ELSACO Kolín  

+  PROMOS fórum
|-+  Další firemní SW
| |-+  CW ovladače
| | |-+  Komunikuje se jen cast dat
0 uživatelů a 1 Host prohlíží toto téma. « předchozí další »
Stran: [1] Dolů Tisk
Autor Téma: Komunikuje se jen cast dat  (Přečteno 5472 krát)
anonym
člen

Příspěvků: 33



« kdy: 01.09.2010, 08:20:21 »

Mam aplikaci v CW, komunikuji protokolem Epsnet a komunikuje se jen cast dat, tj. pouze prvni bloky, ale ty dalsi ne. V cem je problem?
Zaznamenáno
libor
moderátor+

Příspěvků: 388



« Odpověď #1 kdy: 01.09.2010, 08:50:32 »

Ovladač pro Epsnet má 2 módy: BLOCK a ITEM, které se volí v sekci [GLOBAL]

Kód:
MODE BLOCK

nebo

MODE ITEM

V režimu BLOCK se provádí optimalizace komunikace setříděním požadavků, takže i v případě, že požadavky přichází z CW neuspořádaně, tak výsledkem (po setřídění) může být jedna komunikační relace.

V režimu ITEM se provádí zpracování požadavků tak, jak přichází z CW. Může se tak stát, že například při požadavku na 3 kanály dojde ke 3 komunikačním relacím.

Režim BLOCK má svoje výhody, ale pouze v případě nenáročné komunikace. V případě, že máte hodně dat, resp. chcete je komunikovat co nejčastěji (např. u aplikací typu data_driven), a požadavky na novou komunikaci dat se provádí dříve než se stihnou vyřídit všechny předchozí požadavky, tak vlivem setřídění dojde k tomu, že na některé požadavky nemusí vůbec dojít.

Stačí tedy změnit mód na ITEM a váš problém bude vyřešen.
Zaznamenáno

anonym
člen

Příspěvků: 33



« Odpověď #2 kdy: 02.09.2010, 04:33:18 »

Tak MODE ITEM pomohlo, ale mozna mi trochu unika smysl toho druheho modu  Jsem v rozpacích.  Skoro mi pripada jako nepouzitelny, kdyz komunikuje jen cast, nebo jsem neco nepochopil  Nevím co si myslet/Nerozhodný.
Zaznamenáno
libor
moderátor+

Příspěvků: 388



« Odpověď #3 kdy: 02.09.2010, 07:05:10 »

Nejprve uvedu příklad funkce obou módů. Řekněme, že máme v bloku definovány 3 kanály za sebou např. takto:

Kód:
BLOCK 2 OFFSET 10
REAL READ 40000
LONGINT READ 40001
WORD BIDIR 40002
END

V případě, že z CW přijdou požadavky na kanál 40000, 40001 a 40002 v tomto pořadí v rámci jednoho časové kroku (najednou), tak v obou módech dojde k vytvoření jedné komunikační zprávy, kterou se načtou data pro všechny 3 kanály najednou (data z bloku2, od offsetu 10 a délky 10).

V případě, že přijdou požadavky v pořadí například 40001, 40000 a 40002, tak v módu ITEM dojde k vytvoření 3 komunikačních relací postupně pro jednotlivé kanály, protože požadavky na sebe nenavazují.

V módu BLOCK dojde k setřídění požadavků, takže i v tomto případě se vytvoří pouze jedna komunikační relace, která načte data pro všechny 3 požadované kanály najednou.


Mód BLOCK tedy dokáže v určitých případech zmenšit objem přenášených dat, tj. komunikaci zrychlit, ale jak již bylo řečeno, není vhodný pro komunikaci, kdy dochází k rychlému vracení požadavků (zejména v aplikacích typu data_driven).

Obsluha komunikace se dá dělat v CW různými způsoby. Jeden z možných způsobů je zadat požadavky a čekat až se vyřídí (resp. čekat, jestli se vyřídí úspěšně). V takovém případě dává mód BLOCK možnost nezabývat se pořadím požadovaných kanálů, ale můžete se soustředit jen na logiku obsluhy výsledku komunikace - optimalizaci komunikace za vás provede ovladač.
Zaznamenáno

maxim
člen

Příspěvků: 32



« Odpověď #4 kdy: 02.09.2010, 07:35:27 »

A jak se může stát, že se v módu BLOCK setříděním požadavků, některý požadavek "ztratí"?
Zaznamenáno
libor
moderátor+

Příspěvků: 388



« Odpověď #5 kdy: 02.09.2010, 08:27:00 »

Požadavky se se v tomto ani jiném módu neztrácejí, "pouze" zůstávají ve frontě k vyřízení a jsou neustále "předbíhány" nově příchozími požadavky, které je přeskočí v rámci třídění.

Třídění požadavků se provádí podle čísla bloku a následně podle offsetu, takže po setřídění jsou ve frontě nejprve požadavky z bloku 1, pak z bloku 2, pak z bloku 3 atd. Postupně se tyto požadavky odebírají a komunikují.

V případě řízené komunikace se počká, až se požadavky vyřídí všechny a pak se pokračuje dál. Ovšem například v aplikaci typu data_driven je vyřízený požadavek téměř ihned vrácen k vyřízení ovladači.

Řekněme, že máme požadavky na data z bloku 1 a z bloku 2. Požadavky nejsou ve spojitém bloku, takže na vyčtení dat z bloku 1 potřebujeme například 4 komunikační relace a na vyčtení dat z bloku 2 potřebujeme 3 komunikační relace. Požadavky se setřídí, vyřídí se první relace pro blok 1, data se vrátí CW a pokračuje se druhou relací, pak třetí ... Mezitím CW data zpracuje a vrátí ovladači požadavek data z bloku 1. Ovladač si požadavky setřídí a opět vyřídí požadavek na data z bloku 1. Následně by pokračoval dále, ale CW opět vrátí požadavek na data, která ovladač vykomunikoval druhou relací, takže ovladač opět vyřídí tento požadavek. Výsledkem může být to, že na data z bloku 2 se nikdy nedostane.

V takové případě tedy platí, že je nutné nastavit mód na ITEM. Mód BLOCK na takový typ způsob komunikace není určen.
Zaznamenáno

Stran: [1] Nahoru Tisk 
« předchozí další »
Skočit na:  


Poháněno MySQL Poháněno PHP Powered by SMF 1.1.21 | SMF © 2011, Simple Machines Validní XHTML 1.0! Validní CSS!