The short answer
How to Diagnose a Bad Quality Tag
To diagnose a bad quality tag, first read the quality code and the driver diagnostics to learn which layer is reporting it, then work outward: confirm the tag address and data type match the controller, confirm the driver connection to the device is up and polling, confirm the controller tag exists and holds a value, and only then look at the field signal. Most bad quality is a communication or configuration fault, not an instrument fault, and the quality code says which.
Key points
- Read the quality code first. It names the layer that failed.
- One tag bad with the others good is configuration. All tags on a device bad is communication.
- Check the driver diagnostics before touching the controller or the field.
- A frozen good value and a bad value are different problems with different causes.
- Fix the cause, then confirm the quality returns and the value moves.
What you need
- SCADA configuration access and the driver diagnostic tool
- The tag database export or the tag configuration screen
- The controller programming software with online access
- The network drawing with device addresses
- A laptop that can ping and, for serial devices, a protocol test tool
Procedure
- 1
Read the quality code
Every platform carries a quality code with the value: an OPC-style code such as Bad, Bad Not Connected, Bad Config Error, Bad Device Failure, Uncertain, or a platform-specific equivalent. Find it on the tag detail or in the tag browser. Not Connected and Device Failure point to communication; Config Error and Bad Address point to the tag configuration; Uncertain points to a stale or clamped value.
- 2
Scope the failure
Look at the other tags from the same device and the same driver. All bad means the connection; one bad means that tag. Tags from other devices on the same driver bad too means the driver or the network segment.
- 3
Open the driver diagnostics
Every driver has a status view: connection state, poll counts, success and failure counters, last error, response time. A connection that shows failures climbing names the device. An error text such as timeout, connection refused, illegal address, or exception code narrows it.
- 4
For a connection problem, test the path
Ping the device from the SCADA server. If ping fails, the network drawing and the switch diagnostics are next: link light, VLAN, cable, the device power. If ping works and the driver cannot connect, check the port, the unit ID or slot number, and whether another master has the device connection count exhausted.
- 5
For a configuration problem, check the address
Compare the tag address in SCADA with the controller: tag name and case, program scope, array index, data type, and on register-based devices the register number and the addressing offset. A tag renamed in the controller and not in SCADA is the most common single cause.
- 6
Check the data type
A SCADA tag configured as an integer reading a controller REAL, or a 16-bit read of a 32-bit value, produces a bad or a nonsense value depending on the driver. Match them exactly.
- 7
Check the controller
Online with the controller, confirm the tag exists, holds a value, and is being updated by the program. A controller tag that is fine while SCADA shows bad confirms the problem is between them.
- 8
For an Uncertain or stale value, check the timestamp
A value with a timestamp that stopped advancing is stale: the driver stopped updating it, or the controller stopped writing it. Compare the tag timestamp with the current time and with the poll rate. A stale good value is a different failure from a bad one, and its causes are on the frozen values page.
- 9
Look at the field only when the layers above are clean
If the driver reads the controller and the controller tag is bad or out of range, the input channel and the field device are next: an input card fault, an open loop, an under-range signal. The controller has its own diagnostics for those, and they point to the channel.
- 10
Fix, confirm, record
Correct the cause. Confirm the quality returns to Good and that the value changes when the process changes. Record the cause and the fix; a bad quality that came from a tag rename will come from the next rename too.
Reading the quality code
| Quality | Usual meaning | Look at |
|---|---|---|
| Bad, Not Connected | The driver has no connection to the device | Network, device power, port, connection limits |
| Bad, Device Failure | The device answered with an error or stopped answering | Driver diagnostics, device status, controller fault |
| Bad, Config Error or Bad Address | The tag address does not exist on the device | Tag name, scope, index, register number, offset |
| Bad, Data Type Mismatch | The address exists but the type does not match | Data type on both ends; 16 versus 32 bit |
| Bad, Comm Failure after good | The connection was up and dropped | Intermittent network or serial; timeouts; retries |
| Uncertain, Last Usable Value | The last good value is being shown because updates stopped | Timestamp; poll rate; the frozen values page |
| Uncertain, Sensor Not Accurate or Out of Range | The controller flagged the input | The input channel and the field signal |
| Good, Local Override | Someone forced the tag | The override list; remove it when the cause is fixed |
Verification
- The quality code on the tag is Good and the timestamp advances.
- The value changes when the process or the controller value changes.
- The driver diagnostics show a stable connection with failures no longer climbing.
- Any override or force used during diagnosis is removed.
- The cause and the fix are recorded, and the tag database is corrected if the cause was configuration.
Frequently asked questions
- Why does the tag show bad quality only sometimes?
- Intermittent communication: a serial bus with a marginal device, a radio path with fades, a network with packet loss, or a timeout set too close to the device response time. The driver counters show the failure rate. Lengthen the timeout if it is the cause; fix the path if it is not.
- Can bad quality come from the historian?
- A trend that shows gaps or a bad marker reads the quality the historian stored, which came from the driver at the time. A live tag with good quality and a trend with bad quality means the problem was earlier and is now fixed, or the historian collection failed. Check both timestamps.
- What should the display show when quality is bad?
- The value in a distinct style with a visible bad quality indicator: an outline, a color from the reserved palette, a marker such as a question mark or an X, and no number that could be read as a real value. Displaying the last value as if it were live is the failure the quality code exists to prevent.
- The controller has no fault and SCADA shows every tag bad. What is it?
- The connection between them: the SCADA server network interface, the switch, a changed IP address, a firewall rule, a driver license or service that stopped, or the controller connection limit reached by another client. The driver diagnostics and a ping from the server narrow it in minutes.
Related topics
- Tag Shows Bad QualityA tag flagged bad or uncertain by the driver. What the quality codes mean, the difference between a device that is not answering and an address that does not exist, and how to clear each.
- Values Frozen On ScreenThe HMI shows numbers that are not changing while the plant runs. Whether the controller, the communication driver, the tag server, or the display stopped, and the order to check them in.
- Ethernet Device Drops OfflineAn industrial Ethernet device that disappears and comes back. Duplex mismatch, cabling, spanning tree, and the switch counters that identify it in minutes.
- EtherNet/IPHow EtherNet/IP moves control data: CIP over standard Ethernet, implicit I/O connections on a requested packet interval, explicit messaging, producer and consumer tags, and what the network has to provide.
- SCADA ArchitectureThe parts of a SCADA system and how data moves between them: I/O servers, the tag database, clients, the historian, the alarm server, and the topologies from a single panel PC to a redundant, distributed plant.
- How to Build a TagCreate a SCADA tag that is correct, documented, and consistent with every other tag: name it by the convention, bind it to the right controller address or name, and verify it against the live value and the I/O list before it goes on a screen.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.