With Rockwell now including PlantPAx instructions as part of the native instruction set in their L8xP series controllers, there is no longer any ability to modify the instruction itself to optimize communications or modify read/write access to parameters.
What is the current best practice, if any, going forward with PlantPAx and Ignition? Stay at version 4? Embed the v5 instruction in an Add-On-Instruction wrapper and optimize tags for communications? Are there any companies out there selling/licensing functioning PlantPAx solutions for Ignition? Looking for in-production testimony of anybody running a 1500 to 2500 I/O facility with this setup.
I think we can all agree FactoryTalk View is way behind the times and Ignition is much better product, but if you can't utilize the PlantPAx instructions out of the box, then there is a A LOT of development to be done to make an analogous AOI library and corresponding Ignition library. Somebody out there has to have gone down this road before me.
This kind of precludes the ability to practically use PlantPAX with Ignition (and other non-RA SCADAs) in my view... especially if you want to bring in all of the tags from the AOIs, your tag updates will just grind to a halt reading even a handful of AOIs, unless you're happy with ~10s update rates. Although from the grapevine, I understand that FTView doesn't even do well with PlatPAX and is slow and laggy as there are just far too many tags. Or maybe that's just hearsay
I would not use the built-in PlantPax instructions. At all.
They are permanently constructed with no-access members, and therefore can never be optimized for efficient external access.
(There are placeholders for these datatypes in all 5580 and 5380 processors, so I've already had the opportunity to analyze these. And discuss the issue in my manual's application notes.)
The alternate method that FTLinx uses to assemble data blocks has limited buffer space, so won't help significantly on large applications.
PlantPAx v5.0 and newer [P8xP with built-in instructions] is NOT an option for Ignition due to the inability to modify the members/parameters for external access.
PlantPAx v4.X and earlier [as Add-On-Instructions] is an option, but the base library objects will need to be modified to optimize communications.
To use the native IA driver, all members of an AOI need to be set to read/write and optimally packaged into UDTs to allow IA's driver to read the entire UDT as single request. [Edit: you cannot use the native driver to read the Add-On-Defined data type of an AOI, but you can read a User-Defined type that is local tag of the AOI. To read the entire AOI structure, a much more optimized option is to use Phil's / Automation Professional's 3rd party Ignition EtherNet/IP driver, which allows mixing of external access type in the UDT, but must be set to at least "read."
It's probably best pare down v4.0 Add-On-Instructions to the bare minimum information required by the HMI, or develop my own Process Objects library with this in mind. The best way to optimize communication is to simply not have them to begin with.
All that being said, is it possible to create a practical PlantPAx-like solution for CLX where scan times are 1s or less? I don't know enough about EIP/CIP to know the difference, but I was able to do this kind of thing on AutomationDirect Productivity via KepWare ADC Productivity driver, but I set up my IAI UDTs such that only Process Values were polled at "fast" frequency, and Configuration values were only read/written on demand. That might have been successful just because of the way Kepware's Modbus/ADC Productivity driver works.
The native IA driver will not optimize multiple AOI members, except for local UDT instance members in an AOI that are externally readable (and parameters that are aliases into such local UDT instances).
My alternate driver will optimize AOIs as a whole if the entire AOI structure is readable.
Automation Direct Productivity has a totally different protocol and UDT internal architecture. Not comparable.
So are you saying if I have a UDT tag that I just call for example HMIData that's local inside an AOI, that it will perform the same as if I made a separate tag outside the AOI and passed it in via InOut parameter? (With external access set to R/W on both) If so, that would simplify my structure in my PLC, but I swear at one time I tried this and it performed worse, but it's very possible I messed up my testing also.
If the external tag was a singleton (not an array of UDTs), then yes, it should perform similarly. But an array of such UDTs connected as InOut params will be much faster than an AOI local.
So, when using an array to UDTs, that memory becomes highly optimized because it will be contiguous memory addresses and the whole thing is read in a single request?
Seems like this might hearken back to non-tag based programming days where I need to know "which analog input is at what index in my array." Wouldn't this defeat the ability easily late-bind / dynamically bind base on P&ID tag name? You would have to dynamically bind based on array index, and then have some kind of reference sheet to keep it documented?
The potential issue I see here is being able to change the array length without doing a download. It's pretty routine to make modifications to a large processing plant, and they cannot tolerate a shutdown to do it. In a packaged unit / OEM situation this is probably tolerable, but it's probably a deal breaker for site wide production system. I suppose you could pre-define a set number of arrays of each UDT, but then you might be reading a whole bunch of array element AOIs that are empty/spares. What's the best practice here?
My concern: FactoryTalk SE is not great and sounds like it struggles with its own creator's PlantPAx objects. However, nobody ever got fired for recommending Rockwell. If we home-grow something, there is a lot more liability for our company. If we go that route, the standards put in place have to meet operational and maintainability requirements. Just seems like the work-arounds are adding up!
We build our own AOIs and avoid PlantPAx if possible. Technically, a certified PlantPAx system REQUIRES you use unmodified AOI blocks and FTView SE/ME blocks provided by Rockwell. Rockwell will supposedly guarantee performance of the system, but I believe if you want to go that route, you have to send them all the design specs of servers, etc., and possibly even use their pre-build VM images. (I sat in on a meeting once going over all the requirements, but since I don't deal with it, I didn't take notes, but remember thinking it was a lot of hoops to jump through for Rockwell to give it their stamp of approval). There's nothing stopping you from building it out per their spec and not getting it certified. Also, keep in mind that since there's not much optimization to how their blocks are built, you could do the recommendations others have posted (especially what @pturmel has recommended), but also, Rockwell doesn't read all tags all the time, so even if you use @pturmel's driver and are still having performance issues, he can help, but you may need to look into how your scan groups are configured (direct vs leased) to try to reduce comms load on the PLC if you're getting overloaded.
So, you can use alias tags in your PLC to point at UDT instances in the array, and have your AOI InOut params point at that alias. That lets you shuffle stuff around however you need in the PLC to avoid downtime.
Just make sure Ignition itself isn't pointing at aliases.
Is there something you can do on the Ignition side to alias back to a P&ID tag? Perhaps create a Reference Tag that is pointed to the Client Tag at a specific UDT Array index? Kinda making mux/demux to optimize comms but maintain the tag-based approach on both ends?
Note that there is absolutely no reason why a UDT has to match what is in the PLC. UDTs in the PLC should be optimized for use in the PLC, UDTs in the HMI should be optimized for the use in the HMI.
Members of an AOI: these are the Parameters and Local Tags configured on the Add-On-Instruction itself, which results in the creation of a Data Type -> Add-On-Defined type. This type of datatype IS NOT optimized by the native IA driver and will be read/written as individual components. @pturmel's 3rd party driver can read this entire structure, but External Access must be set to at least "Read." "None" (which is the default value) will not work.
Follow up question: When use Automation Professionals driver, I believe this inherently means that all members of the AOI are read regardless of whether you want them to or not. This might be very suitable for smaller AOIs, but be problematic with with a PlantPAx instruction like P_PIDE that has >350 members and has a size >3650 bytes.
Local UDT instance members in an AOI that are externally readable: These would be variables that are UDTs that are listed as members of the AOI. The native IAI driver will read something like Sensor1.Status where Sensor1 is the instance of the AOI, and Status is a UDT of basic/atomic types that is a Usage Local and External Access "Read" or "Read/Write."
*Follow up question(s): This approach allows you to control which parameters via alias of an AOI are communicated to Ignition. Can you make several of these UDTs for each AOI that have different scan/polling characteristics. For example: .Status and .Command as a Direct Tags at 1s intervals, .Config as a Leased Tag where the default rate is some very long interval, but leased rate is 1s? Does the native IAI driver honor these tag groups? Does Automation Professional's 3rd party driver honor these tag groups? What happens if you nest these UDTs into a single UDT called "HMI" consisting of UDT Status, UDT Command, and UDT Config? Is these even possible with either driver and do Tag Groups still function? What happens if you make these UDTs into In/Out parameters such that you might pack/unpack them into arrays of UDTs to optimize comms as Phil has suggested?
I think the issue here is that UDTs have to optimized for comms when dealing with very large AOIs and UDTs. Under no circumstances do you want to force the IAI driver or AP 3rd party driver into polling individual UDT elements.
That being said, I like the idea of making an HMI Interaction Parameter in the PLC that is 100% congruent with the Ignition UDT, and then is mapped selectively inside of an AOI or through a parameter such that you do not read unnecessary local variables or configuration parameters that really should be reserved for CLX programmers. In PlantPAx specifically, there is a lot of stuff that does not need to be exposed.
This is my point, if done correctly you can have groups that are set up for different read rates which can further optimize your comms, even if using IA’s native driver.
