Guardlogix PLC and Ignition Tag Count/Polling Rate

I am having trouble finding good information about this subject.

Ignition Version: 8.1.6

Guard Logix PLC: 1756-L73S GuardLogix 5570 Controller.
Ethernet Card: 1756-EN2T

6.63 MB of 8.38 MB Data and Logic Memory used.

Currently I have 1322 OPC Tags (all from the PLC).
Tag group is Direct, Subscribed and a Rate of 1200 ms.

Device Configuration is: Allen-Bradley Logix Driver Version 6.1.6
Max Concurrent Sessions: 4
CIP connection size: 4000

In my device details I am seeing:

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.

This won't improve driver performance if they are still individual tags in the PLC.

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.

Yes, generally, unless they are far apart (byte offset) from each other.

Yes. Always poll base tags. Never poll aliases from outside the processor. Ideally, make large tags (arrays and/or PLC UDTs) and poll those.

1 Like

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.

1 Like

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.

1 Like

Can you elaborate on why this should never be done?
Thanks!

Because they can’t be optimized. Requests for the elements of the base tag will be combined efficiently. Requests for aliased elements remain separate.

Update:

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.

1 Like

Update:

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.

Update:

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?

Is something else also communicating with the busy PLC? Look in the PLC’s own web pages for utilization statistics as the PLC sees them.

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.

Can you connect Ignition to that Kepware system instead, to reduce possible duplicate polling?

1 Like

Do you mean run Ignition on the same server as Kepware?