# OPC communication with Rockwell PLC

**URL:** <https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612>\
**Category:** Ignition\
**Tags:** vision\
**Created:** [July 23, 2024, 4:23pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612 "2024-07-23T16:23:32Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mohammed\_Afzal](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@Mohammed\_Afzal](https://forum.inductiveautomation.com/u/Mohammed_Afzal)\
**Post date:** [July 23, 2024, 4:23pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/1 "2024-07-23T16:23:32Z")

</div>

Hey guys, I am stuck in an issue please help me out.  
I am using Rockwell CLX PLC and Ignition Vision for its HMI. Data through OPC. I am reading and writing data through OPC and added all the PLC tags in tag provider. The total tags would be around 25k. The HMI is very slow in updating values from the PLC, it takes around 10 seconds or sometimes more to update the values. Also, Ignition software is getting very slow. Do anyone know what's the issue? Or there is some tag limitation for OPC tag provider? Or any configuration setting?

---

<div class="post-metadata">

**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:** [July 23, 2024, 4:33pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/2 "2024-07-23T16:33:03Z")

</div>

> [@Mohammed\_Afzal](#):
>
> and added all the PLC tags in tag provider

This is a common mistake that overloads drivers. Only create Ignition tags for the OPC items (PLC tags) that you actually need.

If, after you prune down to actually used tags, you still have issues, you may need to restructure some data in your PLC to help external access. See this topic and the topics its links:

> [@Ignition & Logix Best Practice Tips for better communications](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386):
>
> Hi All, After a whole bunch of issues I have gone down the rabbit hole of what is wrong with our setup on site. I will preface this by saying I a relatively new to all of this.... so be gentle stuck_out_tongue Based on much reading(such wow) I believe I have a list of things our site could take away for a better system. Some of them are easy to implement, whilst some of them need... significant work to realize. Especially the AOI approach in point 5 expressionless Before going too far a…

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [July 23, 2024, 5:59pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/3 "2024-07-23T17:59:32Z")

</div>

Also, depending on structure, you may not need to read all the tags at the same rates, so create various scan groups for the various update rates you need.

Best way to check performance is by looking at your gateway web pages under Status -- Connections -- Devices and look at the details for your device. I always shoot for single-digit overloads. The smaller the better (strive for 0% overload ideally).

---

<div class="post-metadata">

**Author:** ![Mohammed\_Afzal](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@Mohammed\_Afzal](https://forum.inductiveautomation.com/u/Mohammed_Afzal)\
**Post date:** [July 24, 2024, 6:12am UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/4 "2024-07-24T06:12:30Z")

</div>

@pturmel @michael.flagler Thanks for Quick reply. Will implement these and check. Also, can you please tell is there any tag limitation on Ignition OPC Driver for Rockwell? Also, after I sorted out the tags and added only tags which to be used by Ignition, if I have some latency how to deduce this latency?

---

<div class="post-metadata">

**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:** [July 24, 2024, 12:02pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/5 "2024-07-24T12:02:17Z")

</div>

> [@Mohammed\_Afzal](#):
>
> any tag limitation

No limits.

> [@Mohammed\_Afzal](#):
>
> if I have some latency how to deduce this latency?

Starting by sharing a screenshot of your Ignition device's diagnostics page. And perhaps the PLC own (web) diagnostic that shows Class3 Msg utilization.

---

<div class="post-metadata">

**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:** [July 24, 2024, 12:33pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/6 "2024-07-24T12:33:09Z")

</div>

> [@michael.flagler](#):
>
> strive for 0% overload ideally

Not "ideally". It should _ **always** _ be zero. Any non-zero value means your PLC comms are swamped.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [July 24, 2024, 1:37pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/7 "2024-07-24T13:37:30Z")

</div>

What I mean by ideally is that the number will fluctuate especially right after a download. Things take a bit for that average to come down and I've noticed on mine that on a project I'm on now, I'm hitting over 40k tags on a single processor and see it go up to 1-2% frequently, but it's not enough lag that it causes any issues. On a 1000ms scan rate, 1020ms isn't a dealbreaker (at least in oil and gas where thing's dont move that fast on these big plants).

---

<div class="post-metadata">

**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:** [July 24, 2024, 1:50pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/8 "2024-07-24T13:50:17Z")

</div>

Fair enough. I suppose I should qualify the statement to "any _ **persistent** _ non-zero overload value".

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [July 24, 2024, 4:45pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/9 "2024-07-24T16:45:33Z")

</div>

One other recommendation I'll make is on the device configuration, be sure to leave the maximum concurrent requests at 2 (seems to be the sweet spot for me), but under advanced, change the connection size to 4000 bytes instead of the default of 500 bytes unless you're talking to an old processor through like an old ENBT card.

@pturmel also has a great driver that is much faster than the built-in driver, but that all depends on if this is Ignition Edge (custom modules like his can't be used on Edge). While it is an additional cost, if you're not able to change the structure of the PLC to get faster comms, his driver may help.

@pturmel I'd b curious about the 4000 byte connection size and how it relates to MTU size of ethernet considering this is larger than the default MTU of 1500 bytes. Do packets get fragmented, or do both ends automatically know to break up the request into multiple packets?

> [@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…

---

<div class="post-metadata">

**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:** [July 24, 2024, 4:53pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/10 "2024-07-24T16:53:56Z")

</div>

> [@michael.flagler](#):
>
> how it relates to MTU size

The OS on both ends fragments efficiently and streams based on the negotiated TCP window size (typically much larger). So, for devices that can do 4000, almost always a win.

Since the current EtherNet/IP spec requires errors for oversize to report what size **is** supported, I chose to default to 4k, and gracefully fall back, instead of requiring a deliberate change. Some older devices to not make that report, so I still have the adjustment available. (And some devices simply don't comply with the spec.)

---

<div class="post-metadata">

**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:** [July 24, 2024, 4:54pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/11 "2024-07-24T16:54:10Z")

</div>

> [@michael.flagler](#):
>
> be sure to leave the maximum concurrent requests at 2 (seems to be the sweet spot for me), but under advanced, change the connection size to 4000 bytes instead of the default of 500 bytes unless you're talking to an old processor through like an old ENBT card.

We've seen performance gains up to ~6-8 concurrent requests. I think it depends on your hardware, tag make up, existing comms load, etc... It's best to experiment.

---

<div class="post-metadata">

**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:** [July 24, 2024, 4:55pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/12 "2024-07-24T16:55:31Z")

</div>

> [@Kevin.Herron](#):
>
> best to experiment.

This. And if a high-latency network path is involved, expect to benefit from more concurrency.

---

<div class="post-metadata">

**Author:** ![Mohammed\_Afzal](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@Mohammed\_Afzal](https://forum.inductiveautomation.com/u/Mohammed_Afzal)\
**Post date:** [July 24, 2024, 5:18pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/13 "2024-07-24T17:18:49Z")

</div>

![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/1/712958ac67cb1b01920baf1619270821d0f0000e.png)

---

<div class="post-metadata">

**Author:** ![Mohammed\_Afzal](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@Mohammed\_Afzal](https://forum.inductiveautomation.com/u/Mohammed_Afzal)\
**Post date:** [July 24, 2024, 5:20pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/14 "2024-07-24T17:20:06Z")

</div>

![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/d/cd0fbb8d3b412281b12f9c14a5110f6d7450ac01.png)

---

<div class="post-metadata">

**Author:** ![Mohammed\_Afzal](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@Mohammed\_Afzal](https://forum.inductiveautomation.com/u/Mohammed_Afzal)\
**Post date:** [July 24, 2024, 5:21pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/15 "2024-07-24T17:21:51Z")

</div>

![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/0/0055ff8674c5f8692be4a6a5c1061f76eb095043.png)  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/d/bdae27dc90ea70f4ba4684141c32b8eb127ab171.png)

---

<div class="post-metadata">

**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:** [July 24, 2024, 5:29pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/16 "2024-07-24T17:29:51Z")

</div>

Whoa! So a 3.5-second scan target becomes a 20+ second actual polling pace. Prune your tag list first. Really. If that 100k+ item count is **after** pruning, you probably need to try my EtherNet/IP driver module in place of the IA driver.

---

<div class="post-metadata">

**Author:** ![Mohammed\_Afzal](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@Mohammed\_Afzal](https://forum.inductiveautomation.com/u/Mohammed_Afzal)\
**Post date:** [July 24, 2024, 5:37pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/17 "2024-07-24T17:37:18Z")

</div>

will explore EtherNet/IP driver module

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [July 24, 2024, 6:17pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/18 "2024-07-24T18:17:51Z")

</div>

Yeah, you can try bumping up the 500 byte connection size to 4000, but it's still not going to get to 0 with that many tags. Also, do you need them all at 3500ms? Are tags structured in UDTs or arrays? Is this using PlantPAx?

As an example, here's my most recent project (missing from the screenshot is my 30000ms scan rate for string data) which isn't using Phil's driver, but due to structure of tags, etc it performs well:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/8/68c28e6ebcc6d2a63fb42cdfcaa11f8c6cc5b2cf.png)

Although my ethernet comms of my processor is pushed to its limit:  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/8/7898777133a483af34a6f43424f7bcb23fecbf63.png)

---

<div class="post-metadata">

**Author:** ![Mohammed\_Afzal](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@Mohammed\_Afzal](https://forum.inductiveautomation.com/u/Mohammed_Afzal)\
**Post date:** [July 24, 2024, 6:42pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/19 "2024-07-24T18:42:19Z")

</div>

My tags are in UDT, addon instructions, and modified PlantPax library. I need it less than 500ms. I am using 1756-L74 PLC with redundancy.

---

<div class="post-metadata">

**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:** [July 24, 2024, 6:58pm UTC](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612/20 "2024-07-24T18:58:29Z")

</div>

> [@Mohammed\_Afzal](#):
>
> addon instructions, and modified PlantPax library

You need my driver.

> [@Mohammed\_Afzal](#):
>
> less than 500ms

Not going to happen for 100k monitored items. You need to prune. Split tags into separate tag groups for the ones you need fast versus slow. For really fast tags, you may need class1 comms instead of class3 (or both).

My module's user manual has a great deal of advice for this kind of problem.

[Next page](https://forum.inductiveautomation.com/t/opc-communication-with-rockwell-plc/93612.md?page=2)
