Ignition & Logix Best Practice Tips for better communications

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

    • The dedicated port you speak of is going into a managed switch and straight to our ignition server
    • Time slice settings do not exist in this project (unless they hid them real well)
    • We have a EN4TR ethernet bridge module out to all field Devices (which is spec’d for the number of devices plus a comfortable margin)
    • Pretty much everything in the PLC a continuous task(s)
    • We have 99% MSG 3 load on the PLC CPU
    • We have a 102% overload on the Ignition Device
    • Disabling the device in ignition drops the PLC CPU load to 3%
    • We currently use a significant amount of AOI Read writing
      • (140+ AOI Blocks x 100 Tags per block )
    • We have had a ton of communication faults (specifically with some AB E300 Overloads)

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? :neutral_face:

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

Wanted to thank you as well for the very quick response- greatly appreciate the input

I’ve had success with the legacy ControlLogix doing so. Was helpful with an Omron NJ processor more recently.

If you are referring to the bombshell in this topic, then yes:

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:

{ /Shameless plug. }

1 Like

No shame at all - I didn’t realize that was a thing :stuck_out_tongue:

Thank you again again for the valuable insight… guess I wll go break the news to my peeps.

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.

1 Like

That is correct.

1 Like

Our next project is a L73!

Thank you again

#7a: Never, ever, ever access aliases. Always directly read from the corresponding base tag.

Oops. Why?

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.)

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?

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.

2 Likes

Agree, speaking from experience, when we switched from AOIs to separate UDTs, the performance difference was huge.

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

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!

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.

2 Likes

Having extra requests “in flight” is most valuable when there is network latency.

Relief for those who don't want to break up their AOIs is now available:

3 Likes

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.

If you must use AOIs and not just UDTs, yes.

There’s been a few different strategies discussed around here for isolating the tags needed by Ignition and getting them into a separate UDT. The most recent I can remember was in this post.

@pturmel might have something to say about a particular magic driver he has to get around these issues

It is linked in that topic. Just read the whole topic.