Last Christmas, I was thinking summer '22. This summer I was thinking "by ICC". Last week I was thinking "a couple more weeks". The corner cases are kicking my [expletive].
Alpha release, that is. Wanna be a guinea pig test subject?
Edit: Hmmm. Maybe @jlandwerlen too?
Haha, well it's Summer '22 on the horizon for me now, so you might still be in luck 
oink! 
yes please!
If you plan on using Rockwell Logix UDT's, how do you plan on creating them at scale for every single component?
Also, do you plan on using the COP/MOV command or are you doing something different?
It seems that if I have a device with 20 tags, I will need 20 commands. This starts to add up quickly and so does the potential for errors.
If I'm not mistaken, it seems that there is a significant amount of manual entries and ladder rungs needed just to copy 1 AOI tag over to another tag. It seems that every field has to be linked. If an AOI has 50 interesting tags, I have to have 50 copy or equivalent commands for every single transmitter as well as future maintenance if a new field is needed for each transmitter.
I'm guessing the last option is to just purchase FactoryTalk Linx Gateway Professional and be done with it. Sometimes I wonder if there are Ignition folks on this forum using the FactoryTalk Linx Gateway but don't want to admit it . . . .
I think you've gotten into the weeds, mixing different possible work-arounds.
My generally-recommended work-around is to modify the AOI so the bulk of its data is managed in one or more InOut parameters of suitable UDTs types. Arrays of those UDTs can be accessed efficiently from Ignition, where each AOI instance points at a different subscript. No use of COP or CPS at all.
Where you cannot modify the AOI but absolutely have to have fast access, I recommend using my Class1 Ethernet/IP module with I/O buffers. You CPS the AOI data into the I/O buffer (not a UDT) in your ladder, one complete AOI type per CPS, or if you made arrays of the AOI, possibly multiple AOIs in a single CPS. On the Ignition side (in my module), point the receiving assembly # at a (module internal) tag that has the same byte-for-byte arrangement and member names as the AOI (or multple AOIs). Then your Ignition OPC tags can point at the AOI data in the class1 driver.
IA doens't do enough for you and all you do lol.
They should at least put you on payroll or name a version after you. 
Ignition: The Phil Edition
Ignition: Phil.1.15
Oy! Crazy face is right.
Or at least a function after him:
system.dataset.philtur
Perfect, really; you get the "Phil" AND the "Tur"! Can't work in the "mel" though, sorry
The data type size of the P_Ain is 1856 bytes so I don't think I can easily copy that to the Ethernet Module as-is (?). Even with the Ethernet bridge, it would require splitting the P_AIn somehow and requires an offline change.
However, I just looked and the PlantPax AOI's are editable so maybe I can go through and add the InOut parameter like you have suggested. Not sure what happens when/if Rockwell releases an update to the AOI's but I'll cross that road later. Since they are pushing their Process controllers, I'm not sure what will become of the existing AOIs anyway.
I know others are using the PlantPax AOI's but I don't think I have read anyone editing them yet and adding in the InOut usage type.
Maybe this thread will be helpful to you,
It should highlight a specific user that experienced problems with a large project using native PlantPax AOIs.
Most of the PlantPax users that I know don't use the raw PlantPax instructions... they are WAY too bloated. For example, I used PlantPax as a base but then stripped out all of the unnecessary RA garbage and spun the code the way I wanted. I am biased, but I think the code turned out better.
If you are worried about keeping the instructions intact so they are easy to maintain for if/when RA releases updates, then just use them as-is, but if your project is large you will need a beast of a system to keep up.
I don't think you have a warm/fuzzy on how things should really work. I say that because you mentioned the size of P_AIn. Who cares how big it is? You would never copy the entire thing over as you don't need to. Ignition doesn't care, nor need access to a lot of the AOI members.
I recommend that you spend some time planning things. Perhaps looks at the Flintium stuff for inspiration, or just use them as they are. I don't think they ever finished though so you would probably need to finish them.
Thank you for your response. I was attempting to use the instructions as-is to avoid maintaining a custom set of instructions.
The primary goal is to go from the PLC (1756-L85E) to Ignition without unnecessary copy instructions and to not modify the AB AOI's.
I have been using P_Ain as an example. In Ignition, I only bring over a few tags from the P_Ain but due to limitations in Ignition, the request is not optimized and still requires reading the entire P_Ain AOI block which doesn't scale well for the Ignition driver.
Phil has recommended that when you are not able to modify the AOI instruction, one could use the Automation Pros EthernetIP Class 1 Communications Module and then the AOI could be copied to the buffer and then into Ignition. It's a good idea but I found out that the datatype of the AOI is 1856 bytes which is greater than the messaging limit of 500 bytes (if I understand that correctly). It's possible I misinterpreted how the size is used. If the messaging will need to be split up, I'm back to adding in complexity.
However, I really didn't realize the PlantPax AOI's could be modified (didn't try since we kept them intact for upgrade purposes) but that might be the easiest approach. If I add the InOut like Phil suggested, then I should be able to keep the speed up with lower load and we'll stop addressing the AOIs from Ignition. We would use the standard Ignition driver in this case unless we had a special case. If I really wanted I could combine the InOut with Automation Pros EthernetIP Class 1 Communications (or in select cases to increase speed).
If I really didn't want to modify anything, then I could probably purchase FactoryTalk Linx Gateway Professional which is about $700 per year after a one time purchase of $3500. But like most people, I'm trying to avoid purchasing another piece of software unless I absolutely have to.
I know editing the PlantPAX 4.0 and under AOIs is possible as we have done this, but with PlantPAX 5.0 controllers those are included as process instructions and can't be modified. Has anyone done testing with the new 5.0 library? Would it produce the same "AOI" reading issue?
Not quite, due to the "limitation" the driver will read each tag individually subscribed from the Ignition side, not the entire AOI block. Ignition doesn't read the entire P_AIn AOI unless you are actually using the entire AOI.
If you have 20 tags subscribed in Ignition, the driver is basically forced to read each of those 20 tags individually. If you use UDTs it can handle all of those in one block.
If you read earlier in this thread you will notice how you can break up the UDTs. Then you simply update the AOI to use that UDT instance. When I did this, it only took a few minutes to make the changes. The trick is how to handle default values and perhaps if you want to use Out parameters.
Once you get to AOIs like the P_Intlk, you will see just how stupid PlantPax is. ALL of the strings are stored in the PLC. That is a complete waste for the HMI to read these strings from the PLC when they are only used in the HMI.
Ok. I didn't think we were bringing over many tags from an AOI (maybe 10-20) so I wouldn't have thought this would cause things to choke. I'm under the impression from these forums that it's more complicated than this but my technical know-how on this is limited.
Yes, my plan is to use a UDT and modify the PlantPax AOI as an InOut. I have resolved myself to modify the PlantPax AOI's.
If you only have 20 tags per AOI and the project size is relatively small you might be OK. Just know that it doesn't scale very well, so if you get comfortable and get hit with a huge project you will not like the performance.
Play around with Flinitium, it should give you a good basis for experimentation without needing to do much development.
@pturmel any significant updates on your magical module that will make all of our problems go away? (no pressure or anything 
)
