Čeština
Dobrý den,
řeším rychlost vykonávání příkazů a funkčních bloků.
Dotazy Modbusem mají odezvu ze zařízení do 10 ms (měřeno Wiresharkem, zrcadlením na switchi). Ale po přijaté odpovědi následující dotaz odchází až za 100 - 150 ms.
Dá se toto nějak zoptimalizovat?
Např. čtecí cykly v následujících programech trvají cca 800 a 500 ms. Z toho usuzuji, že vykonávání RS + 2. bloku (který žádný Modbus dotaz nepošle) trvá 300 ms.
Je to možné?
Případně jak mám počítat délku trvání?
Myslel jsem si, že pokud v bloku udělám FOR cyklus a nějaké rozhodování, tak by to mělo být na 1 cpu step?
Odpovědi 8
Dobrý den,
z přiloženého obrázku nepoznám, jak přesně je do programu blok modbusu zakomponován.
Blok fbModbusTCPmas2 (stejně jako ModbusTCPmas) má v sobě stavový řadič. Při spuštění se v prvním cyklu PLC hledá příslušný příkaz z pole, další cyklus se kontroluje zda je nastavena na kanálu správná IP adresa. Pokud není trvá další cyklus než se nastaví a pak se v dalším cyklu zahájí navazování spojení. Jakmile je spojení navázáno odešle se zpráva a přejde se do stavu čekání na odpověď. Po přijetí odpovědi se přejde znova do stavu, kdy se hledá, zda je k odeslání další příkaz.
Rychlost je tedy závislá na tom, zda blok běží v automatickém režimu, zda mění IP adresy a jak je dlouhý cyklus PLC.
Dobrý den,
program běží ve free wheeling modu, funkční blok cyklicky volá fb ModbusTCPmas pro datové oblasti různých slave ID, které jsou v poli. Následující dotazy (na obr. níže a řiložený capture) jsou datově identické, akorát pro různá slave ID. Červeně jsem označil delší prodlevu.
V přiloženém souboru je capture z Wiresharku. Když to teď píši, tak mě to napadlo - před dotazy, kde je delší prodleva, posílá PLC většinou ACK pakety (TCP). Vypadá to tedy, že cyklus je cca 25 - 40 ms a pokud se pošle ACK, tak na to padne celý cyklus.
Šlo by to nějak zychlit?
Třeba, když se má poslat ACK, tak aby se další PUSH paket poslal ihned a ne až při následujícím průchodu?
Nebo poslat datový PUSH paket s ACK flagem?
Dobrý den,
byla uvolněna knihovna ModbusRTU verze 4.4 (dostupná přes Mosaic Updater), která snižuje počet cyklů, kdy bloky ModbusTCPmas a fbModbusTCPmas2 pouze připravují data k odeslání, což by mělo celkově urychlit komunikaci.
Co se týká TCP vrstvy, tu PLC přímo neřídí. Rychlejší příprava dat se na ni nicméně projeví.
Dobrý den,
děkuji moc. Rád vyzkouším.
Akorát mi nejde sestavit projekt - hlásí to ... POU FBMODBUSSLAVE - detaily viz můj email.
Dobrý den,
omlouvám se, knihovna používá nové funkce z knihovny ComLib v3.8, která nebyla uvolněná. Nyní by měla být dostupná, takže by mělo stačit spustit Mosaic Updater a v projektu knihovnu ComLib zaktualizovat.
Dobrý den,
vyzkoušeno, komunikace se výrazně zrychlila. Děkuji.
Nicméně na síti vzrostl provoz - místo 1 datového (PUSH) a 1 potvrzovacího (ACK) se posílá ještě "nový" paket ACK s aktualizovaným oknem, t.j. poté, co se ze vstupního bufferu vyzdvihnou data (odpověď) a zpracují se, tak se s tímto jde hned na ethernet kabel. Domnívám se, že TCP window update (jak to hodnotí Wireshark) není potřeba okamžitě propagovat. A jako wish list - kdyby to šlo vše v 1 paketu :-). Chápu, že jsem jako žena, ale v tomto případě to má technický argument.
Obr. 1 - odezva je nyní 30 - 60 ms (oproti 160 ms před Vaší úpravou)
Obr. 2 - Foxtrot posílá 3 pakety (sice po 1.7 a 4.1 ms, ale stejně - je jich nezvykle hodně :-) )
Obr. 3 - ukázka, že v datovém paketu může být kromě flagu PUSH i flag ACK (přání a cíl)
Dobrý den,
chování vrstvy TCP je dáno TCP stackem operačního systému, který knihovna nedokáže přímo ovlivnit.
Takže smolařík :-(.
Nicméně je mi divné, že před Vaší úpravou se posílaly pouze 2 pakety a nyní s posílají 3 pakety. Z toho usuzuji, že Vaše úprava ovlivnila i chování TCP stacku.
Máte tam nyní nějaký flush na socket nebo něco takového?
Tento dotaz je vyřešený.