Max no. of Modbus TCP Connections

Hi

We have a client that has about 800 plcs that send data via modbus TCP to Ignition.
I need to confirm how many OPC ua connection one Ignition gateway can handle with proper hardware reaource?
Is there any hard coded limitations?

Inbound connections to the server or outbound connections as an OPC UA client? What version of Ignition? What do the Modbus TCP devices have anything to do with this?

Okay, so not OPC UA connections, but 800 Modbus TCP devices / connections. (updated the post title)

Yes it’s possible with good hardware. There is no artificial or license limitation, except maybe on Edge.

You will find it’s a bit awkward to have that many devices, though. The only method of bulk configuration is via system.device.addDevice and practically none of the gateway’s table/record UIs gracefully handle large quantities, so the device page will just be a big list of 800 devices.

Thanks Kevin
What about the limitation of number OPC UA out bound connection as client?

No limit there either.

1 Like

I know in theory we can connect up hundreds of devices, but… any “Best Practices” for practical device limits? I have a project with about 600 separate Modbus devices (~45,000 tags. 95% read-only). The system Ignition is replacing used multiple front-end servers running Kepware. The backend SCADA system (let’s call it “Brand W”) talked to the Frond End servers to get the data. Client would rather have a 100% Ignition system and get rid of the Front End servers. I’m sceptical about having everything just come into a single gateway. Am I setting myself up for failure here? Or just paranoid?

There are other customers successfully using more than 600 Modbus connections. The worst part is creating the connections to begin with, or managing them after the fact. Just need to have decent hardware.

As long as these aren’t connected over radio or serial that requires slow or scheduled polling periods you should be okay. If they are, then I’d recommend using Kepware instead.

Thanks for the quick reply. Just paranoid, I guess!
I created a script to create all the devices initially - much easier than doing by hand. Fortunately I could turn an Excel list of devices into a python script with some editting.

Hey Kevin, can you help me understand the reasoning behind recommending using Kepware when connecting to multiple devices over radio? Does Kepware create a benefit rather than connecting directly to Ignition? Thanks.

It’s for a couple reasons.

  1. Kepware allows precise control over the polling, by using channels, devices within channels, and with their scheduling plugin. Our driver offers nothing like this.
  2. Our Modbus driver is very old, and like the other handful of old drivers, it’s based around the flawed idea that it should basically be a state machine that is always trying to be connected. This works fine for most drivers in most scenarios, but it’s pretty flawed for Modbus, where it’s common to have slow polling times (longer than say, 10-15 seconds), and it’s also common for Modbus slave implementations to close an inactive TCP connection after 10-15 seconds. You end up with all your devices constantly cycling between disconnected/reconnecting/connected and all your tag qualities blipping back and forth as this happens.
1 Like

Hmmm. I probably ought to make my alternate driver more robust for this case.

Might be a nice alternative. Some day I’m gonna get a chance to rewrite ours and at least fix the flawed assumption that losing your connection is an error state that must be recovered from immediately, but I don’t know if we’ll ever do anything to match the channel/device model or scheduling plugin flexibilities.