That explains why I cannot pass parameters from the AOI to an Ignition UDT. Thank you all for the critical information!
if you use the legacy driver
I think the analogue device AOI was like 600 tags last time I looked a few years ago. Ridiculous. I think it would be far better to create the non-configuration tags in the Ignition UDT, and read the other 590 config tags via opc reads and writes in dev-only screens. Operators certainly couldn't care less, nor even want to see most of the stuff displayed in those PAX popups to do with configuration
I totally agree. I was not impressed with it when my coworker was showing it to me. His excitement was not contagious.
When I showed him Ignition 7.5x (at the same plant) it was like I popped his balloon. I explained to him that it was a REAL old version of Ignition and the modern ones are a lot better. What can I say? 
4 Likes
I wouldn't be surprised if there's an internal directive within Rockwell forbidding the firmware engineers optimizing the memory usage of these objects, in order to push clients into more expensive CPU models. The bloat is so extreme that there's simply no engineering excuse. 
5 Likes
I've started on the Perspective version of this same thing. I agree there is a lot of bloat in these tag structures and I do worry about how my project will scale. I've thought about putting things like string tags into a slower poll group. If anyone is interested in helping or just wants to check this out:
https://www.youtube.com/watch?v=22jKPR5ky4w
https://github.com/ASolchen/LitPax
When the string tags are in the same data structure as the rest (as is typical with PlantPax), the possible gain is limited. (May help with the IA driver when the strings are embedded in AOIs, as IA's driver is going to read those piecemeal anyways.)
Remember that optimization means reading structures/arrays in blocks, reducing PLC workload for each little piece of data. The shorter strings that PlantPax uses aren't really a problem, as such, if you can read big blocks. (In an AOI, it would only help with my alternate driver.)
I don't understand why you'd have the strings in the PLC at all. The strings are used for HMI display and don't have any role in the PLC.
It's a PlantPax thing. Its AOIs have numerous embedded strings.
Let me say it a different way, if the strings are only bring used to display on the HMI, then instead of ignition reading these strings from PLC, change to memory. I understand why FactoryTrash uses PLC strings, but we are discussing ignition.
3 Likes
Yes, we are discussing Ignition, but in the context of how to interface with the PAX instructions in the PLC. You could ignore the strings, but my goal of this is to be able to rid an unfortunate customer of View SE that happens to use the PAX object with as little pain as possible. This means it should have close to the same functionality. This includes having the labels and descriptions in the PLC that show up on the HMI. We could talk all day about if PAX is terrible, or not, but I have several customers that use it and I would love to offer them Ignition as an option.
Then use the existing Exchange resource full of Vision implementations of various faceplates. Vision is going to be much closer, behaviorally, to View SE than Perspective. And you save much development effort over a from-scratch Perspective effort.
Then, use my alternate driver to avoid AOI miseries. Do whatever you can to modify the PlantPax AOIs to be entirely readable (that means avoiding the ones built into the firmware).
I've even embedded basic strings in my AOIs as well. I know it seems silly, and normally I wouldn't do it, but as an integrator while I want to push everyone to using Ignition, some customers have specs to use FTView, etc, and since most things are direct tagged in FTView to the PLC without HMI tags, so you practically have to use PLC tags for these unless you want to go through the pain of doing it in the HMI tags which just gets messy having tags in 2 places without proper structuring. The same goes for Wonderware System Platform. They have a great structure with templates, but if any attribute (tag) values are updated at runtime that aren't connected to I/O, if those objects are ever undeployed without uploading runtime values to the galaxy, those values are lost.
1 Like
I guess I didn't explain myself, I'm not saying don't have strings in the PLC, I use AOIs that are based on PlantPax, they have similar strings for description, tag, label, EU, etc, etc. What I am saying is if I use these AOIs with Ignition I don't read those strings, I make the strings memory tags in Ignition. If I use those AOIs for FT, then I use the PLC strings. It seems silly to me to read PLC strings when using Ignition if those strings are only used for display purposes.
It isn't silly if the PLC uses them for other purposes (external comms of some kind) and the PLC programmer is responsible for them.
1 Like
Maybe you missed the part where I said for display purposes only?
As @pturmel said, if they're used elsewhere, or just for consistency between systems. So that someone doesn't get in the PLC and say....all the EUs and descriptions are blank how are tags being read to discover that they're just memory tags. I have all my strings in my blocks in a single UDT that is on a very slow leased poll since they rarely change, and usually if they do, it's being done from the HMI, so the tag update will be instantly seen anyway.
Michael beat me to it. I was going to say that a piece of data that lives in two places, and is expected to match, need to be synchronized somehow.
Fair enough point(s). To me it's a lot easier to populate the strings when I create the Ignition tags vs PLC tags. Importing tags into Logix doesn't include values, so you are reliant on an import file like L5X, which is possible just more cumbersome IMO. I might also delete the PLC strings when using the AOIs with Ignition, just to save some memory, then there's no confusion.
It's not that big of deal on memory when dealing with a description or label, but when using AOIs like interlocks, where you have a lot more strings, you can eat into memory quickly.
Just my opinion, not trying to change minds. You haven't changed mine. 
Pssst! Import into my alternate driver's "Host" driver type.... You get structure and values without having the live PLC.