Every variable in the runtime carries a status next to its value. The status tells whether the value can be trusted: it is Good while the owning driver delivers values, and it changes when the driver reports a problem with the device or with the individual point. The value itself is kept in every case, so a page keeps showing the last known reading together with the status.
The status is visible in several places:
- On a page, an object bound to a variable shows a status icon next to its value for every status other than Good. A grey question mark means Unknown; the red icons mean a fault or a disabled point.
- In the runtime API and MCP, ReadVariable and GetData return the status as text in the Status field, for example "Good" or "Unknown".
- In the Historian Viewer, the Status column shows the status that was recorded with each sample.
- On the OPC UA server, the status is exposed as the OPC UA status code of the node, so an OPC UA client sees the quality of every variable it reads.
Status Values
The table lists every status, when the runtime sets it, and how the OPC UA server reports it to a client.
| Status | Meaning | Set when | OPC UA server status code |
|---|---|---|---|
| Good | The value is current and was delivered by the owning driver. | The driver delivered a value for the point since it started, and the device is connected. | Good |
| Unknown | No value has been delivered for the point since its driver started. The value shown is the initial 0 or the last known reading from before a reload. | At project load for every device variable, and again when the device is stopped for a reload after a device or variable edit or a Restart Device action. The first value delivered by the driver turns the status into Good. | Uncertain (initial value) |
| Disabled | The variable or its device is disabled in the configuration. | The Enable option of the variable or of the device is switched off. | Bad (out of service) |
| ConnectionLost | The device cannot be reached, so the value is the last reading before the connection was lost. | The driver loses its connection to the device. The device Channel State variable reads the connection state at the same time. | Bad (no communication) |
| FormatError | The point could not be read or written, for example because its address does not exist on the device or the value does not fit the configured type. | The driver reports a failed read, write or address resolution for this point while the device itself stays connected. | Bad (data encoding invalid) |
| Timeout | A request for the point was not answered in time. | The driver reports a timeout for this point. | Bad (timeout) |
| Warning | The value was delivered but the device marked it as uncertain. | The driver reports an uncertain quality for the point, for example a value received with a quality flag set. | Uncertain |
No rows match the filter.
Unknown Until the First Value
A device variable starts in the Unknown status and becomes Good with the first value the driver delivers for that point. A connection that comes up does not make a point Good by itself: only a delivered value does. This applies to every driver in the same way, for a polled point on the first successful scan and for a subscribed point on the first notification from the server.
The rule makes a point that the device never answers visible. A variable with an OPC UA Node id that the server rejects, an element Node id of an array that the server exposes as one node, or an address that is never read keeps the Unknown status with its initial value, where it used to read as 0 with a Good status. The timestamp of such a variable is not advanced while it is Unknown, so it shows since when the point has been without a value.
A device reload sets the device variables back to Unknown while the driver restarts. Saving a device, saving a variable and the Restart Device action all reload the device, so a corrected address shows Unknown until the driver delivers the first value on the new address. The last value is kept during the reload. Local variables are Good from the moment the project loads, and the variables of a device in Simulation mode are Good as well.
Conditions and the Historian
Alarm and event conditions, the Run When trigger of a UDT script member and the Exceptions expression of a schedule are evaluated only while every variable they reference has the Good or Warning status. While a referenced variable is Unknown, ConnectionLost, FormatError, Timeout or Disabled, the condition is suspended: an active alarm stays active, an inactive alarm stays inactive, an event keeps its edge state and no actions run. A suspended schedule exception does not stop the schedule.
The System Log Viewer reports a suspension once per variable, with the number of conditions that reference it, and reports it again when the variable delivers a value and its conditions evaluate again. The first evaluation after a suspension uses the delivered value, so an alarm whose condition is met at that moment goes active exactly as it would have without the interruption.
Build a communication alarm on the Channel State variable of the device, for example PLC1.ChannelState != "Connected", to be notified when a device stops delivering values. The Channel State variable is written by the driver itself and keeps the Good status while the driver runs, so an alarm on it is evaluated during a device outage.
The Historian records the status together with every sample, so the Historian Viewer and the OPC UA Historical Access show which samples were recorded while a point was in a fault status.