An intermittent BadNotConnected result must be isolated at the first point where a failed attempt differs from a successful one. The client sometimes completes the full path—connect, browse, read, and write—so the investigation should compare individual connection attempts rather than treat the endpoint as permanently incompatible.
Where does the connection request stop?
Follow the packet. The Reference Client sends a connection request through the Windows network stack and physical network to the PLC address and configured server port. After the transport connection reaches the listener, OPC UA establishes its communication channel and session. A failure at any earlier stage can leave the application without a usable session and surface as BadNotConnected.
| Path stage | Successful observation | Failed observation | Action |
|---|---|---|---|
| Client process | Connection begins and remains active | Immediate local exception or closed socket | Capture the complete exception chain and client log |
| Windows network interface | Frames leave the selected interface | No outbound traffic | Check interface selection, routing, and local filtering |
| Physical network | Request and response traffic appears | Loss, retransmission, link transition, or no reply | Inspect cabling, link state, interface counters, and switching path |
| PLC listener | The configured port accepts the connection | The port refuses or ignores it | Check server state, listener binding, connection limits, and PLC diagnostics |
| OPC UA channel and session | Channel and session complete | Transport opens but the OPC UA exchange stops | Compare endpoint selection, security configuration, certificates, and server diagnostics |
BadNotConnected identifies the client state at the time of the failed operation; it does not identify which path stage caused that state. The earlier exception, trace entry, packet transition, or server event is the diagnostic record that matters.
What does the 80 percent failure rate reveal?
The reported installation used VS2017 on Windows 10, started the Reference Client with F5, and entered the PLC IP address and port manually. About 80% of attempts failed, while about 20% connected and then allowed variable reads and writes.
A successful read and write proves that the selected route, endpoint, and application data path can work. It makes a permanent address error, permanently closed port, or completely incompatible server configuration less likely. It does not clear intermittent layer-one faults, duplicate addressing, transient filtering, server connection exhaustion, startup races, or channel/session negotiation failures.
| Observed behavior | Diagnostic meaning | Next comparison |
|---|---|---|
| Failure before any server response | Investigate the network path or listener first | Physical counters, address resolution, route, and port acceptance |
| Transport connects, then closes | The failure moved above the physical and routing layers | OPC UA message sequence and PLC server log |
| Connection succeeds only on some launches | Process timing or retained server/client state may participate | Debugger versus normal launch and cold versus repeated attempts |
| Session connects and read/write works | The server data model and basic access path are usable | Compare the successful handshake with the first failing handshake |
Which troubleshooting approach should be used?
| Approach | What it establishes | Limitation |
|---|---|---|
| Repeat Connect until it works | Confirms intermittent behavior | Produces no causal boundary and may consume more server resources |
| Inspect only the final client status | Confirms that no usable session exists |
BadNotConnected may follow several different lower-level failures |
| Compare one successful and one failed attempt by layer | Locates the first divergent network or OPC UA event | Requires synchronized client, network, and PLC records |
Use the layered comparison. Layer one first: inspect link state, cable path, switch-port counters, and interface errors before changing OPC UA settings. Then verify that every attempt targets the same address and port. Move to endpoint and session analysis only after failed attempts reliably reach the PLC listener.
Changing multiple timeouts, security selections, or network components at once destroys the comparison. Apply one correction at the first divergent stage, repeat the same test series, and record whether the success rate changes.
What must be recorded for each attempt?
Create one row per attempt and assign a timestamp or sequence number before clicking Connect. Capture both successes and failures from the same client launch when possible.
| Field | Value to record | Comparison rule |
|---|---|---|
| Target address | Exact PLC IP address entered | It must remain identical across attempts |
| Target port | Exact server port entered | Compare it with the active PLC listener |
| Launch mode |
F5 debugging or normal execution |
Test each mode separately |
| Connection timing | Request start, first response, closure, and final status | Locate the first missing or delayed event |
| Client setting | Selected endpoint and security choices shown by the client | Keep them fixed during a comparison series |
| Client result | Full exception chain, not only BadNotConnected
|
Identify the earliest failure |
| Server result | Matching PLC server diagnostic entry | Determine whether the request reached the server |
A packet capture is most useful when it covers a known successful attempt and the immediately adjacent failed attempt. If the failed capture contains no outbound request, stay on the client host. If the request leaves but no response returns, inspect the physical path, addressing, and listener. If both directions carry transport traffic before closure, correlate the last exchange with client and PLC diagnostics.
How should the fault be corrected?
- Stop repeated connection attempts and clear any client sessions using the same test endpoint through their normal disconnect or shutdown path.
- Confirm stable link indication and inspect interface error, discard, and link-transition counters on the client, intervening network equipment, and PLC connection.
- Check that the entered PLC IP address resolves to one physical device throughout the test. An address conflict can redirect successive attempts to different interfaces while preserving the same displayed target.
- Verify that the PLC server is running and listening on the exact entered port. Compare its connection and resource diagnostics before and after one failed attempt.
- Run a controlled series outside the debugger, then a separate series using
F5. Keep the address, port, endpoint, and security selection unchanged. A launch-mode dependency directs attention to client startup order, timing, or exception handling. - Compare successful and failed traces. Correct the first difference: repair the link if traffic is lost, correct addressing or routing if the request reaches the wrong destination, restore the listener if the port is unavailable, or align endpoint security and trust configuration if transport succeeds but OPC UA negotiation stops.
- Restart only the component implicated by the trace, then repeat the controlled series. Do not use a broad restart as proof of root cause.
How is the repair verified?
Verification must exercise connection establishment and application services. Use the same address, port, endpoint selection, and launch mode that previously produced failures. Record consecutive attempts across fresh client launches and deliberate disconnect/reconnect cycles. Each attempt must reach an active session without BadNotConnected, followed by a known read and an authorized test write whose value is read back.
Review the client trace, packet sequence, and PLC diagnostics after the series. There should be no unexplained transport closures, rejected sessions, rising interface errors, or abandoned server connections. If one attempt fails, compare that attempt at the first divergent stage rather than averaging it into a success percentage.
FAQ
Can I fix BadNotConnected by increasing a timeout?
Only when the trace shows that the same handshake stage completes successfully when given more time. A timeout change will not repair a dropped link, wrong destination, unavailable listener, or rejected OPC UA negotiation.
Does a successful OPC UA read prove the network is healthy?
No. It proves that one attempt completed the route, channel, session, and read service. Compare interface counters and packet flow across both the successful attempt and an adjacent failure.
Can I verify the repair by connecting once?
No. Repeat fresh launches plus disconnect/reconnect cycles under the previously failing conditions, then complete a known read and an authorized write/readback on every attempt. Accept the repair only when the first divergent failure is gone from the client trace, network capture, and PLC diagnostics.