This is making more sense to me now. So for instance even in the second instance "Ignition OPC UA client <--> Ignition OPC UA server <--> PLC (via native protocol, implemented by driver modules)"
where I would be using say Factory Talks OPC server, It would still have somewhat the same CIP limitations mention in 1756-pm020 regarding AOI/UDT. It may just perform a little better. I guess my question is still around device load factor just trying to really understand the core issue so I can explain it to others when I am asked.
Well, no, not in that example. If you use Rockwell's OPC server they have undocumented proprietary access methods that we don't have.
1756-pm020 documents the scraps they make available to the public.
1 Like
Wonderful. Ok. When using their OPC server the diagnostics are no longer relevant like you said above right? Is there anything else that won't work well within Ignition with a third party OPC such as tag groups mode/rate?
No that should all work more or less the same with any OPC server.
1 Like
I have word from multiple sources that the undocumented methods only get you so far--big PLC projects will still have horrible performance when hitting "ExternalAccess=None" anywhere in UDTs or AOIs.
2 Likes
This was my concern. I am actually planning on doing some testing on this within the next month or so. I will bring results here if I find anything.
Just wanted to revisit here and share something new I've found in regards to this that so far seems to be proving a nice clean work around. It took us a little while to get to this point (after trying some other painful and partial workarounds), so hopefully it will save someone else a bunch of tears.
There's a little hidden property you can set in the Local tags of an AOI (right click on any column in the Local Tags tab to show the hidden External Access column). You can actually make them externally accessible. Why do we care you might say? Well because I can't set a custom data type as a parameter in the AOI. I CAN however set a custom data type as a local tag and then Alias that tag back to the parameters. Doing that, and then referencing the Local DT in your Ignition UDT gets you the best of both worlds. We had a considerable library built around the access the AOI structure and having those same tags accessible on the face of the AOI and not wanting to create a bunch of extra in/out tags to make access work (those were some of the pains we went through).
Here's some screen shots to give you an idea of the setup. To test it out, I just did one instance of each of our 17 AOI's and set a bench test to a PLC on a local network with a scan class set to 10 ms (so that we could put some strain on the comms to see the difference with a smaller population of tags). The difference is quite remarkable.
11 Likes
Very nice.
You should recommend this to Rockwell for all of their PlantPax instructions...
I haven't dealt with their PlantPax a lot, but the little I have, I thought they essentially did this (just using In/Out tags) already. Do their templates reference the direct structure? I also wonder, where it's developed by them, if they have their own under the hood hack around it.
I would hope they would have an idea how to work around their own pitfalls and not rely on some random integrator to "fix" their flaws LOL.
Not the ones shared with me.
Oh boy. I guess we've been fortunate to not have it required to be used on many of our projects. At least not any I've been involved in.
Hello again,
Hope you are well
I have two quick questions for you on this topic.
-
I thought that accessing aliases was not recommended (one of our earlier discussions) - how does tashbys solution (which looks good) work with respect to that advice?
-
With regards to your fancy (and exciting) driver - would I be correct in assuming that to replace an existing Logix driver (with several thousand tags) I have to export all my tags and do find and replace to edit the path/structure and then reimport them so that they point at the new driver correctly, or is it simpler than that?
Thank you.
- Not exactly sure. With my driver, if the AOI itself is not completely readable, but the local tags within it that are structures are completely readable, aliases into those structures will be optimized together to read the those inner structures efficiently. Not sure what IA's driver is doing with those, but it seems to do this (or @tashby wouldn't get the performance boost). tashby's solution does not permit arrays of AOI structures to be optimized into large reads in IA's driver.
My driver originally had bugs handling aliases inside AOIs. That was fixed before formal release. Alias tags are still not optimized by my driver, though I do hope to do so eventually.
- If you are replacing the IA Logix v21+ driver with mine, the addressing is compatible. I recommend the following:
- Edit the IA driver device to disable it.
- Wait for all subscription paces to "notice" the disabled device. (~2x the slowest pace seems to suffice. In early testing I thought a server or OPC module restart was needed.)
- Delete or rename the IA driver device.
- Create an instance of my new driver with the IA driver's original name. OPC tags pointing at that name will notice rather quickly.
If you are replacing an IA legacy ControlLogix or CompactLogix driver with mine, you would need to perform the same search and replace operations as you would after a firmware upgrade to v21+. My driver uses v21+ Item Path syntax for all firmware versions.
2 Likes
ooooooh that is even easier than i thought it would be!
very exciting.
Now I just need to convince the counters of the beans to bum me the cash!
Still having issues with an L83 Processor - Ignition is at about 30% load but the PLC is red-lining on comms for MSG3 - I have a feeling this will get us out of a bind in the shortest possible way.
Has anyone (you perhaps?) who has been testing monitored the PLC performance when testing for a before and after?
Yes, did quite a bit of that. PLC Class 3 comms goes way down with my driver if you make all of your AOIs completely readable. I did the bulk of my very-high-load testing with an L81 and an L320.
The client driver application notes chapter in my user manual has very detailed instructions, by the way.
1 Like
This feels like Christmas
If you can tolerate some minutes of downtime to implement the driver swap, and then later reverse it, you can get hard data for your bosses using Ignition's 2-hour trial mode. All of my non-free modules honor the trial system.
(You'll likely need some PLC downtime too, to load the new file after the L5X search-and-replace operations. That doesn't need to be undone afterwards.)
We ended up going this route, the performance is pretty decent from the PLCs to the tag servers. There are a couple million tags in the system. There is an added costs though. Somewhere in the neighborhood of 1500 bucks per OPC server needed.
They arent built with In/Out parameters for external data access like Ignition. Their OPC server has a work around. If you scroll up a bit on the post there is some discussion around it.
Is @tashby's fix similar/same to changing up the AOI to just group all of the tags you need to access in Ignition into an in/out paramter UDT?