Automation Professionals' EtherNet/IP Communication Suite V2

My driver's user manual §3.3 has very specific application notes for best performance and compatibility with the NJ/NX family. While Omron modeled their EtherNet/IP support for compatibility with Logix PLC to PLC messaging, they did not implement everything found in Logix, and did some things differently.

The most important two things I recommend:

  • Keep all UDTs' total size within ~1800 bytes, to fit the family's maximum CIP buffer size. Omron didn't implement Logix-style continuations, so cannot bulk read any UDT that is larger.

  • Put all Booleans into UDTs and include at least one non-boolean member in such UDTs. (And include the non-boolean in the tag group with the booleans.) This dramatically improves the optimization of boolean subscriptions. (Do not use simple booleans or arrays of booleans outside UDTs. Horrible performance.)

1 Like

Hi,

Thank you very much for your recommendations — I’m already working on optimizing the structures in my PLC project. I assume you are referring to UDTs defined in the PLC; please correct me if I’m wrong.

In my case, I have structures that include other structures and arrays of structures, and the total size of some structures can reach up to 4 MB (which is the maximum for the NX102).

Could you please clarify if the ~1800 bytes limitation applies to all structures, or specifically to individual UDTs being read? If I keep the lower-level (nested) structures within ~1800 bytes, would that help improve performance?

Also, I’ve seen posts on this forum mentioning load factor measurements. Could you please advise how to measure this? I would like to evaluate how the performance changes after optimizing my data structures.

Thank you again for your support!

Yes, that will suffice. Minor hit for the extra path segment in the request, but probably not noticeable.

There is a great deal of ambiguity (and bugs) in the various flavors of load measurement. This is what I recommend:

1 Like

I’ve performed the test you suggested, and so far the results are quite disappointing — the update rate is around 13 seconds.

Do you think that optimizing the data structures (e.g., reducing UDT sizes and reorganizing them according to your recommendations) could realistically bring this down to around 1 second?

Thanks again for your guidance!

What did you do? Drag all of the tags from the OPC browser to the Ignition tag browser? That will never be performant, unless the PLC is trivial. (My driver very deliberately includes data types with folder names, partly to discourage users from doing that.)

Segregrate the PLC content that is needed in Ignition from the PLC content that is purely internal (separate tags and UDTs). That is key to keeping the subscribed item count reasonable.

(Show us a screenshot of your device diagnostics page....)

Thank you very much for your advice — I really appreciate your guidance, which has already helped me achieve a much more acceptable update rate.

I did not import everything from the OPC browser. Instead, I created, in Ignition, a kind of “copy” of only the UDTs I actually need from the PLC, keeping only the tags that I plan to use. I also removed some tags that can be calculated on the Ignition side. At this point, I have about 78K+ subscribed tags.

The update time for the test tag is now no more than ~1.5 seconds. I believe there is still room for further improvement.

I hope the screenshot I provided is what you were looking for. Apologies if I misunderstood — I’m just getting started with Ignition and still exploring how best to work with it.

Thanks again — your help is truly invaluable.

Try bumping up the concurrency setting.

Thank you for your advice.

I’ve already tried increasing the concurrency setting. Setting it to 2 reduced the update time of the test tag by about 20% — from around 1.5 s down to approximately 1.2 s. Further increasing the concurrency didn’t have any noticeable effect on the update rate, so I decided to keep it at 2.

Ok. You might be at the performance limit for the item count.

The device diagnostics that show the histogram of response times would be a helpful screenshot.

I assume you would like to see something like the image below. However, for some reason, these histograms are not available in my web interface. I would actually like to find them myself — when I wrote my first message here, that is exactly what I was trying to locate.

The user manual for version 8.1 describes the diagnostic page functionality, but I cannot find these features in the web interface of version 8.3, despite trying. The PDF manual for the current version is unfortunately not available, and I was also unable to find a description of the diagnostic page features in the online documentation.

I think that later on I will implement something similar myself in Vision.

As requested, I will provide any information available to me. Your help is greatly appreciated.

Ah, you didn't make clear you were using v8.3. That piece is missing from my 8.3 driver. (IA refactored that interface.)

I really found this page to be useful and was quite disappointed to see it removed from 8.3.

I hope IA brings it back to someday.

Not IA's fault for my drivers. They moved things around, as often happens in new major versions, and I missed that. Complicated by its absence in 8.3.0. It is on my to-do list.

3 Likes