# IPSCADA / IDP 680-6100 Modems **URL:** \ **Category:** Ignition\ **Created:** [February 9, 2024, 4:38pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487 "2024-02-09T16:38:16Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![dnsfontenot](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dnsfontenot](https://forum.inductiveautomation.com/u/dnsfontenot)\ **Post date:** [February 9, 2024, 4:38pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/1 "2024-02-09T16:38:16Z")
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. Thanks, David 832-913-230 ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 9, 2024, 5:27pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/2 "2024-02-09T17:27:07Z")
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. ---
**Author:** ![dnsfontenot](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dnsfontenot](https://forum.inductiveautomation.com/u/dnsfontenot)\ **Post date:** [February 9, 2024, 6:05pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/3 "2024-02-09T18:05:37Z")
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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [February 9, 2024, 6:16pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/4 "2024-02-09T18:16:49Z")
> [@dnsfontenot](#): > > Fails once a larger request for data is executed. You could try lowering the "Max Per Request" setting for whatever data area this. Do you have a Wireshark capture that shows the difference in behavior between the two modes? ---
**Author:** ![dnsfontenot](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dnsfontenot](https://forum.inductiveautomation.com/u/dnsfontenot)\ **Post date:** [February 9, 2024, 9:30pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/5 "2024-02-09T21:30:16Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 9, 2024, 9:32pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/6 "2024-02-09T21:32:45Z")
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. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [February 9, 2024, 11:52pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/7 "2024-02-09T23:52:42Z")
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. ---
**Author:** ![diat150](https://avatars.discourse-cdn.com/v4/letter/d/a587f6/32.png) [@diat150](https://forum.inductiveautomation.com/u/diat150)\ **Post date:** [February 10, 2024, 8:12pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/8 "2024-02-10T20:12:48Z")
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. ---
**Author:** ![dnsfontenot](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dnsfontenot](https://forum.inductiveautomation.com/u/dnsfontenot)\ **Post date:** [February 12, 2024, 2:16pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/9 "2024-02-12T14:16:41Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 12, 2024, 2:54pm UTC](https://forum.inductiveautomation.com/t/ipscada-idp-680-6100-modems/85487/10 "2024-02-12T14:54:13Z")
You might consider my [alternate Modbus driver](https://inductiveautomation.com/moduleshowcase/module/automation-professionals-llc-advanced-modbus) for Ignition. It has the per-request delay option that @diat150 suggests (as a per-slave unit timing option). More here: > [@Automation Professionals' Advanced Modbus Driver](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312): > > Automation Professionals is pleased to announce the first beta for its Advanced Modbus Driver, for Ignition version 7.9. Key features: Server mode, emulating one or more slave [devices](https://www.automation-pros.com/modbus/UserManual.pdf), using any of the three typical connection types, including simultaneous connections of multiple types. Client mode, incorporating all three connection modes in one driver. Support for Modbus Function Codes 20 and 21, File Records. Configure protocol tweaks for troublesome devices per slave unit, enabling suppor…