I’d maybe check other providers outside of what you think should be used in case one accidentally got added to a different tag group or provider. Could search for the device name under all providers in the designer maybe? hard to say where it might be hiding unfortunately.
This is sounding all too familiar for me and how I ended up with a crap renamed tag provider, as I simply couldn’t find the cause of some tags polling slower than they should at 5000ms Instead of 1000ms after moving it from a test environment after some big changes (merged 3 gateways ino 1). Creating a new tag provider and copying all tags fixed it. I couldn’t set it back to the same name. This was in 8.1.5 though
Well. That’s not too comforting, but might at least be some validation that I’m not totally crazy. @grietveld’s suggestion was still helpful for me so I can at least get those of the default scan class under the same one and get rid of at least 1 of the 3 polling cycles.
If it all works after that, I don’t want to go too crazy searching for the one tag. I did check all the other providers in my gateway and didn’t see any tags point to that device. So good on that front at least.
Check transaction groups with direct OPC items.
So I don’t have anything in transaction groups going to that PLC. But your comment reminded me that I do have some SQL queries going on that write back to the PLC that are event driven. Not exactly sure if those are what are showing up as that 1000ms request rate or not. You’ll have to excuse all the crazy things going on in this project. Requests from this client are beyond anything I’ve been asked to do before, so it’s a bit of a mess.
Psssst!
Wow. For real?? We just recently got done overhauling all of our AOI's to work around this. Ooof. I think we may still wait for it to pass the beta stage, but may be interesting to bench test in a non-production system. Thanks for passing along the info nonetheless. It is still good news.
All testing is welcome. 
The beta will end when neither I nor the peanut gallery finds any (more) show-stoppers.
Just a little better than the Logix driver for reading AOI tags directly...!
(Enip is Phil's driver)
Note Phil's uses load factor, logix uses overload where load factor approx = overload + 100
2 Likes
I wouldn't mind if you reposted the original graphics of those on the announcement post... 
1 Like
Will do, just to confirm though, do you mean that screenshot exactly? (the "original" graphics threw me)
They are still present in the alpha topic. I can repost them if you don't mind.
1 Like
Sure, feel free to post them!
(edit: ah I see what you meant now)
This is just for CIP connections though right. Not OPC connections? Or is Ignitions native OPC server a CIP request that gets mapped into OPC? Sorry if this is a dumb question. I am just trying to understand this.
This thread veered off into specifics about accessing data in Logix processors via CIP connections, though most of our polling-based drivers will have the same kind of generic diagnostics about request load.
The data acquisition "system diagram" in Ignition most commonly looks like this:
Ignition OPC UA client <--> Ignition OPC UA server <--> PLC (via native protocol, implemented by driver modules)
Sometimes like this:
Ignition OPC UA client <--> 3rd Party OPC UA server (e.g. Kepware) <--> PLC (via native protocol)
and starting to become more common:
Ignition OPC UA client <--> PLC with embedded OPC UA server
The diagnostics discussed in this thread are provided by Ignition's driver modules and only relevant when they are being used.
2 Likes
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