Something like I am discussing here?
My driver reads entire UDTs and/or AOIs when any two elements of that structure are read together (same subscription pace). Yes, this would be very non-optimal for instructions like P_PIDE. (Which is an abomination, IMNSHO.)
IA's driver does look at placement and gaps when optimizing a UDT.
Drivers don't see tag groups. Driver's see all OPC items that belong to them, and their pace. Only the pace differentiates how stuff is subscribed.
Phil, been a while since I was exploring these concepts and find myself a bit cloudy.
You are saying, to optimize AOI parameter communications utilizing your driver, but also maintain the ability modify code online/without download:
- In Logix Designer, create a controller level tag of the AOI type of interest, but make it an array of some length, with Read/Write external access Example: P_AIn_HMI_01[10]
Assumptions: If you want to avoid downloads into a running plant, you need to create an array of sufficient length to handle all your planned and future/spare modules while staying in memory limits. If you run out of spares, then you need to create another array. Alternatively, can resize the array offline and do a download, but that's going to cause some reorganization of the controller memory.
- In Logix Designer, create instances of your AOI, but declare them as Alias tags (as opposed to base) and point them at indexes of the array controller tag of like-type.
-
In Ignition Designer, create a UDT type that matches the Add-On-Defined Data Type for the AOI of interest. Create parameters for the UDT for substitution purposes that will allow dynamically building the OPC paths (i.e. parameters for "Controller Name", "TagName" and "TagIndex")
-
In Ignition Designer, create an instance of the Ignition UDT tag, name it the physical/P&ID tag, and pass it the necessary parameters.
-
Yes. Do spares in small batches, so any single array tag total size just fits in the link's connected buffer size.
-
Optional, but very helpful in the PLC code.
-
Maybe. Ignition UDTs do not have to match PLC UDTs at all. If using InOut AOI parameters to push parts of your workload into different poll rates, the Ignition UDT itself can still be unified. It reduces confusion to have most member names match, but don't forget that an Ignition UDT can have non-OPC tags that aren't in the PLC at all.
-
Again, Ignition tag names do not have to match PLC tag names. Only the OPC Item Paths have to match. Structure your tag folders and UDT instance names and folders of atomic tags to have naming patterns that make sense for UI window/template/page/view reuse, whether the PLC matches or not.
Some of #1 only matters if you are not using unfixable AOIs, where the structure is sealed with unreadable members, or built into the firmware with unreadable members. (A shocking amount of that in Rockwell's 5480 family.)
As always, thank you for comments!
1) Make sense
2) I'm not "mature" enough to want to do memory address style programming in the logic itself!
3a) Understood that the Ignition UDT doesn't have to match. Just as local variables of AOIs are not exposed in Logix Designer, I wouldn't want them to be exposed in Ignition either, even if the are required to be set to "Read" external access and show up while browsing tags.
3b) InOut AOI Parameters: Are you suggesting here that you could, rather than create an array containing the whole AOI, create multiple arrays at the controller level for what equates to different tag groups in Ignition? My AOI could have an InOut that was configuration pars, something like P_AIn_Config_Ary and then one for status/process value like P_AIn_Process_Ary? Then just piece it together in Ignition using some dynamic references? In that case, you wouldn't have to read the whole AOI, could encapsulate local variables, and even use function blocks or other garbage from RA that would normally poison the comms.
3c) I suppose all of this this comes down to really understanding how your driver works. I know it's optimize to read the entire AOI structure (or really, just an entire Logix UDT), so long as every member is "read." So does that mean if I set up a single bit from an AOI type as an an OPC tag within an Ignition UDT, the entire AOI structure gets read? However, it doesn't really matter because whether you are reading one bit, one Logix UDT/AOI, or one array of Logix UDT/AOIs as long as they fit into a single packet (the connection buffer size?) General strategy: a) reduce the number of communication transactions, and b) make sure the packets are full. If the above is reasonably accurate, then this also implies that putting varying tag groups on different members of an Ignition UDT is irrelevant; all tags that are packed into the same packet will end up getting read at the frequency of the fastest tag group? Thus your comment about implementing separate InOut parameters?
- This makes sense. For example, on the P_AIn AOI, it would probably makes sense to group everything associated with the "High Gate/Alarm" into a single directory in Ignition.
3b) Yes. That is what I recommended be done before I added the Client driver type to my EtherNet/IP module. See this old comment:
Many users reported huge performance gains with that approach, with the IA driver.
3c) My driver reads entire UDTs or AOIs when any two items are to be read at the same pace and the UDT fits in the buffer. IA's driver uses additional merging criteria. But yes, reduce request count, reduce request complexity, and aim for nearly-full buffers per request.
- Eh, no, that sounds like a nightmare for UI design. You should have UI components that only need a tag path string parameter to satisfy all of the indirect binding requirements within. And an Ignition tag hierarchy that meshes with that.
1 Like
Okay I think I've got my head around it now! Thank you very much for the guidance.
What do you do about controller redundancy using the IAI or AP drivers? You could set up each PLC as its own EIP server, but then you're bringing in 2x the tags and have to have some method of watchdogging / switch on failure.
That being said, do you know anyone that has gone the FactoryTalk Linx Gateway Pro route to solve this problem? Yes it's an additional (and very expensive) license, but it could be co-installed on the same server as the Ignition Gateway and then added as an Ignition OPC-DA/UA client. I know that this method would support redundancy and also be able to take advantage FTLive Data / Linx proprietary optimization.
I think v5 PlantPAx is coming out on Optix soon, or maybe already is... I have to assume that to use Optix you're going to need to use FT Linx Gateway Pro to accomplish this. Anyone have any insight here?
Haven't had to. That's a reasonable feature to pursue. Similar to how I did it in my Modbus driver, perhaps.
I've been told that this is not a significant boost for large amounts of AOI data. It seems to be a help for a few PlantPax faceplates at a time, not continuous reading of all your PlantPax objects of interest.
I won't touch the PlantPax5 objects that are built into the new controllers--they are permanently unoptimizable in the firmware. If you really care about communication performance, you will abandon (migrate away from) PlantPax.
You all have me convinced PlantPAx are garbage and Rockwell has done very little in firmware or software to improve their usability.
I am curious how Rockwell plans to use PlantPAx in the Optix platform they recently acquired. Clearly using standard EIP communications isn't going to do it, possibly could go the OPC-UA route... perhaps removing the CLX OPC-UA tag cap on the P-Series controller, base it on Gateway, or most likely develop their own propriety driver based on Linx for Optix.
They do that now?
2 Likes
Curious if you've seen Optix... it's just another poor offering from Rockwell IMO. I spent some time going through it and really tried to keep an open mind, but with every question/comment I had, Rockwell came back with their typical garbage response on why it does or doesn't do something.
Iâve only seen the brochure and got the talking points from my rep; no hands-on experience. Long way to go to catch up to Ignition then?
So, this will sound pessimisstic, but no way will Optix come close to Ignition.
1 Like
Well Rockwell has tremendous resources, unfortunately I think theyâve lost their taste for innovation and are now just in the business of buying other companiesâ half baked ideas and pretending to be a DCS. If they went back to the drawing board a bit with Logix Designer and PLC firmware, went with something similar to Emmerson CHARMs IO or ABB Select IO rather than this Flex 5000 HA garbage they just released, they might have chance. No way Iâm recommending PlantPAx for a DCS migration.
2 Likes
The only thing Optix is displacing right now is their own FactoryTalk View ME at best. Eventually I think their goal is for it to replace all of FactoryTalk View, but it has a long ways to go before it gets there. The one thing I see them still doing (unless I'm missing how it's done) is that you make a separate list of tags for logging/history and a separate list for alarms, rather than making it part of the UDT or whatever they call it. I sent them a page and a half list of questions after they came and gave us a sales pitch. Took them a week or 2 to get answers and many of my questions like "Can you make historical and alarm configurations inside the types for standardization" came back with a "yes" rather than how it's done, which makes me think they have no idea what I'm talking about and are just trying to say they can compete with Ignition. Their sales team really needs to research their competition some, and none of them had a clue what Ignition is capable of or had watched any videos on it. Their only information was that they're trying to compete with them and stop them from taking market share.
I'm doing a startup now, and their local AB/RA distributor was by to bring us some replacement parts. They saw the HMI running and asked if it was FTView SE. When I said no, it's Ignition, their only comment was "yeah, we're seeing that a lot". Then I jokingly said "no, it's actually Optix" and they just laughed and said yeah, it's nowhere close to Ignition yet.
6 Likes