Yes. However, we had several parameters we got accustomed to changing on the face of the AOI (when set to visible) when online with the PLC (instead of using the button on the AOI to show all parameters). With In/Out parameters, you need to either do away with that nice feature (of making parameters visible) or design your AOI to do conditional writes from either the in/out parameters or the AOI parameters (this was what we did in one iteration, but was pretty clunky). Aliasing makes it much cleaner.
So, more expensive than my driver for Ignition.
No, @tashby's recommendation retains the elements within the AOI type, but leverages the bulk readability of UDTs within an AOIs local tags. As noted, it doesn't make the entire AOI readable in bulk (like my driver does), but is much faster than individual member reads.
How many tags per driver can yours handle?
I agree it definitely makes it easier. I wonder what the memory impact is on the PLC, if any.
There's no fixed limit. It is entirely dependent on how fast you want to go, and how closely you follow the fundamental optimization advice in the user manual. If you cannot edit your AOIs to make them fully readable, then it runs just a bit faster than IA's native driver. It scales up from there to 15x faster or more. It tends to impose substantially lower class 3 comms load on the target when AOIs are involved.
In my lab testing (L81, L306), well-optimized targets with ~100k tags sustained 1000ms polling easily. One of my torture tests for the L81 is a PlantPax sample that is only partially optimized--it sustains ~300k tags at 5000ms.
If you have a sample you'd like tested in my lab, send it on.
I am honestly not sure how many tags we have per PLC for the rockwell OPC server. We are working on optimizing some of our AB/Ignition projects. I will probably include your module in our test scenerios, it does have the 2 hour trial yes?. I am really appreciative of the people on this forum coming together trying to solve problems. I have learned a lot just by reading some of your post lol.
Yes, all of my commercial modules honor the platform's two-hour trial mode. Consider reading my module's application notes for optimization, as much of it would apply to IA's driver, too.
1 Like
We talked about this today and I think the only downside I can come up with is memory useage on the PLC. On a large project it could definitely affect controller selection, especially if you are trying to work with PlantPAx AOI's, some stripped down version of them, or some other large AOI with a lot of tags going to the HMI. That aside, I dig it.
Yes. Tag count is a little bit of a downside to this method. But when I actually compared the memory increase doing this vs. before, it was a much smaller increase than I had anticipated, because we were only aliasing the tags we needed on the SCADA side of things, which wasn't close to what we originally had in place in the AOI. So for us, it was mostly negligible on pretty much every project.
Keep in mind, this for us was a way to work around the inefficiencies of AB's native AOI structure, but with an attempt to maintain much of the structure and debugging we've already put into our library of custom AOI's. We didn't want to touch any of the logic we've already proven, but instead just make it externally accessible in a more efficient manner, and this did it for us elegantly.
That is good to know, I guess I was thinking you were re-creating the AB process library objects faceplates in Ignition. Those are pretty tag heavy and it would be a lot of tags to Alias. But it sounds yours is a much smaller number of tags which is great.
1 Like