Hi there. I'm communicating to a Omron CJ2M PLC with FINS TCP driver with Ignition and I checked some tags were being really slow refreshing its value. I separated some tags (4/200) to a faster tag group (mode: direct || data mode: subscribed || 100ms Rate). And the rest of the tags left them in default tag group with the same configuration except for the rate: 1000ms. And the behavior that I find is in the picture
I would understand this kind of response if I had tons of tags, but knowing that I have only 200/215 tags in total, and just 4 of them are in a faster rate tag group, is the result shown in the image expected? Or am I doing something wrong? In anyway, how can I improve communications so that I can avoid this overload and have more smooth reads from the PLC?
Some PLCs don't behave well when hammered at sub-second intervals.
You picture is low-resolution, so the response times aren't clear, but those indicate how quickly your PLC is responding to requests.
Based on the number of requests, I would guess your target tag addresses are scattered in the PLC, preventing bulk access to many tags with single requests. Try to fix that first.
I can’t tell for sure because it’s blurry, but those response times look like they are 3xx milliseconds… so your PLC is either already totally hammered and has no time for servicing comms, or you’re trying to access it remotely or over VPN or some other slow network.
Sorry about the Low Res photo. While I was waiting for a reply, I was trying some options on how to decrease the overload. And in the configurations of the device connection, I changed the Concurrent Requests from 2 to 8 (max) and improved a lot. Is it okay to leave it with 8? Or, you don't advise me at all to do it?
I changed back to 2 to get a better image of the first configuration explained:
I've putted a new photo with the values, even made a mistake of keeping 2000ms instead of 1000ms as in the beginning and the values are through the roof. Both PLC and Ignition are in the same network. I'm communicating through Wi-Fi but I've tested with ethernet cable and the stats don't improve at all.
The PLC has less than half of work memory, so it shouldn't be the PLC either. This doesn't seem like a normal behavior for these few tags. Am I missing something setting up comms?
It doesn't seem normal, but I'm not familiar enough with these PLCs to know what settings are available.
I would expect it has less to do with available memory and more to do with your program/cycle times, plus any available settings that affect comms servicing. Comms usually get serviced in whatever leftover time is available...
I understand your point but I have strong beliefs it's not possible or at least it will be one if not the last thing to try. The PLC program is dense. Changing the addresses and areas of work of the PLC will just be high cost effort to make. + PLC program isn't being developed by me. I need to know that I've reviewed all the other options.
It's Omron PLC, not Mitsubishi. And even not being a PLC that I work on daily basis, I'm confident that there were no settings that I missed that could affect communications this "bad".
Both Ignition and PLC are in the same LAN. Most of the times wireless but I already tried with cable and didn't see any improvement at all.
What is your opinion on increasing the value of "Concurrent Requests" in the Device configuration? Because I did increase the value and it helped a lot, but what's the downside?
If your PLC has free memory, consider copying the critical values into a contiguous block in your PLC logic. They'd be effectively read only, but you could read them much more efficiently.
I'd do it. Up to the point where it doesn't help any more.
I maxed out the value of concurrent request to 8. And the overload values decresead significantly. Check the photo I sent to the previous reply
The router is already old. But the online mode of the PLC values are changing smoothly in the PLC software. So, it doesn't make sense to be a network latency.
Oh well. That processor doesn't do class 3 messaging. You can get a comm module to do class 1 I/O, which would be screaming fast, but much more trouble to set up. (And a different option in my module.)
You had right. It is still going to be complicated to place all tags desired to read/write from ignition in a contiguous way but I guess I'm forced to do it for efficiency. Sorry for refusing to try it out the first time you told me to.
I resetted the concurrent request value to 2(default value) before testing it out.
Behavior of an amount of tags when scattered across memory areas:
Notice what you've done there is reduce the required number of requests from 4 to 1. This is obviously a big help, but it didn't really change your response times. There's still something unusual about how slow it is.
