My goal is to double or potentially triple the tag count on the PLC. However I need to maintain as close to a 1 second polling rate as possible or better.
For reference we had started to poll nearly 20,000 tags on the PLC and seen the Mean Queue Duration increase to 20 seconds.
I don’t need 20,000 but I do wonder how some claim this is possible with fast polling rates.
Is it possible to increase the overhead timeslice for this PLC program?
What kinds of tags are you accessing? Accessing tags from AOIs tends to perform particularly poor, as does standard UDTs when there are a mix of tags where some have External Access set None.
I could increase the Overhead Time Slice. It is currently at 20%. My continuous task has a max scan time of approx. 90ms.
As for the tags, I am not accessing any AOI tags. All tags have external access set to Read/Write.
Many of the tags are program scope with some UDTs used.
This implies that you have lots of individual tags? That would be bad. Optimization is at the tag level--multiple elements of an array or UDT read together in a single message. Separate tags need separate messages. (And aliases are treated as individual tags. Never use aliases for external access.)
Yes… many individual tags… I did not set the system up and have been contemplating starting all over.
When I say UDT I am referring to UDTs in the PLC.
From the make up of the tags, I don’t think I would be able to get around the individual tags on the PLC itself but I would be able to create a few UDT in ignition that could link to everything I use.
I am primarily looking at DINTs as a whole as well as individual Boolean tags.
Thanks, please help me understand this. If I poll a tag that is PLC_UDT.Tag1 and I poll a tag that is PLC_UDT.Tag3, they will both occur in one message form the OPC server to the PLC?
Also if I have tags within my program scope that are aliased to Controller Tags, I would be better off polling the Controller scoped tags (the base tags for the alias)?
This can help me optimize because we have some PLC tags that are mapped to tags used strictly for Ignition.
Let me elaborate on this, as the terminology is vague. PLC_UDT is a PLC tag. .Tag1 and .Tag3 are UDT members of that tag, not "tags" themselves. A PLC tag in the Logix world is the only entity, whether an array, a structure (UDT), or a primitive type, that has a contiguous block of memory with well-understood layout. Rockwell's published Data Access methods permit reading/writing arbitrary fragments of tags, and figuring out how to encode/decode the byte by byte contents.
I appreciate the detailed explanation. I’m more of a SCADA guy then PLC. So is there a way to poll the top level structure of a Allen Bradley UDT or I still have to have a SCADA Tag for each member?
Make Ignition tags for individual elements that you need. The driver will then optimize into as few messages as it can.
Let me elaborate some more:
For Ignition’s Logix driver, and for typical drivers, you address everything you need individually, and the driver optimizes from there.
For OPC/UA direct client connections to a PLC’s built-in server, or third-party OPC servers, making a single document-type connection to a top level tag may be required. But beware: it creates an object that must be read and written in its entirety every time. Which creates a race condition cluster-[expletive] of epic proportions. You don’t want that.
Because they can’t be optimized. Requests for the elements of the base tag will be combined efficiently. Requests for aliased elements remain separate.
After I began restructuring my Ignition tags to point to the Base tag instead of the Alias I saw an immediate improvement in the system overload. I have not even removed the Alias tags from the system yet, I simply created 2 sets of UDTs to work with the Base Tags and linked about 2/3s of the tags.
I have not adjusted the PLCs System Overhead Time Slice.
Important Note. Our Studio5000 platform had been running painstakingly slow for quite sometime. We checked into all suggestions from the Rockwell Knowledge base. Then we tried disabling Ignition for a test. When Ignition was disabled Studio5000 ran extremely fast.
So I found a happy medium with the Ignition Control Logix driver set to 2 concurrent sessions and 2000 CIP objects. We also increased the overhead time slice of the PLC to 25%.
Unfortunately this means I wont be able to optimize my tag polling rate much faster than 1,000 ms.
I did however manage to make improvements to the Overload factor using the suggestions here.
We now have an another production line at this plant. On this new line we are using the same type of PLC with the same ethernet cards and using Ignition as well.
Ignition is running on 1 computer for both lines. The PLC program is nearly identical and the tag counts on Ignition are about the same. The Logix Driver configuration for Line1 has 2 Concurrent Sessions and 2000 CIP objects. The driver config for Line2 has all default values. Line1 still has the issue stated above with an overload at or above 100%. Line2 is showing 0% overload.
What could be a reason I am seeing such a dramatic difference?
Very fair question. The busy PLC (Line1) does have a Kepware MES system polling it. The new PLC (Line2) Kepware is not working yet. It will be interesting to see the impact after it is up and running.
