Kepware Connectivity to Modicon over Modbus TCP/IP

[Osman]

I am running into a strange issue where I have 30 channels with one device per channel configured in KepserverEX. These include 3 Omni channels, 1 Triconex and rest 26 are Modbus TCP/IP device channels. The Triconex Channel has over 20,000 tags and is the biggest channel-device configured in terms of volume of tags. Also one of the Modbus device channel is configured for 12000 tags. All of the devices including these two channels are fetching data very smoothly and are updated well-within time. The scan rates vary from 1-3 secs. However we are facing an issue where we are getting very much delay in receiving data from one of the Modbus Devices which has only 10000 tags. The settings in Kepware other than the scan rate have been kept the same for all devices but the delay in getting data is problematic for only one of the particular Modbus devices having tags of around 10000 which is very less than Triconex Device which have 2-3 times the number of tags and another Modbus device having tags greater than this one. Any possible way-around or diagnosis to verify if this is an issue from the PLC end? What can be done to improve the data update rate in Kepware.

[billysmithde2]

There are several factors related to OPC update time with Modicon devices. The main one, in addition to the number of tags requested, is scantime. I can think of (in no particular order): 1. Scantime 2. Relative tag location in memory 3. Number of tags 4. Number of simultaneous sockets in use by OPC 5. Specific device capability You have attributed your slowdown to only one factor - number of tags. Can you comment about the other factors? What is the problem device scantime? Understanding that it only makes sense in context, so what are the scantimes of the devices you are happy with compared to this one? Are they all the same device - say NOEs, or ETYs, or same platform, Premium, or M340, etc? Are they all Modicon? Is the tag mix all the same - relative tag location is important in optimizing performance. A function code 3 can read 125 registers, so case would be 10000 tags/125 tags per read, and we would have 80 requests total to refresh each and every tag. But if they are not close together, you would need more. Worst case (not really possible, but it represents the upper limit) would be 10000 separate Modbus reads, one per tag/register. If each takes a certain amount of time... the update times will be very different.