# How to avoid values when connection to the PLC is lost **URL:** \ **Category:** Ignition\ **Tags:** ignition79\ **Created:** [March 31, 2020, 9:45am UTC](https://forum.inductiveautomation.com/t/how-to-avoid-values-when-connection-to-the-plc-is-lost/33546 "2020-03-31T09:45:18Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![roizundak](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/roizundak/32/4430_2.png) [@roizundak](https://forum.inductiveautomation.com/u/roizundak)\ **Post date:** [March 31, 2020, 9:45am UTC](https://forum.inductiveautomation.com/t/how-to-avoid-values-when-connection-to-the-plc-is-lost/33546/1 "2020-03-31T09:45:18Z")
Hi, I have lot of tags with connection issue we cant fix it in the field. I want that when the connection is lost the Historical Data and wouldn’t save the zero value. ---
**Author:** ![diat150](https://avatars.discourse-cdn.com/v4/letter/d/a587f6/32.png) [@diat150](https://forum.inductiveautomation.com/u/diat150)\ **Post date:** [March 31, 2020, 12:31pm UTC](https://forum.inductiveautomation.com/t/how-to-avoid-values-when-connection-to-the-plc-is-lost/33546/2 "2020-03-31T12:31:08Z")
I think this ties back to how your opc server tags the connection issue. OPC has quite a few different quality codes for devices that lose communication.Not sure if this is changeable in your OPC server, or if you are using the Ignition drivers if that is something that is changeable. I do know that the opc servers that I work with use a code that is called “unknown, hold last value”, or something to that effect, which keeps the last known good value in the tag. ---
**Author:** ![roizundak](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/roizundak/32/4430_2.png) [@roizundak](https://forum.inductiveautomation.com/u/roizundak)\ **Post date:** [April 1, 2020, 6:39am UTC](https://forum.inductiveautomation.com/t/how-to-avoid-values-when-connection-to-the-plc-is-lost/33546/3 "2020-04-01T06:39:19Z")
Thanks for replay. So my new question is how do i hold last value while my Quality is Bad? Thanks! ---
**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 1, 2020, 10:57am UTC](https://forum.inductiveautomation.com/t/how-to-avoid-values-when-connection-to-the-plc-is-lost/33546/4 "2020-04-01T10:57:34Z")
Try using a second tag of the same type, but as a memory tag. In the source tag, monitor with a value change event and write to the 2nd tag when quality is good. ---
**Author:** ![dcamp1](https://avatars.discourse-cdn.com/v4/letter/d/dc4da7/32.png) [@dcamp1](https://forum.inductiveautomation.com/u/dcamp1)\ **Post date:** [April 1, 2020, 11:00am UTC](https://forum.inductiveautomation.com/t/how-to-avoid-values-when-connection-to-the-plc-is-lost/33546/5 "2020-04-01T11:00:20Z")
Hello, I just wanted to add my opinion (And it may not be relevant for your application)! I too started out wanting my tags to hold the value if I lost communication, but once I had the system running in the Real World and other user became involved, we found out this was misleading. If communication is lost I have a set value “Displayed” and all of my user know that value, so example: a float value of 99.99 means lost communication and any other value is actually a good reading. Just something to think about. ---
**Author:** ![Sanderd17](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/sanderd17/32/8735_2.png) [@Sanderd17](https://forum.inductiveautomation.com/u/Sanderd17)\ **Post date:** [April 1, 2020, 11:48am UTC](https://forum.inductiveautomation.com/t/how-to-avoid-values-when-connection-to-the-plc-is-lost/33546/6 "2020-04-01T11:48:28Z")
If it’s for historical data, you could solve the issue when displaying too. There’s a separate table that holds timestamps for when tags go stale. You can use those timestamps to get the last value to display.