BadNoCommunication

BadUnderlying device

What you actually see

The session stays connected and browsing works, but a group of tags all flip to a bad status at the same moment and stay there until the underlying device comes back.

Why it happens

• The field link between server and device is downAn OPC UA server fronting a PLC, a fieldbus master or a serial device reports this when its own driver connection fails. Cable, switch port, power to the device, or a fieldbus master fault will all produce it. The OPC UA hop is fine, which is why every other part of the server keeps responding normally.
• The PLC is stopped or in a non-running stateA controller in stop, in a fault state, or mid-download stops answering its driver. Tags backed by the program go to no communication while server-object nodes and static configuration nodes stay Good, which is the diagnostic signature to look for.
• Driver or channel not started in the serverIn a gateway product, each channel and device has its own enable state and its own connection. A disabled or failed-to-start channel gives every tag under it this status, immediately and consistently, from the moment the server started.
• Aggregating server has lost its upstream sessionA server that aggregates other OPC UA servers reports this for the branch belonging to a downstream server it cannot reach. The status is generated locally, so nothing about your own session or certificate is involved.
• Address or item path no longer valid at the deviceAfter a PLC program change, a driver may still be connected but unable to resolve a specific item, and some products report that as no communication rather than as an unknown item. This one affects individual tags rather than a whole branch, which distinguishes it from a link failure.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Check the scope of the failureRead a few Server object nodes such as Server_ServerStatus_State and Server_ServerStatus_CurrentTime. If those are Good while field tags are bad, the OPC UA layer is healthy and the problem is downstream. If they are bad too, look at the server itself first.
2. Look at the server's own device diagnosticsGateway products expose channel and device status in their configuration tool or in an OPC UA diagnostics branch. That is where the driver-level error text lives, and it is far more specific than the status code your client sees.
3. Confirm the device is reachable at the network levelFrom the machine running the OPC UA server, not from your workstation, ping the device and test the driver port. Server and client often sit on different network segments, so a test from the wrong host proves nothing.
4. Check the controller stateA PLC in stop or fault answers some requests and not others. Read the vendor's own status tag, or look at the controller front panel or engineering tool. A recent download or a mode switch is the most common trigger.
5. Distinguish permanent from transientIf the status clears and returns on a cycle, you are looking at an intermittent link or a device that is polled faster than it can answer. Slow the sampling interval on the affected items and see whether the status stabilises before chasing the network.
6. Handle it as data quality, not as a client errorIn the client, a bad status is a DataValue you should record, not an exception to retry. Store the status alongside the value so downstream analytics can exclude the period rather than interpolate over it.

Where it shows up, by tool and stack

What it looks like in the log

MonitoredItem ns=2;s=Line1.Motor.Speed status changed to BadNoCommunication
Device connection lost; all tags on channel Line1 reporting no communication
Server object nodes Good, device branch reporting BadNoCommunication

Confirm the fix

Restore the device link and confirm the affected items return to Good with a fresh SourceTimestamp, not a repeat of the last value from before the outage.

Stop it happening again

Monitor the status code, not just the value, and alert on a branch going bad rather than on individual tags. Where the server exposes device diagnostics as nodes, subscribe to them so you learn about a link failure from the server rather than by inference.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.