# Omron FINS TCP Communication Overload **URL:** \ **Category:** Ignition\ **Created:** [May 17, 2024, 9:51am UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554 "2024-05-17T09:51:12Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 9:51am UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/1 "2024-05-17T09:51:12Z")
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 ![Imagem1](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/4/948dcf56cbe844e34e4de7d18f2e3a97582110ba.jpeg) 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? ---
**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:** [May 17, 2024, 11:44am UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/2 "2024-05-17T11:44:12Z")
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. ---
**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:** [May 17, 2024, 12:09pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/3 "2024-05-17T12:09:56Z")
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. ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 12:19pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/4 "2024-05-17T12:19:00Z")
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: ![IMG](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/3/d3e005e490d77d2e49f10e16498c565896f164e6.png) In case the values are still not readable: AGGREGATE STATS: Request Count - 27 Throughput (Mean) - 7,73/sec "" (1min) - 7.65/sec Mean Response Time - 257.85ms SAMPLED AT 100ms: Request Count - 4 Throughput (Mean) - 1.8/sec "" (1min) - 1.7/sec Mean Response Time - 259.69ms Mean Queue Duration - 1927.85ms Actual Sampling Interval - 2027.85ms SAMPLED AT 2000ms: Request Count - 23 Throughput (Mean) - 5.94/sec "" (1min) - 5.94/sec Mean Response Time - 257.29ms Mean Queue Duration - 1880.52ms Actual Sampling Interval - 3880.52ms Answering to your guess, yes my tag addresses are spreadout in the PLC, but it's not an option to organizing them. What other choices do I have? ---
**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:** [May 17, 2024, 12:23pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/5 "2024-05-17T12:23:42Z")
If your four requests in the 100ms pace average 259ms each, then your hoped for 100ms polling is simply not possible. > [@Rodrigo\_Domingues](#): > > not an option to organizing them I think you need to make it an option. The items you need to sample together should be packed into contiguous register blocks so the IA driver can read them with a single request. Also look at any settings on the PLC side that affect comms workload. (I'm not a Mitsu guy, so others will have to make suggestions.) Also, if Ignition isn't physically on the same LAN as the PLC, fix that too. ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 12:36pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/6 "2024-05-17T12:36:25Z")
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? ---
**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:** [May 17, 2024, 12:42pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/7 "2024-05-17T12:42:48Z")
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... ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 12:44pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/8 "2024-05-17T12:44:50Z")
PLC program cycle is 3ms ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 1:06pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/9 "2024-05-17T13:06:41Z")
> [@pturmel](#): > > I think you need to make it an option. > The items you need to sample together should be packed into contiguous register blocks so the IA driver can read them with a single request. 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. > [@pturmel](#): > > Also look at any settings on the PLC side that affect comms workload. (I'm not a Mitsu guy, so others will have to make suggestions.) 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". > [@pturmel](#): > > Also, if Ignition isn't physically on the same LAN as the PLC, fix that too. 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? ---
**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:** [May 17, 2024, 1:12pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/10 "2024-05-17T13:12:30Z")
> [@Rodrigo\_Domingues](#): > > I have strong beliefs it's not possible 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. > [@Rodrigo\_Domingues](#): > > increasing the value of "Concurrent Requests" I'd do it. Up to the point where it doesn't help any more. ---
**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:** [May 17, 2024, 1:23pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/11 "2024-05-17T13:23:46Z")
> [@Rodrigo\_Domingues](#): > > 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? Usually the downside is more load on the PLC, and you can only increase it if there is available overhead. That you're able to increase it suggests to me this is still a network latency problem... your response times are 10x what they should be. ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 1:27pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/12 "2024-05-17T13:27:38Z")
> [@pturmel](#): > > 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'll see what I can do about it. Thanks > [@pturmel](#): > > I'd do it. Up to the point where it doesn't help any more. I maxed it out to 8 then. It helped significantly ![IM2](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/8/0881e9435a49e7c86f32b829edacbeacefa7026d.png) ---
**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:** [May 17, 2024, 1:29pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/13 "2024-05-17T13:29:04Z")
What model is this? If NJ or NX, you might try my EtherNet/IP driver for named tag access: > [@Automation Professionals' EtherNet/IP Communication Suite V2](https://forum.inductiveautomation.com/t/automation-professionals-ethernet-ip-communication-suite-v2/68190): > > Automation Professionals is pleased to announce its latest EtherNet/IP Communications Suite driver module, a major upgrade to its EtherNet/IP Class1 Communications module, as a Public Beta. As of April 15, 2023, this is now a Production Release. The primary new feature is its new Generic EtherNet/IP Client Driver, a drop-in replacement for IA's Logix V21+ driver and its Omron NJ/NX driver. It does work with older Logix processors, and also works with Rockwell's MicroLogix 8xx family (ethernet… ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 1:33pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/14 "2024-05-17T13:33:35Z")
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 > [@Kevin.Herron](#): > > That you're able to increase it suggests to me this is still a network latency problem... your response times are 10x what they should be. 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. ---
**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:** [May 17, 2024, 1:34pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/15 "2024-05-17T13:34:31Z")
🤷‍♂️ ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 1:34pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/16 "2024-05-17T13:34:40Z")
It's an Omron CJ2M ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 1:35pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/17 "2024-05-17T13:35:43Z")
🥲 ---
**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:** [May 17, 2024, 1:36pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/18 "2024-05-17T13:36:32Z")
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.) ---
**Author:** ![Rodrigo\_Domingues](https://avatars.discourse-cdn.com/v4/letter/r/cdc98d/32.png) [@Rodrigo\_Domingues](https://forum.inductiveautomation.com/u/Rodrigo_Domingues)\ **Post date:** [May 17, 2024, 3:15pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/20 "2024-05-17T15:15:19Z")
> [@pturmel](#): > > 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. 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: ![ScateredTags](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/2/b2ebc736cb296f94c15fc3daf89c1e572c5fbbfe.png) Behavior of the same amount of tags when in a contiguous register block: ![ContiguousRegistBlockTags](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/b/3be71b4b874a7e32ff252b43432d73fb47c1d2d8.png) Once again sorry for not testing it out as soon as told and thank you for the help! ---
**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:** [May 17, 2024, 3:32pm UTC](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554/21 "2024-05-17T15:32:24Z")
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. [Next page](https://forum.inductiveautomation.com/t/omron-fins-tcp-communication-overload/90554.md?page=2)