Připomeňme, že čekání na dokončení komunikace ovlivňuje atribut timeout kanálů nebo jiných komunikovaných elementů. Pokud je timeout nastavený na hodnotu 0 (což je výchozí nastavení), na dokončení komunikace se nečeká, použije se hodnota změřená při předchozím čtení a samotné čtení je dokončeno na pozadí.

Přístroje vykonávají svoji činnost periodicky podle nastavených parametrů nebo od události (například od uživatele nebo jiného přístroje). Control Web pracuje v časových krocích. Jakmile přijde okamžik, kdy je potřeba aktivovat některé přístroje, Control Web nachystá seznam přístrojů, které mají být aktivovány a zahájí časový krok v němž aktivaci provede. Na začátku časového kroku zjistí, jaké kanály budou přístroje potřebovat a zahájí jejich čtení. Až do tohoto okamžiku je chování Control Webu 7 a 8 stejné.

Nejprve si popíšeme, jak bude pokračovat Control Web 7. Pokud některé čtené kanály mají timeout nastavený na nenulovou hodnotu, zjistí Control Web maximální timeout a po tuto dobu čeká na dokončení čtení. Po celou dobu čekání nejsou aktivovány žádné další přístroje. Nemůže být prováděn žádný další časový krok, celá aplikace čeká.

Následující obrázek ukazuje aktivace dvou přístrojů periodicky jednou za sekundu. Přístroj P1 čte kanál s nenulovým timeoutem. Skutečná doba komunikace je 0,2s.

Control Web 8 na začátku časového kroku zjistí, které přístroje potřebují čekat na dokončení komunikace a jejich aktivaci odloží. Ostatní přístroje aktivuje ihned. Jakmile je dokončena komunikace, na kterou čeká některý přístroj, je proveden nový časový krok a přístroj je aktivován.

Přístroje, které čekají na dokončení komunikace mohou být aktivovány později než přístroje se stejnou periodou aktivace. Svým čekáním však nezdržují běh ostatních přístrojů.

Zajímavá situace nastane, pokud budeme přístroj P2 aktivovat periodicky a v určitý okamžik aktivujeme přístroj P1, který čeká na komunikaci. Jak to dopadne v Control Webu 7 ukazuje následující obrázek.

Přístroj P2 se dostane do skluzu. Čím bude delší čekání na komunikaci, tím bude skluz větší. Na obrázku je vidět, že Control Web se snaží dohnat skluz, tedy provést všechny aktivace, které nestihl. Pokud bychom potřebovali aktivovat P1 znovu, dřív než Control Web dožene skluz, dostala by se aplikace do trvalého skluzu. To je chybný stav, aplikace by měla být navržena tak, aby tato situace nemohla nastat.

V Control Webu 8 se stejná aplikace do skluzu vůbec nedostane.

V předchozích verzích systému Control Web nebylo čekání na dokončení komunikace s využitím timeoutu prakticky vůbec používáno. Čekání zdržovalo aplikaci. Pokud došlo k chybě komunikace a všechna čekání se protáhla na celý timeout, dostávala se aplikace často do skluzu. Nyní již nic nebrání používat timeout k řízení čekání na komunikaci.