# Tags Becoming Stale **URL:** \ **Category:** Ignition Early Access\ **Created:** [October 14, 2020, 5:46pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673 "2020-10-14T17:46:30Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![rfedyk](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rfedyk](https://forum.inductiveautomation.com/u/rfedyk)\ **Post date:** [October 14, 2020, 5:46pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/1 "2020-10-14T17:46:30Z")
I have a problem whereby tags are going stale. Ignition version 8.0.15 I’m still not sure that it isn’t a network problem, but I am unsure as to how to diagnose the Ignition system to check its usage. I have six clients currently connected and since the last two were brought online tags have been going stale. I restart them and they are fine for a few minutes, then I lose them again. Then when I check the others, the problem occurs on all Clients. This is not specific to one or two machines. I have deleted pretty much everything out of the designer projects except some buttons, lamps and a string message display. I am using indirect addressing for most of the tags. I use a client script event on startup to verify the IP and set the machine number. I set a client tag on page opened event to set a pathtag variable which is used for indirect addressing. Nothing seems to be too taxing. Single Rockwell L84S PLC with a dedicated Ethernet connection for the Clients. Clients are Cincoze Windows 10 machines. All brand new equipment. The tags stay stale and I have to restart the client application to regain a connection. I am currently using one default tag provider, but was looking into creating one tag provider per project (2-4 Clients). Will this be a help? I am stuck for an answer. Can someone give any pointers? ---
**Author:** ![bpreston](https://avatars.discourse-cdn.com/v4/letter/b/4af34b/32.png) [@bpreston](https://forum.inductiveautomation.com/u/bpreston)\ **Post date:** [October 14, 2020, 5:52pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/2 "2020-10-14T17:52:56Z")
If you want anyone to make suggestions you will probably have to provide more information? Little things like what kind of tags? If OPC tags, what kinds of devices? What type of tag group they use? Does it happen when something specific is happening or all the time? Do they stay stale or come back on their own? With the forum, more information is better. If you don’t give enough to give someone a place to start, you probably won’t get any replies that help figure it out. ---
**Author:** ![rfedyk](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rfedyk](https://forum.inductiveautomation.com/u/rfedyk)\ **Post date:** [October 14, 2020, 5:59pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/3 "2020-10-14T17:59:54Z")
Hit the send key by accident. Amended above. ---
**Author:** ![bpreston](https://avatars.discourse-cdn.com/v4/letter/b/4af34b/32.png) [@bpreston](https://forum.inductiveautomation.com/u/bpreston)\ **Post date:** [October 14, 2020, 6:22pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/4 "2020-10-14T18:22:04Z")
I’m assuming your talking two different things. I’m also assuming your talking Vision. Your talking stale tags but when you mention using indirect tagging, I’m assuming you talking tag binding. When I’m looking at what you described, I think you may be making some parts of it more complicated than you need to. You mentioned doing a startup script to verify your IP and set a machine number and then setting a client tag as each page is opened. You can do a client tag as an expression using the system client/network/ipaddress tag to find your IP address in an expression. Then you can use a case in the expression to set your machine number. It would be something like: ```auto case({[System]Client/Network/IPAddress} ,'192.168.1.1', 1 ,'191.168.1.2', 2 ,-1) ``` Doing it this way takes out the startup script that you would have to test by starting clients. Then you can test your screens in the designer to see if they are having the same issue. When your talking stale tags. Are they stale when you look at them in the designer or only on the client? If they are working in the designer but not on the client then there is something wrong with how they are bound to whatever your displaying. If they are stale in the designer, does your device have a fault? Are you seeing any errors in your log? With your setup right now, if you go into the diagnostics for the client, are you seeing any error? ---
**Author:** ![rfedyk](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rfedyk](https://forum.inductiveautomation.com/u/rfedyk)\ **Post date:** [October 14, 2020, 6:36pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/5 "2020-10-14T18:36:14Z")
Your assumptions are correct. Vision and tag binding. The gateway connects to one PLC and multiple Client PCs used as HMI screens. The HMI PCs do not run any software other than as ignition clients. I am doing what you described above for startup. The Client startup script sets a ScreenNum tag. This identifies which panel the Operator is at. There is a reason for this, but I won’t bore you. In addition to this, a tag is set on a vision window opened event as a second reference. This is a secondary tag binding reference as there are common buttons and lamps etc. on every screen. This simply creates an indirect reference e.g. Tool1, Tool2 etc. My question is two fold I guess. Is any of this incorrect or in some way contributing to the problem I am experiencing? What, where and how do I look for what may be causing my stale tags? I am sure there is a whole host of other information I still need to provide, but am unsure as to where to look. ---
**Author:** ![bpreston](https://avatars.discourse-cdn.com/v4/letter/b/4af34b/32.png) [@bpreston](https://forum.inductiveautomation.com/u/bpreston)\ **Post date:** [October 14, 2020, 6:48pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/6 "2020-10-14T18:48:25Z")
I think your trying to do something similar to what I have for one project. I have 16 lines running on one project all using the same screens. The reason I lean away from the startup script is if the script fails, you may not see it unless you check the diagnostic logs on your individual client. Thats why I like doing it through an expression in a client tag. By doing it that way, I also set up a separate memory tag with a test line number for when I’m in the designer. The -1 at the end of my case is linked to that test tag so I can vary which line I’m looking at while building and testing the screens. Doing it through a startup script, I can’t do that. How are you testing it in the designer to make sure your indirect bindings are working? Are any of your tags stale in the designer or only an issue on the client? I’m not sure what your trying to do with the secondary reference part. I would assume you would still do these connections through an indirect binding. I’m not sure what you would gain by doing it through a vision window opened event. One of the biggest question is when tags are stale on your client, are the stale in the designer. If they are good in the designer then it has to do with how your binding the tags. You also need to look at the client diagnostics log. When the tags go stale, I would assume your getting some kind of error or if one of your scripts is failing, I would expect an entry. ---
**Author:** ![rfedyk](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rfedyk](https://forum.inductiveautomation.com/u/rfedyk)\ **Post date:** [October 14, 2020, 7:14pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/7 "2020-10-14T19:14:45Z")
Thanks for your prompt reply. When I’m testing I set the terminal number to 0. It works with the PLC code I have, so I know it will work for all. Plus I always bench test with a real HMI screen to try to find any additional problems (normally hardware), like I have been recently. I didn’t really like the idea of the startup script, for the same reasons you mentioned, so changing that shouldn’t be a big deal. Secondary reference is for each part of the machine. e.g. Tool{page}.faulttag So as I change pages the reference to the tags change for common items like mode control and status. I’m not a fan of this either. For exactly the same reasons as startup. I know the tags are good in designer and are/were good in the clients until recently. They start up fine and just go stale after a few minutes. I see no issues in Designer. I know the scripts are good, because I tested them. The tags go stale with absolutely no interaction whatsoever. I will see what I can see in the diagnostics log. ---
**Author:** ![bpreston](https://avatars.discourse-cdn.com/v4/letter/b/4af34b/32.png) [@bpreston](https://forum.inductiveautomation.com/u/bpreston)\ **Post date:** [October 14, 2020, 7:18pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/8 "2020-10-14T19:18:29Z")
I think the diagnostics logs are the next place to look. Something has to cause them to lose it. I would assume it should be there. I’m assuming the secondary references are custom properties, you could also add property change scripts looking at these and add print statements so you can see when and how they change. If something else is changing them some how, it may help point you in the right direction. ---
**Author:** ![witman](https://avatars.discourse-cdn.com/v4/letter/w/d2c977/32.png) [@witman](https://forum.inductiveautomation.com/u/witman)\ **Post date:** [October 14, 2020, 7:54pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/9 "2020-10-14T19:54:11Z")
We are on 8.0.16 and still experiencing a bug that can cause persistent red overlays on items bound to tags in clients after a connection loss. Usually they clear, but sometimes they do not and restarting the client resolves them. Before some recent fixes, the problem was more consistent; now it happens less often. You’d have to check the change logs, but some related fixes may be in 8.0.16 if you can upgrade. ---
**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:** [October 14, 2020, 8:54pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/10 "2020-10-14T20:54:05Z")
I understand there may be some funkiness going on with Logix firmware 32.x and tag subscriptions. ---
**Author:** ![rfedyk](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rfedyk](https://forum.inductiveautomation.com/u/rfedyk)\ **Post date:** [October 14, 2020, 9:27pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/11 "2020-10-14T21:27:59Z")
Perhaps someone from ignition could comment and possibly explain how I resolve this? Or a work around? Or if an update is planned? ---
**Author:** ![BryanB](https://avatars.discourse-cdn.com/v4/letter/b/57b2e6/32.png) [@BryanB](https://forum.inductiveautomation.com/u/BryanB)\ **Post date:** [October 21, 2020, 3:45pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/12 "2020-10-21T15:45:39Z")
> [@pturmel](#): > > I understand there may be some funkiness going on with Logix firmware 32.x and tag subscriptions. Do you have a reference for this? I'm using v32.011 on some PLCs and have been having intermittent stale tag issues as well. ---
**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:** [October 21, 2020, 3:53pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/13 "2020-10-21T15:53:15Z")
I believe I was remembering this report: > [@OPC UA - new tags not showing up all the time in Designer](http://forum.inductiveautomation.com/t/opc-ua-new-tags-not-showing-up-all-the-time-in-designer/35306): > > I have a Perspective project that has a lot (44k) tags gathered from several different OPC UA devices. There are 5 different Control/GuardLogix processors configured. Their configuration is shown below and is consistent with exception of the names, IP address, and slot. We have found that when adding new tags to the processor that the new tags do not always show up in Designer’s tag tree. Perhaps we haven’t always waited long enough, but it doesn’t seem to happen in a reasonable amount of ti… ---
**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:** [October 21, 2020, 3:54pm UTC](https://forum.inductiveautomation.com/t/tags-becoming-stale/39673/14 "2020-10-21T15:54:09Z")
Or this one: > [@AB Logix Firmware 32 tag qualities Unknown](http://forum.inductiveautomation.com/t/ab-logix-firmware-32-tag-qualities-unknown/24870): > > Ignition 7.9.10 Logix Driver 3.9.10 I’m using the above and connecting to a Control Logix (GuardLogix actually) 5583ES with firmware 32. Connection is established and I can browse the PLC, but any tag I try to read has Unknown quality. I’ve just tested now in Ignition 8.0.1 with Logix Driver 4.0.1 and this works, so I’m guessing there was something added into this version to handle changes in the later AB firmware versions. I note that this version isn’t compatible with v7.9.10 so I can’t jus…