Nejprve uvedu příklad funkce obou módů. Řekněme, že máme v bloku definovány 3 kanály za sebou např. takto:
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č.