I am trying to see tags inside an AOI.
I went back to basics and dragged and dropped the tags from the OPC browser into the Tags Folder, but the quality is bad and there is a red x next to them.
What is more confusing is that some are working and some are not. I cannot see any similarities between the few that aren’t working. Data type, In and Out types are working and not working.
I can create a new UDT as an In/Out but this seems cumbersome. In this case, I would need to create tags only for HMI display.
Tags are set to default, readin at 1 second intervals.
PLC is an L84ES.
Ignition running on localhost and currently plugged in to PLC bench testing.
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 externally visible/writable stuff in the InOut parameter datatypes. If you absolutely have to access a non-optimizable datatype (built-in FBD instructions, perhaps), create a mimic datatype with all-visible members and use CPS to copy over every scan. Do any writes to such with system.opc.write*() so there won't be any subscription to the non-optimizable data.
Edit 2021-07-12: It isn't locked hidden members, though any hidden member in the AOI would yield the same effect. AOIs present themselves in processor browse with proprietary flags on some elements, and Ignition's driver is (too aggressively?) honoring those flags.
Wow. Is this really the case? We’ve used custom and builtin AOI’s quite heavily on many systems. It makes development on both the PLC and HMI side much faster. Has this always been the case or is it something more recent? I haven’t really noticed any issues with older 7.9 systems, but 8.0 possibly is slower to read stuff?
We have several templates going to AOI’s and I had them working pretty well on 8.0.14, but was suggested by tech support to update to 8.0.16 and now they run super slow. Think it is mostly because of the tag() function within expressions tho? This seems to be a bug in 8.0.16 Vision. How much of that could be due to AOI’s?
AOIs being inefficient isn’t a matter of 7.9 vs 8.0, it’s firmware v21+ (…and 20.15+), when Rockwell deprecated the direct memory access and introduced the new services for reading tags. If you’re using the legacy driver accessing AOIs is fast, if you’re not it’s subject to the limitations @pturmel mentioned.
Any slowness you’re seeing in Vision templates between 8.0.x versions is unrelated to the driver and unrelated to your use of AOIs, though Phil will surely jump on the chance to talk about how you should never use the tag() function and always use indirect properties
Phil, currently I don’t use UDTs for my AOIs. One, how much more efficient are we talking comparing UDTs to internal AOI data types? I haven’t seen anything abnormal from past projects and have had some high tag counts. Two, what do you do for default values and read/write access if you use UDTs? Having default values has been why I haven’t jumped ship yet. I assume you either don’t use default vales or write code for first pass?
An order of magnitude slower. Or worse if you read many AOI booleans.
A tag created from a normal UDT with no inaccessible members can be read in its entirety in a single tag read request. Up to ~500 bytes normally, or ~4000 bytes with large connections. Same with arrays of such UDTs and/or nested UDTs. Any time you have an algorithm with mixed data types, a regular UDT provides a way to monitor every variable using a subscription that doesn’t have to waste resources by spanning gaps or issuing multiple requests. Have a dozen 40-byte UDTs in an array or as named elements of an outer UDT? With everything within subscribed? A single request gets the whole batch packed together. Do the same entirely with an AOI’s in, out, and local members? Separate requests for every item in every AIO. (Some can be wrapped up in a multiple-service request, but those requests will still contain all of the AIO member names and the responses will have the same overhead for each item.)
Also note that the requests that read large logix tags can still efficiently transfer tags that are larger than the available buffers by using continuation requests. As long as there are no forbidden elements, which means no AOIs allowed.
As to the rest: Regular UDTs do not have default values for members. But you can control external access for individual members. However, if you make anything forbidden (no external access at all), you have the same problem as the AOIs. If you don’t want it accessible, leave it in the AOI.
I just came across the topic. We also use AOIs everywhere, and we do have issues with slowness in some PLCs. This seems like something that should definitely be added into the user manual and also perhaps into the gateway as a warning when configuring a “new” Logix device. Those of us who aren’t also software devs doing work with modules, specifically with PLC drivers, and have an in-depth knowledge of AB comms simply won’t know this (such as me).
Do you know the reason rockwell changed from efficient to inefficient AOI comms?
I use first scan rungs where applicable. Habit, as older Logix versions didn't have default values either, and I try to create AOIs for the least common denominator.
Just to be crystal clear: I am a big fan of Add-on Instructions. I just work around this particular gotcha by moving "public" data into a separate UDT that is passed to the AOI as an in/out parameter.
Thanks to @pturmel recommendations I can confirm that the order of magnitude is correct when moving away from reading AOIs and only reading UDT’s.
What we do is have an AOI that has an In/Out Parameter that is the HMI only UDT. All other tags that are needed in the program outside of the AOI originate from the AOI that way we can differentiate between the two when looking at the code. It has changed the load factor and mean response on logix PLC’s in some respects to a 10th of what they were before. Also being smart with tag groups on the tags. See: CLX performance for information on that.
For default values @jlandwerlen, we have an init bit in the AOI that is default low and when that init bit is high that we set default values in the HMI UDT within the AOI and then set that init bit low.
Changing things over was easier than I though, even needing to write a little code for default values. But, losing the ability to change values from the AOI faceplate in Studio is a bummer. Not a huge deal to drill into the InOut tag, but it was nice seeing specific tags right there.
Curious what everyone does for naming when using AOI and UDT together. For example, before on a motor AOI I would name it M1000. Now I need an instance tag for the AOI and one for InOut UDT. In the past and currently I’m naming the InOut M1000 and the AOI M1000_AOI. Thoughts??
