Sure, I've testing over TCP and the broadcast unit and the device disconnects and only recovers manual on save again on the gateway.
Sure, I was using the function for bulks HR writes with codes 16/23.
When using RTU over TCP the CRC is not important after all, right? So, the payload size should be always be expected.
@pturmel, would you verify on your code if the device crashes when using unit = 0?
Not correct. RTU over TCP simply means the actual serial port is remote, but all other serial semantics apply, including the CRC.
Not supported on RTU. I might have time to experiment with unsupported functionality in July or August. Getting my modules ready for v8.3 is second only to bugfixes now.
Hey @pturmel! The module looks awesome! I am currently using KepServerEX/TopServer or ACM for Modbus communication, specifically for Lufkin controllers (and more specifically for ELAM support). Reading through this (impressively long) thread, it looks like your module supports ELAM; thank you and well done! One of the other reasons I am using tools like KepServer/ACM is for their “scheduling” service, to manage the synchronous polling of a slave device via a single master. Does your module do anything to support scheduling one slave device at a time? Based on the thread, it sounds like it, but I wanted to ping you to be sure.
I would LOVE to have a native Ignition solution to be able to jump that hurdle, because those 3rd party tools are never cheap, especially at scale.
There is no 1:1 equivalent.
But the driver does round-robin scheduling of requests to units, and has per-unit rate limits. If, in a single poll rate, you have multiple requests to each of four units, they'll be executed like so:
If the each set of requests takes longer than the per-unit rate limit, then the poll will smoothly run through all of the requests from start to finish, then wait for the next poll start.
If the four units' requests are quicker than the rate limit, then there will be pauses and/or re-ordering inserted to fit the constraints.
Perhaps you should test with your application? (All of my non-free modules honor Ignition's two-hours-at-a-time trial mode.)
Huge! I am going to test it immediately. I’ll reach out if I have any questions.
Hi @pturmel - hope you’re going well.
I just wanted to say we’ve now finished commissioning our application with your advanced modbus driver, where we use redundant servers each with redundant modbus links to the safety PLC, and the system is now in production. This included various failure mode tests (single network link failure, dual link failure, redundant server failover, reboots). Your driver has been robust to all, in that it either recovered once reconnected or correctly showed it was connected to 1 of the 2 redundant PLC addresses.
Thanks for putting in the effort to add redundancy to your driver - it works a treat!