I am currently working on a project that involves communication with 5 inverters using the Modbus RTU protocol.
I have implemented a Modbus TCP-RTU Bridge to implementate the communication,
allowing Gateway to directly read Modbus TCP.
Each inverter has a unique Modbus address, and reading holding registers works well under normal conditions.
However, I am experiencing significant delays, up to 2 minutes,
when turning off the inverters.
Upon investigation, I observed a drastic increase in connection load, up to 7000%, during the device shutdown.
The device log reports the error:
"ReadHoldingRegistersRequest - Received response with ExceptionCode: 0x0B (GatewayTargetDeviceFailToRespond)."
I believe this issue is connected to the increased connection load, causing delays in data reading.
I am seeking assistance to resolve this problem and improve the efficiency of Modbus communication during inverter shutdown. Any advice or suggestions would be greatly appreciated.
Modbus RTU is a pretty dumb protocol. It simply cannot handle the situation you are presenting. Ignition will be running along, making many requests per subscription period. Each one has to be answered before the next can be sent, to any slave on the same link. Full stop.
You can mitigate somewhat by using a short execution timeout.
You could also switch drivers: my alternate Advanced Modbus driver has a minor optimization for this case--when any message for a given slave times out, all pending messages for that slave are also marked as timed out. It doesn't totally eliminate the problem (fundamental to RTU), but reduces the blow-up.
Instead of defining a single Modbus connection in Ignition, define one for each slave/unit ID. You'll still experience some delays unless the gateway is capable of "demoting" an offline slave, but it might not be as bad...
Thank you for your prompt response and valuable input. I'm relatively new to the world of Ignition, and your suggestion to use direct OPC address readings using syntax like [Device1]1.HRF1 is insightful.
Could you please elaborate on the advantages of using direct OPC address readings over the mapping method I'm currently using? I appreciate your expertise and would like to understand better how this approach could potentially enhance the performance or efficiency of my system.
Thank you for your insightful response regarding the challenges with Modbus RTU during inverter shutdowns. Your expertise is highly valued.
In your suggestion, you mentioned using a short execution timeout to mitigate the situation. Could you please clarify whether you are referring to the execution timeout of the OPC device or the execution timeout within the scan class of tags?
Additionally, I appreciate your offer regarding the alternate Advanced Modbus driver. Before considering this option, I need to discuss it with the project stakeholders. Could you provide more clarity on whether the package cost applies universally across all supervisors or if a separate package is required for each supervisor that requests it?
I sincerely appreciate your advice on optimizing Modbus communication in Ignition. I've implemented the solution you suggested by defining a separate Modbus connection in Ignition for each slave/unit ID. To test this, I recreated the configuration locally at the bench.
I set up two OPC devices, both on the same IP address. One device reads Modbus slave address 2, and the other reads Modbus slave address 3. This configuration has shown a noticeable improvement with only two inverters, reducing the delay to approximately 10 seconds.
However, when both devices are active, the OPC communication overload remains at a manageable 1%. However, if I deactivate one device, the overload on the still-active device rises to 700%, while the turned-off device displays an overload of 1400%. This overload further escalates to 2000% when both devices are turned off.
I'm curious to know if you anticipate that increasing the number of turned-off elements could further escalate this communication load. Additionally, could high loads potentially cause other issues for the supervisor beyond communication challenges?
Your insights on this matter would be immensely valuable.
Thank you again for your expertise and assistance.
Unfortunately I think the only real solution to this will be a 3rd party solution. Phil's driver can handle this scenario, as he mentioned, and I know that Kepware's KEPServerEX has support for device demotion as well.
Your Modbus TCP-RTU bridge has a timeout. The Ignition Modbus device has a timeout also. The bridge timeout must be less than the Ignition device timeout. If you don't do that the bridge will start queuing requests and get very slow.
The timeouts have to be a low a possible. You will need to experiment to figure this out. The bridge timeout should under 200ms.
Thank you for your assistance with . I appreciate your insights. While it seems a third-party solution may be necessary, your guidance has been invaluable.
