Hello all!
Is anyone using IPSCADA or connecting to IDP 680 or 6100 series satellite modems?
I am currently using Ignition internal Modbus driver connected to IPSCADA for Modbus RTU over TCP driver. I am able to get data from the devices, however, I seem to run into a timing issue when requesting multiple data polls. Almost as the Ignition requests data to fast since it's on slow connection. Is anyone successfully using these older technologies? If so, please let me know as I'd like to review some configuration settings.
Modbus RTU has strict timing requirements that a high-latency satellite connection probably cannot achieve. Consider using true Modbus TCP gateway on the far end to manage the RTU strings with compliant timing.
Thanks for the response and will look into other options.
Agree timing is culprit but not sure if there is a way to make the changes.
What I find interesting is if I have my Data Mode set to Subscribed it works perfectly to connect and collect all 79 Modbus registers of data. The problem is that when the connection is established I get multiple requests successfully from the device burning up costly airtime before I can disable the connection via script.
Based on documentation I'm working with Polled and One Shot approach to only request 1 data poll for the same total of 79 modbus registers. I see the same 2 requests go out with the subscribe model but get a failed data response. However, If I ask for smaller set of Modbus registers using one shot I see the single request and data comes back. Fails once a larger request for data is executed.
Kevin,
Default max holding is 125, that didn't work out the box. I tried lower to 80 to cover my max request but I couldn't get all the registers in a single poll to work even with subscribed model.
Based on my experience with other SCADA platforms, Modbus doesn't like more than ~50 registers per request unless Ignition platform does something "magical".
After much successful testing, I have set the max holding registers per request to 48 and that worked with subscribed model. It does send out 2 requests to cover first 48 registers, then a second request for the next set of registers which is typical behavior.
So that works, but still unsure why the one shot performs differently...
I'll work on getting wire shark setup to capture data to help determine what send/receive packets are being generated.
The Modbus specification indicates that 125 registers can be read in one packet, and 123 consecutive registers written with one packet. Implementers can impose lower limits, and these people obviously did.
This is a good candidate for MQTT. Put an Ignition Edge device on the remote end that does the Modbus polling locally and pushes the data to your central Ignition system. Granted, this involves cost of licenses and hardware, but this is exactly what MQTT was designed to help solve. The initial BIRTH message will have a decent amount of data (you'd want to use compression and aliases), but after that, you'd only have data that changes sent over the modem rather than polling for data constantly.
I would try a different modbus driver, perhaps kepware or autosol. I dont know if Ignition has a setting for delay between polls but most other drivers do. I have setup comms to modbus devices over satellite including inmarsat bgans many times over the years and have never had an issue. It appears the IDP has a few other pieces in the puzzle but I would experiment with kepware or autosol to see if you get a better outcome.
Thanks everyone. I was trying to avoid using 3rd party tools when IA has an internal Modbus driver.
I have opened up a ticket with support to provide data sets on subsribed model that polls and brings back data where the one shot setup polls but fails. If no resolution I'll look at 3rd party polling engines for the Sat modems. I'll post my findings in here to help anyone in the future.
You might consider my alternate Modbus driver for Ignition. It has the per-request delay option that @diat150 suggests (as a per-slave unit timing option).