Ignition & Logix Best Practice Tips for better communications

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.

Hi, which is the best way to group data inside PLC to get maximum performance, where I can read about how Ignition/Rockwell is required to be data grouped for best connection performance? I am using udt structure only with different data types inside udt. I trying to create some guidance for my organization of how to do data grouping, but cannot find any proper document of how Ignition or Rockwell doing transfer optimization. I not really like to create arrays of REALs to send analog data to the ignition, because in this case is really a mess to work with this PLC code. Best case for me is grouping data into udt like udt_Valve, udt_VFD, udt_Motor etc, and each udt has all requried data for specific unit. But how to group those udts to have max performance it's is a question for me. (Example program has 200 valves, 100 VFDs and 50 Motors). The best approach be to group them into arrays (VFD[100], Valve[200], Motor[50])? or there any better solutions present?

1 Like

UDTs are very good for performance. Arrays of UDTs are especially good. With some constraints. I recommend you read the topics linked above, because they have a great deal of information about how this stuff works. The best summary is probably this one:

Most importantly, for any given base tag in the controller (a controller tag, or a program tag, at the top level), use only one subscription pace. Optimization can only occur for OPC items that are part of the same tag, and at the same pace.

Things that are less important to your operation, and can operate at slower paces, should be in a completely separate tag hierarchy, preferably another array of UDTs.

If you must use AOI tags, and cannot do any InOut parameters nor tweak AOI locals into a nested UDT, you probably want to use my alternate driver.

2 Likes

Question about udt:
If udt has 5 tags:

  • Tag 1 (dint)
  • Tag 2 (dint) (not used in ignition)
  • Tag 3 (real) (not used in ignition)
  • Tag 4 (real)
  • Tag 5 (bit)

Tag 2 and 3 are not required in Ignition, how data be called from PLC in this case?
Should i group tags into udt specifically for ignition or there any difference if udt has some tags which is not for HMI?

1 Like