# Ignition & Logix Best Practice Tips for better communications **URL:** \ **Category:** Ignition\ **Tags:** rockwell\ **Created:** [June 5, 2022, 11:46pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386 "2022-06-05T23:46:38Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![A\_Power](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@A\_Power](https://forum.inductiveautomation.com/u/A_Power)\ **Post date:** [June 5, 2022, 11:46pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/1 "2022-06-05T23:46:38Z")
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 😛 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 😑 Before going too far and upsetting apple carts. I was hoping to get some oversight from the IA gods. specifically @pturmel and @Kevin.Herron - as it was some of your previous posts that have helped me form some of this picture. The last thing I want to do is find out I misunderstood something and led others astray I hope that my list (once confirmed as correct) is beneficial to others who may end up in a similar situation with "bad coms" specifically when running Allen Bradley gear as the majority on site. **What do I mean by bad coms** - High PLC MSG (Class 3) task loads - Overload situations on Ignition Device connections - General network instability **Levers to pull when it comes to bad comms** 1. Consider utilizing multiple Ignition Device Connections to 1 PLC when using a large number of tags 2. Increase the number of device CIP Connections (CAREFUL - do not go too high - Processor dependent!!!) 3. Increase Scan Mode Class Times in Ignition (OPC Polling rate) 4. Delete Continuous Task in the PLC - always go periodic 5. Do NOT read/write from an Allen Bradley AOI (Add on instruction) - instead use a separate UDT 6. Prime Number scan times - in the PLC (not ignition) I am happy to share my much longer winded document if these points are correct - but for now I just want to make sure I have things right. I appreciate any time anyone can give to this post. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [June 5, 2022, 11:53pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/2 "2022-06-05T23:53:14Z")
I think#5 will have the biggest impact. #4 won’t matter much if you are using L81, but I do agree in not using a continuous task. Edit, for #3 switch to lease if possible. ---
**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:** [June 6, 2022, 12:14am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/3 "2022-06-06T00:14:15Z")
#1 and #2 are functionally identical in the modern Logix driver. #3 is always helpful. #4 is usually helpful. If you do this, you do not need to mess with “Communications time slice” setting. Note, the latest L8x processors have a dedicated comms processor for their front ethernet port, mitigating the problem separately. #5 You can still read/write AOIs for light duty items, like leased tags for configuration UIs. #6 What? (Prime number poll rates is utterly useless in Ignition. I don’t understand where you’d apply it in the PLC itself.) Items to also consider: #7a: Never, ever, ever access aliases. Always directly read from the corresponding base tag. #7b: Consolidate scattered tag instances into arrays or nest them in structures. The fundamental unit of optimization when polling is the tag. Multiple items won’t be in consecutive memory locations, and therefore be retrievable together, unless they are part of the same tag. If you must, you can use aliases in the PLC to retain the prior logical structure, but access from Ignition via the consolidated tag(s). #8: Never poll across a WAN. Latency crushes polling protocols. Place your OPC/UA server local to the PLC and let OPC deliver updates across the WAN. (Or use MQTT to deliver across the WAN.) ---
**Author:** ![A\_Power](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@A\_Power](https://forum.inductiveautomation.com/u/A_Power)\ **Post date:** [June 6, 2022, 1:00am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/4 "2022-06-06T01:00:27Z")
**Thank you** so much for the prompt response. If I could unpack a couple of things (just to make sure I have this right) - #1 & #2 - are identical so for the Logix driver therefore #1 is moot - the max CIP is what it is. **Are there other drivers in which multiple connections are recommended?** - We are currently running an L82 Processor - and have had a heap of issues I was hoping the hail mary of the continuous task → periodic task will resolve some of this… but I am not liking my chances… at this point **Because if not I am led to conclude the site standard code and UDT’s need to be revisited?** 😐 Things have worked fine on site up until this last project - but this was the biggest to date at 7000+ tags which I am thinking was a bridge too far with some of the methodologies **Thank you** again so much for taking the time to review this and adding more points. Once the conversation dies down I will finalize the list to help others ---
**Author:** ![A\_Power](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@A\_Power](https://forum.inductiveautomation.com/u/A_Power)\ **Post date:** [June 6, 2022, 1:01am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/5 "2022-06-06T01:01:14Z")
Wanted to thank you as well for the very quick response- greatly appreciate the input ---
**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:** [June 6, 2022, 1:10am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/6 "2022-06-06T01:10:01Z")
> [@A\_Power](#): > > in which multiple connections are recommended I've had success with the legacy ControlLogix doing so. Was helpful with an Omron NJ processor more recently. > [@A\_Power](#): > > site standard code and UDTs If you are referring to the bombshell in this topic, then yes: > [@Cannot read some tags inside Rockwell AOI](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/3): > > What Mike said, but also: Don’t. All AOI’s have EnableIn and EnableOut booleans that are locked to “Hidden” and therefore prevent most optimization of the data traffic to read instances of these data types. Ignition’s Logix driver cannot do bulk reads on AOIs. Do very much of this and your Logix driver will choke. I strongly recommend that any AOI you design yourself use one or more InOut parameters of another data type, with instances of those datatypes elsewhere. Place all of your extern… If you are going to be changing things in the PLC, you might also consider switching your fastest tag group (or part of it) to "Class 1" Ethernet/IP. This module was created to deal with large numbers of tags at a 100ms pace: > [@Snappy user interfaces with the Ethernet/IP Module](https://forum.inductiveautomation.com/t/snappy-user-interfaces-with-the-ethernet-ip-module/12617): > > Automation Professionals [Ethernet/IP Class1 Communications Module](https://www.automation-pros.com/modulesales.html) has been in beta for a few months with no recent issues. A release to production use is approaching soon and I thought I’d share a test project and its matching PLC code I’ve been using to exercise the module’s base features. In the simplest setup, this driver presents a virtual I/O chassis to to the outside world, populated with up to 100 virtual I/O modules – I/O modules that also appear to be ControlLogix processors with user… { /Shameless plug. } ---
**Author:** ![A\_Power](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@A\_Power](https://forum.inductiveautomation.com/u/A_Power)\ **Post date:** [June 6, 2022, 1:25am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/7 "2022-06-06T01:25:19Z")
> [@pturmel](#): > > { /Shameless plug. } No shame at all - I didn't realize that was a thing 😛 **Thank you again again** for the valuable insight... guess I wll go break the news to my peeps. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [June 6, 2022, 1:26am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/8 "2022-06-06T01:26:24Z")
> [@A\_Power](#): > > - We are currently running an L82 Processor - and have had a heap of issues You would probably have even more issues with the older L7x. The L8s are not better because of a dedicated port but because of a dedicated processor that handles comms. There is no time slice in L8s to my knowledge. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [June 6, 2022, 1:34am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/9 "2022-06-06T01:34:52Z")
> [@jlandwerlen](#): > > There is no time slice in L8s to my knowledge. That is correct. ---
**Author:** ![A\_Power](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@A\_Power](https://forum.inductiveautomation.com/u/A_Power)\ **Post date:** [June 6, 2022, 1:36am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/10 "2022-06-06T01:36:20Z")
> [@jlandwerlen](#): > > You would probably have even more issues with the older L7x. Our next project is a L73! **Thank you again** ---
**Author:** ![michael2](https://avatars.discourse-cdn.com/v4/letter/m/3e96dc/32.png) [@michael2](https://forum.inductiveautomation.com/u/michael2)\ **Post date:** [June 6, 2022, 4:07am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/11 "2022-06-06T04:07:24Z")
> #7a: Never, ever, ever access aliases. Always directly read from the corresponding base tag. Oops. Why? ---
**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:** [June 6, 2022, 12:17pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/12 "2022-06-06T12:17:31Z")
Because they can’t be combined with anything else for an optimized read. To external readers, they look like a completely independent tag. Now, go review #7b. (There’s a reason those are #7a and #7b.) ---
**Author:** ![Cory.grube](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cory.grube/32/20476_2.png) [@Cory.grube](https://forum.inductiveautomation.com/u/Cory.grube)\ **Post date:** [June 6, 2022, 2:08pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/13 "2022-06-06T14:08:23Z")
> [@pturmel](#): > > #7b: Consolidate scattered tag instances into arrays or nest them in structures. The fundamental unit of optimization when polling is the tag. Multiple items won’t be in consecutive memory locations, and therefore be retrievable together, unless they are part of the same tag. If you must, you can use aliases in the PLC to retain the prior logical structure, but access from Ignition via the consolidated tag(s). Question in a similar vein - I do a lot of tag reads from UDTs. Currently I have the tag groups optimized by how often I need the data. E.g. Within one UDT, IO values might be 1 sec tag groups, configuration tags that shouldn't change might be 60 sec groups, etc. Does this cause a big performance hit? Might it be better to poll the whole UDT at a single fast rate (1 sec) vs this scattered approach? If I'm reading noncontiguous tags within my UDT, does it become a moot point? ---
**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:** [June 6, 2022, 5:44pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/14 "2022-06-06T17:44:45Z")
> [@Cory.grube](#): > > Does this cause a big performance hit? Yes, put them on the same pace. Then they'll be optimized together and likely read with a single message. If you follow the other links, you'll see I recommend separate UDTs for separate purposes/paces. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [June 6, 2022, 5:50pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/15 "2022-06-06T17:50:09Z")
> [@pturmel](#): > > If you follow the other links, you'll see I recommend separate UDTs for separate purposes/paces. Agree, speaking from experience, when we switched from AOIs to separate UDTs, the performance difference was huge. ---
**Author:** ![A\_Power](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@A\_Power](https://forum.inductiveautomation.com/u/A_Power)\ **Post date:** [September 28, 2022, 2:21am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/16 "2022-09-28T02:21:54Z")
So quick update for those of you playing from home. A colleague has just pointed out something I myself missed completely. Max Concurrent Requests (OPC Device Settings) - by default is 2. We just upped ours to 4 The problems we were having went away. Load went right down in ignition by 80%, and by about 30% on our PLC I see this has been mentioned before back in the day by @pturmel > [@Tag Scan Class](https://forum.inductiveautomation.com/t/tag-scan-class/11712/12): > > Increase the max concurrent requests. I suggest 8 or 10. (I think the max is 12, but don’t quote me on that.) The problem is that with only 2 requests at a time, and hundreds of requests needed per scan, round-trip travel and process time suddenly becomes significant. If it’s still not enough, you can create multiple drivers to the same processor to get more concurrency. Before I go screaming it's fixed and summarizing these findings, is there any healthy Convo to be had around this? What to do or what to check before you play with this number? Times when it is not a good idea and could have negative outcomes? But yeah I am buying someone a beer... You don't know until you know! ---
**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:** [September 28, 2022, 2:37am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/17 "2022-09-28T02:37:15Z")
On newer firmware/models you can view the comms load from the PLC’s perspective right on the webpage hosted by the device, on some others you have use the Logix5000 status monitor tool (I forget what it’s called). You can push concurrent requests up as long as the PLC isn’t indicating its comms load is 100%. Once it reaches 100%, or if it’s already there, there’s not much left to be gained. ---
**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:** [September 28, 2022, 12:34pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/18 "2022-09-28T12:34:30Z")
Having extra requests “in flight” is most valuable when there is network latency. ---
**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:** [January 3, 2023, 10:58pm UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/19 "2023-01-03T22:58:16Z")
Relief for those who don't want to break up their AOIs is now available: > [@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:** ![David.Reed.Schmidt](https://avatars.discourse-cdn.com/v4/letter/d/5f9b8f/32.png) [@David.Reed.Schmidt](https://forum.inductiveautomation.com/u/David.Reed.Schmidt)\ **Post date:** [May 3, 2023, 2:57am UTC](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/20 "2023-05-03T02:57:15Z")
Help me out here. As I understand Im supposed to program like this AOI-\>UDT in PLC-\>Ignition UDT-\>Ignition Vision Just making sure because typically the easy route is to have Ignition access the AOI tags directly. But this can slow things down on the PLC side. [Next page](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386.md?page=2)