# Guardlogix PLC and Ignition Tag Count/Polling Rate

**URL:** <https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842>\
**Category:** Ignition\
**Created:** [April 25, 2022, 10:55pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842 "2022-04-25T22:55:39Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [April 25, 2022, 10:55pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/1 "2022-04-25T22:55:39Z")

</div>

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:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/d/fd7dfd53b872913560d9bb19cff580b76bbc8858.png)

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.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [April 25, 2022, 11:01pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/2 "2022-04-25T23:01:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [April 25, 2022, 11:17pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/3 "2022-04-25T23:17:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 25, 2022, 11:23pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/4 "2022-04-25T23:23:26Z")

</div>

> [@Aaron\_Shivne](#):
>
> 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.)

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [April 25, 2022, 11:33pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/5 "2022-04-25T23:33:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [April 26, 2022, 12:51am UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/6 "2022-04-26T00:51:33Z")

</div>

> [@Aaron\_Shivne](#):
>
> but I would be able to create a few UDT in ignition that could link to everything I use.

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

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [April 26, 2022, 1:05am UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/7 "2022-04-26T01:05:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 26, 2022, 1:19am UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/8 "2022-04-26T01:19:11Z")

</div>

> [@Aaron\_Shivne](#):
>
> they will both occur in one message form the OPC server to the PLC?

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

> [@Aaron\_Shivne](#):
>
> I would be better off polling the Controller scoped tags (the base tags for the alias)

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

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 26, 2022, 1:45am UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/9 "2022-04-26T01:45:05Z")

</div>

> [@Aaron\_Shivne](#):
>
> If I poll a tag that is PLC\_UDT.Tag1 and I poll a tag that is PLC\_UDT.Tag3

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](https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm020_-en-p.pdf) methods permit reading/writing arbitrary fragments of tags, and figuring out how to encode/decode the byte by byte contents.

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [April 26, 2022, 2:11am UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/10 "2022-04-26T02:11:58Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 26, 2022, 11:52am UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/11 "2022-04-26T11:52:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![adonnell](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@adonnell](https://forum.inductiveautomation.com/u/adonnell)\
**Post date:** [April 30, 2022, 8:26pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/12 "2022-04-30T20:26:15Z")

</div>

> [@pturmel](#):
>
> Never poll aliases from outside the processor.

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

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 30, 2022, 8:58pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/13 "2022-04-30T20:58:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [May 2, 2022, 3:14pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/14 "2022-05-02T15:14:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [May 14, 2022, 3:52pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/15 "2022-05-14T15:52:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [September 15, 2022, 8:53pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/16 "2022-09-15T20:53:17Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [September 15, 2022, 8:54pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/17 "2022-09-15T20:54:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [September 15, 2022, 9:37pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/18 "2022-09-15T21:37:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [September 15, 2022, 9:38pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/19 "2022-09-15T21:38:14Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Aaron\_Shivne](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Aaron\_Shivne](https://forum.inductiveautomation.com/u/Aaron_Shivne)\
**Post date:** [September 15, 2022, 10:11pm UTC](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842/20 "2022-09-15T22:11:19Z")

</div>

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

[Next page](https://forum.inductiveautomation.com/t/guardlogix-plc-and-ignition-tag-count-polling-rate/58842.md?page=2)
