Yes, They are AOI’s. specifically the AB default P_Motor/P_VSD/. I made UDT’s in Ignition and only brought in the tags I needed the operators to use/see. I basically re-made the P-Motor faceplate in Ignition. It was a pain. We are migrating from standalone Panelviews running FactoryTalk ME. Why are AOI’s worse for the Load Factor?
AOIs can't be read efficiently because even if you have made every normal tag inside it externally accessible there are still EnableIn and EnableOut tags locked to "hidden". So the driver has to read all tags belonging to an AOI individually rather than as a whole structure.
More discussion of this phenomenon over here:
3 Likes
Thanks Phil I was looking for that post and quoting it from memory.
When you say bumping concurrency, what is that? I am going to assume class 3 comms are also sent to PanelViews? We have lots of those… Which I am also assuming that this class 3 comms is all of my class 3 comms including those going to other ENBT cards etc…from this PLC??
I searched for AOI plus myself… (:
It's another setting on the driver along with the CIP connection size. It controls the number of CIP connections the driver makes and thus the number of concurrent requests the driver will issue to the PLC.
Yes, the utilization you're seeing is from all the things talking to the PLC.
It may not make sense to increase concurrency and/or connection size if your PLC is already near full comms usage.
For anybody else following along… I just want to say that our Load Factor calculation is garbage and starts to fall apart under anything but the most basic scenario (e.g. tags subscribed @ 1000ms and no other rate groups).
We’re working on a replacement for it right now that should give you a better indication how each sampling group is performing or not performing vs. its ideal.
edit: the overhauled load factor calculation and diagnostics OPC tags are present starting in 8.1.7.
10 Likes
Thank you for the help and clarification. I am looking forward to an updated Load Factor calculation. I will try and work something out with the AOI with the 3 UDT’s like Phil suggested in the other topic. I have been wanting a reason to get rid of the P_Motor/P_VSD AOI anyway and writing my own that doesn’t have an obscene number of tags for functions we don’t use… maybe today is the day.
1 Like
Lets not be dramatic. I've got a large project w/40,000+ tags and ~ 60-70% of those are from Ignition UDTs pointing 1:1 with the AOI instances and performance is perfectly acceptable. The only fancy sauce involved is packing the PLC AOI tags into an array.
Yes, let's. The system you describe must have relatively slow scan classes/tag group paces or you are using the built-in port of an L8x. Your comms performance would improve by a factor of ten or more if you separated the public parts of the AOIs as described in the linked post. Your application may be able to tolerate the difference but most applications cannot. Especially on older processors.
Putting AOIs into arrays does not mitigate the hidden member restrictions.
1 Like
Yea. I am in total agreement. I removed maybe 15 AOI UDT’s (about 120 tags in each) out of ignition that I pulled in for areas I haven’t started development on and my MSG Class 3 utilization dropped 8%. I really wish I knew this was going to be an issue on the front end. I am not even 1/3 of the way through this process. I spent a lot of time making that P_Motor faceplate. I hope someone sees this and catches it on the front end of their development. I’m sure most SI’s know about it, but its going to costs me a decent amount of time and effort to fix this.
EDIT:
I am a bit of a dummy. I had all of my tags in the default 1 second tag group. I leased all of my configuration and control tags for my UDT’s and everything dropped super low, less than 40% on my Class 3 connections. I still plan on creating new AOI’s though.
We fought everything trying to be stubborn and use AOIs. It wasn’t until I did some serious testing and reading across multiple scada systems and in depth study and testing with Ignition that we changed to a udt and aoi system. 95% of our base tags are now in udts. One one specific system that has 150k tags plus we went from 90-103% load factor down to 10%. That was enough for me to know that AOIs are going to give you a bad time. Do AOIs work? Yep. But it is a shakey foundation to build a large system on, in my opinion.
4 Likes
My PLC guy hates the idea of using UDTs with AOIs as you then can’t easily glance a look at the values going into the block. What about using FactoryTalk Linx as the OPC server to read these in? I read somewhere that because it’s all Rockwell, it’s still super efficient when reading with their software. I haven’t looked up the cost of Linx yet though I imagine it’s around the AUD $5K mark
I don’t know of RSLinx is faster with AOIs in particular but it’s worth a try. They are faster in general because they use an undocumented/proprietary method for reading tags instead of the method outlined in 1756-PM020.
If you’re going to spend, I’d recommend my Class1 driver. If the processor CPS’s the AOI into a I/O buffer, the hidden/locked bits go along for the ride. And you get blistering speed as a side benefit.
2 Likes
I'm not a plc guy, but will this affect my scada tag addresses?
Yes it would. Generally when I do this, I arrange for the data to land in my module’s emulation in matching tag names & structures, so the OPC item path is identical except for the device name. Note that transmitting tags this way effective yields a read-only value in my module, so you’d use the standard driver with OPC writes to go the other way.
1 Like
Not disputing that inefficiencies exist, and that I could spend a bunch of time refactoring AOIs to better optimize. However a "Factor of ten" does not necessarily equate to 10x noticeable improvement user experience. Would I be better off refactoring for the sake of Ignition? Or investigating an alternate OPC comm driver?
meh, It's the inability to make online-changes that deter me more than anything, that's for AOI's in general.
Approximately 3400 AUD (2,600 USD) from the last quote I had. For the Professional version.
1 Like