Hi Phil,
We ran some more tests regarding the communication instability issue we're experiencing.
We believe it might be a RequestDelay problem, but we're not sure.
We compared it to the Kepserver driver, which is working perfectly, and I've sent you an email with the Wireshark screenshots and the Ignition wrapper.log file to see if we can determine what's happening and resolve it.
Regards, Andrés
While I'm not @pturmel, I'd suggest actually sending the wireshark captures to him rather than screenshots of the captures. That would make it much easier to analyze rather than looking a pictures, and I'm guessing he'd also prefer it.
Hi Michael,
Yes, sorry, I meant captures, not screenshots. My mistake.
Hi @pturmel
We ran in to an issue using tag scripting (UDT acquired from Ignition Exchange) to change the device IP when communications failed. With a major network outage, the constant device.hostname type changes seemed to overwhelm something config related (idb?) and our redundant gateway was very unhappy - tried several full pulls and then just stopped.
Looking into third party alternatives now.
I see in your manual that it supports two separate IP address connections for each device and that it will alternate polls if they are both good.
Is it possible to make one the primary that it always uses? our two connections are hardwired (ADSL) and the second is a cell modem. the cell modems are typically much slower and much less reliable connection and we are trying to reduce data usage on them if possible, so I don't want it constantly using it if the hard-wired connection is good.
Thanks
Many modbus devices close the TCP session after inactivity (often 10seconds). This would mean the back would keep disconnecting and having to reconnect. I suspect this is why the advanced driver is configured to split the polling across the primary and secondary (to avoid this, by keeping the secondary alive and healthy).
Not practical, no. The only way to reliably tell that the connection is good is to route some of the traffic through it. Anything other than a 50-50 split is a nightmare.
Hi @pturmel
We are upgrading to Ignition 8.3.9 while using Advanced Modbus 1.2.3 (b262241428). Any concern?
There is a beta addressing connection breakage/stalls of Modbus TCP client connections on very lossy networks (wi-fi). You can snag it from my common downloads folder if you wish to try that instead.
Note that no build of v1.2.3 is officially a production release.
Hi @pturmel
Any documentation on differences between 1.2.3 versions ?
No, use latest one. The others were buggy.
Automation Professionals is pleased to announce a new Production release of this module, fixing some bugs in v8.3, and moving the "Ignore TxID" feature to a separate, default false, configuration setting.
For Ignition v8.3.x: v1.2.3.262571909
Breaking Change: Users relying on the Ignore TxID feature will need to set that configuration boolean after upgrading. Concurrency=1 will default to Modbus TCP spec-compliant TxID handling going forward.
Great news!!
We’ll test it ASAP.
Thanks Phil
Regards, Andrés
