I am using Kepware and Ignition together to poll a set of SCADAPack PLCs on a multidropped serial radio network using a Modbus/TCP to Modbus serial gateway.
My understanding is that Ignition subscribes to the addresses in each PLC that it needs the Kepware OPC server to read. The Kepware OPC server does its thing, polling that data based on how I setup the OPC server. Ignition polls the Kepware OPC server at a rate I select in the scan class. Kepware just returns the last known value of these addresses. Kepware sets the quality of each address/tag, not Ignition.
So adjusting the rate of the scan class has no affect on what Kepware does with polling. This is the way it seems to work, at least. Does the Ignition OPC server work completely differently than the Kepware one?
Ignition will request updates based on the scan rate configured in the designer for a tag/group of tags.
Kepware has lots of configuration options which control how it responds to this.
For example
It can be configured to respect the client specified scan rate(client being for example Ignition)
It can be configured with a ‘lower limit’ rate, that it won’t scan any faster regardless of what the
client wants.
etc…
Let’s say I have one Modbus serial slave that I connect to through a Modbus/TCP to Modbus serial gateway. The Modbus slave works at 1200bps and has minimum turnaround time of 1 second, but the link is flawless. I am only interest in reading one 4x register. The Ignition (or Kepware) OPC server is set with the appropriate timeout of 2 seconds. What happens if I create only one Ignition tag with one register in its source with a scan class I have configured with a rate of 100ms?
Ignition’s OPC-UA client will ask whatever OPC-UA server it’s talking to to poll the register at 100ms.
Both servers under normal conditions will then try to poll your Modbus gateway every 100ms. This is almost certainly too fast. Whether the gateway returns its latest value, or gets backed up attempting to read too fast and returns a Modbus exception code (likely 0x0B GATEWAY TARGET DEVICE FAILED TO RESPOND) is an implementation detail of the gateway and you’ll have to dig into its documentation or call their support.
I set the gateway so it does not make up its own error messages. The gateway is transparent. So the gateway’s timeout should be about 1100ms, in my example. Who is asserting that there’s been a timeout? The Ignition OPC server and Kepware OPC servers have their own timeout settings. Does the gateway itself get mad when the request for a 100ms poll rate is not satisfied? Who changes the quality of a tag from 192 to whatever the timeout error quality value is?
If you are trying to poll at 100ms over 1200baud connection you are going to get connection timeouts especially if your going over a radio network. You should expect at least 30-50mS just for the radios to sync up. No way your going to update at 100ms, especially if you are trying to communication with more than one device over a radio network.
Here’s how to best optimism your set-up given these assumptions - You have Ignition talking to Kepware which is talking to (4) PLCs over radios.
Add (1) PLC device to each channel. So Radio1 channel contains PLC1, Radio2 channel contains PLC2, etc.
Set-up the timeouts for each device under the Timing tab. On my radio network I have the Connection timeout = 3 seconds, Request timeout = 1000mS, Fail after 7 timeouts. You might need to adjust these settings for optimal performance.
The reason you want each device in a separate channel is because when a device in a channel is having communication problems, all the devices in that channel will get delayed until the device that is having communication problems either makes a successful communication or that device timesout. The other reason you want a separate channel for each device is in item #4 under In Ignition.
In Ignition
Create (4) Scan Classes. (PLC1, PLC2, PLC3, PLC4)
Set the update rates of the Scan Classes to slight different times, i.e. 5300mS, 5500mS, 5700mS.
Assign all the tags for each device to it’s own Scan Class. So all the tags for PLC1 should be in scan class PLC1, all the tags for PLC2 should be in scan class PLC2, etc.
Create tags in Ignition to monitor the status tags in Kepware. At minimum I would set up the following tags - Channel tags (_FailedReads, _FailedWrites, _MaxPendingReads, _MaxPendingWrites), Device tags (_Error and/or _NoError) Since we have created a separate Channel for each Device, monitoring the Channel tags will give us information about that one device as apposed to any device under that Channel.
In the PLC
If possible, block all your data together.
When Kepware polls the PLC for data it does so in blocks. There is a maximum size block that can be requested over Modbus, 120. If all your data is within one block size then Kepware only has to make one communication transmission to the PLC for all the data. If your polling data outside the maximum block size, then Kepware has to make two or more communication transmissions to get the data. Kepware is actually efficient in the fact that, even if your data isn’t in consecutive memory locations, it’ll still try to grab all the data in on block. So let’s say I’m asking Kepware to give me the value from memory locations 1, 5, 32, 102, Kepware will grab the data block 1-102 and parse out the the requested data for Ignition from that block. If your requesting data from memory location 1,8, 132, then Kepware will have to make two communication transmissions to get the required data.
How it all fits together -
Since you are going over a radio network, the largest part of the latency is in the overhead of the equipment, the radios have to sync up, transmit the request, switch between send and receive, transmit the requested data. So we want to minimize the latency of the equipment by grabbing all the data from a remote site in one shot.
In Ignition we have setup (4) separate Scan Class for each PLC. We have assigned each tag to it’s PLC’s own Scan Class. Ignition sends this information to Kepware. Kepware sets up (4) different groups of tags, one for each PLC because we told Kepware they are in different Scan Classes. Kepware starts polling the PLCs based on the Scan Class update rate given to it from Ignition. Since we set up our Scan Classes with slightly different update rates, this should allow Kepware to only try to make one communication transmission over the radio network at a time, thus limiting the amount of collisions. Finally we monitor the Kepware Channel and Device tags to see what’s happening on the network and make adjustments to our Ignition Scan Class update rates and Kepware Device Timing to give us the fastest most reliable communications.
You are almost always correct and helpful, but in this case, not so much. Reluctanly… Modbus/TCP to Modbus serial gateways support a limited number of TCP connections, usually 8. You cannot setup separate channels for each remote Modbus slave unless you have 8 or fewer slaves. Make that 7 if you want to leave a channel open for diagnostics or programming. This is a rare circumstance. And the nature of the beast is that it can only talk to one serial slave at time, so having a gateway with a gazillion ready sockets wouldn’t help. That’s probably why the Modbus gateway OEM don’t bother with servicing a lot of sockets.
Jay, you are correct, Modbus TCP/IP to Serial Gateways support a limited amount of TCP connections. Even though you stated that you are using a serial radio network I was thinking there was a Modbus Gateway at each remote PLC. So you are correct that multiple channels in the OPC server would be of no benefit or possible in your case.
But, creating seperate Scan Classes in Ignition for each PLC and blocking the data together in the remote PLCs will give you the best performance aside from using a Master PLC to poll all the remote PLCs.