v20.55 works with the old driver? That’s interesting… what model even has a firmware 20.55 available?
1756-L75 ControlLogix 5575 Controller
Revision 20.55
Maybe the firmware ranges I mentioned only apply to CompactLogix then. Not sure what the story is for your model.
Maybe. It’s also worth noting that this driver was “just there” when Ignition was upgraded from 7.7.2 to 7.9.9 and I haven’t tried adding the controller again using the old driver. It also doesn’t work well with the old driver which is why I was trying to test the newer one in the first place.
It seems like the Redundant variants are the ones with these .5x firmware releases… explains why I haven’t seen it at least.
I think at this point (since I’m already nearly done changing OPC addresses in all of the tags) it’s best to at least finish and try the performance with the new driver. If it doesn’t help I can always import my backup of the old tag structure and switch back.
Like I mentioned before, with an increased CIP size I was seeing promising early results with this.
Just going to provide an update on this one…
I’m using a 1756-L85E v31.11.
We were pushing our PLC MSG utilization to 85-100% (put PLC IP addr into web browser, see “Tasks” tab) with ~22k tags (reported by the Ignition Gateway/Status/Devices page).
Scan class for majority of tags was set to Direct @ 1100ms.
Ignition device connections are all set to 4 concurrent requests, 4000 CIP connection size.
We have 4 device connections to the same PLC, but majority of load comes from 2 connections with aprox ~11k tags each.
I’ve heard of these PLC’s being able to service up to 30k tags no problem. Does anyone have any tips on what they are doing to achieve this?
I’m going to spend some time today trying to play with different scan classes and Device settings.
Have you seen this discussion about AOI issues?
Probably ought to review the discussions that also link to that post.
Hi Phil, thanks no i hadn’t, but i’ve read quite a lot on the topic now, from that post and a few other related ones.
One thing i did notice straight away, is that the EnableIn and Out booleans in the AOI’s are currently set to ReadOnly External Access in my project.
You mentioned that they were forced to Hidden in older posts, is this something that is changed potentially?
Could be. I’ll play with Studio 5000 to see where that became possible. Or maybe it’s only possible for AOIs you create yourself.
Hmmm. Everything back to v16 where AOIs were introduced show those booleans as External_ReadOnly. The part that seems locked to hidden is the AOI’s Local tags. You can toggle display of the external access column for those, which then shows “ReadWrite”, but they aren’t.
I need to confirm this in my lab tomorrow. I may have misidentified the culprit.
Hi Phil, thanks for looking into it. We are using an AOI local tag that we can read from Ignition, and we have been doing so for quite a while.
Interested to hear what you find out.
Well, that was interesting. It isn’t an issue with external access. Or rather, setting every member of the AOI to read or read/write is necessary for bulk reads, but the Logix driver won’t do bulk reads on AOIs anyways. ):
I’ve passed my findings on to @Kevin.Herron for future driver improvements.
Yes, to clear things up, our driver will not attempt to read Module-defined, Predefined, or AOI structures as a whole, at the recommendation of the Logix 5000 Controllers Data Access guide (1756-pm020).
IMPORTANT
The information described in this manual about accessing and understanding structures should not be used to access complete Module-Defined structures, Predefined structures, Add-On-Defined structures, or system tags, whether they are stand alone, an alias, or nested within another user created tag. Tags of these types have rules for dealing with host members and mapping of BOOLS, which are beyond the scope of this document. If such structures are manipulated or accessed, results can be unpredictable.
Phil has shared some of his findings about how BOOLs are mapped in AOIs and PDTs and in the future I'll probably look into this to see if there are any other risks or rule changes involved in trying to read AOIs or PDTs, but I can't really put any timeline on it.
Thanks guys for the updates.
In terms of my own update, we’ve managed to get some stability from the PLC with the following changes:
- set our Direct scan classes to 2500ms.
- move a few UDT members from default fast Direct scan class to a slower direct scan class that didn’t need to be polled as often.
Note 1: Adding additional device connections didn’t seem to help much (we already have multiple).
Note 2: Increasing CIP connection size > 4000 broke the connection.
Current stats:
Device Connection 1:
11k tags. Direct @ 2500ms. Request count 87, Mean response 17ms, Load Factor 15%.
Device Connection 2:
11k tags. Direct @ 2500ms. Request count 180, Mean response 5ms, Load Factor 9%.
EDIT: Don’t use any leased scan classes in this particular example.
Do you really see much difference between 2 devices with 4 logical CIP connections each vs 1 device with 8 connections?
Usually we only recommend separate device connections where you put all your leased stuff on one and direct on the other so the relatively frequent re-optimization of the leased tags doesn’t affect the direct tags.
I noticed a big difference when using the Omron driver for an NJ job, splitting 1 device connection into two. Can’t recall how many CIP connections were on the device connections at the time.
I remember Cody saying they had better success with everything on Direct, but i think the part where we split Direct and Leased into different device connections may have been lost in translation somewhere.
I’ll try have another go with that in mind.
To clarify, we don't actually have ANY leased scan classes in this particular project. I've updated my comment above to read:
- move a few UDT members from default fast Direct scan class to a slower direct scan class that didn’t need to be polled as often.
Instead of:
- move a few UDT members from Direct to Leased scan classes that didn’t need to be polled regularly.