A TOP Server connection that drops for four seconds and recovers is harder to troubleshoot than one that stays down. By the time you open the TOP Server Configuration, tags are back to Good quality and the useful clues are buried under new events.
We’ve seen it many times in support - a PLC, drive, or meter stops responding to TOP Server for a few seconds, operators see bad quality or stale values at the HMI or SCADA, and then everything clears before anyone can look.
Changing timeouts or scan rates at that point can make the next failure harder to explain. A better first step is to build a small evidence package that shows what changed, when it changed, and whether the problem hit the whole device or only part of the data path.
Is the connection down right now, not intermittent? Start with our
TOP Server Troubleshooting Scenario: Device Side Communication Issue step-by-step guide or get help with jonjon.ai right now. For a tour of every built-in tool, see TOP Server Startup & Testing Tools.
Before you collect logs, confirm what the operator or consuming application actually sees. Does every tag from the device go bad at once? Do only writes fail? Does the connection recover on its own? The answers narrow the search before anyone touches the driver configuration.
Record the first and last observed time, the affected device or channel, and a few representative tags. Include value, quality, and timestamp from the client that reported the problem. Use the same clock source across the PLC, TOP Server, network equipment, and client systems whenever possible. Mismatched clocks turn a simple timeline into a guessing game.
TOP Server exposes system and statistics tags for status and performance monitoring that you can read like any other tag. For many drivers, the tag that shows whether a device is in an error state is [Channel].[Device]._System._Error, for example Channel1.PLC1._System._Error.
Bring that tag into a trend, historian, or alarm system so the next interruption has a timestamp, even if it clears before an engineer connects. Statistics tags add performance feedback for your channels and devices, and archiving them in a historian gives you a record for later troubleshooting.
Remember: this tag does not identify the root cause. It gives you a clean boundary for the event. Correlate that boundary with the TOP Server Event Log, Communications Diagnostics, PLC status, network logs, and the application that consumed the data.
Communications Protocol Diagnostics (also called Channel Diagnostics) record the requests TOP Server sends to a device, the responses it receives, and their timestamps. Enable diagnostics in the channel properties for the channel under investigation.
For an intermittent issue, use the persistence options that fit the expected time window and the available disk space in TOP Server Administration. Then save the diagnostic output after the event. Our guide to using Channel Diagnostics walks through the steps.
Look for a clear sequence around the failure: successful transactions, a timeout or protocol error, retries, and the first successful response after recovery. Compare a tag that failed with one that stayed healthy. This helps separate a device-wide interruption from an address, data type, or request-specific problem.
TOP Server sits between the control device and one or more client applications, so test both sides. The OPC Quick Client is included with every TOP Server installation. If it shows values updating with Good quality, TOP Server is working with the device. Leave it running next to your production client through the next failure window, then compare what each view shows during the dropout.
The Event Log records driver and runtime messages that the client never sees. It covers configuration, client, and device-side events, and the driver help files explain what the logged errors mean. OPC Diagnostics shows the events between an OPC UA, DA, or HDA client and TOP Server in real time and historically.
For a full walkthrough, see our step-by-step guide: Device Side Communication Issue
Network checks should use the same endpoint and port as the driver. As we covered in our Tech Support Corner, a successful ping does not prove the industrial protocol session is healthy. Check port reachability, duplicate IP addresses, link changes, managed switch events, and firewall session limits that line up with the recorded time.
Change one variable at a time after the evidence is saved. If you adjust a timeout, cable, switch port, firmware setting, or request size, repeat the same observation window. A controlled comparison gives the team something stronger than a temporary return to service: proof of which change fixed the issue.
Repeat the capture during a known production cycle when possible. Some failures appear only during a recipe change, controller download, shift transition, or burst of client requests. Mark those events on the same timeline so normal process activity can be compared with the communication break.
When the issue needs deeper review, generate a TOP Server Application Report. The utility installs with TOP Server and collects your current configuration file, event log, licensing information, and details about the PC. Send it with the time window of the event, plus:
Intermittent failures become manageable when the system is ready to record them. Configure a simple tripwire, preserve the protocol exchange, and compare the server view with the client and network views. If the pattern is still unclear, open a Support Ticket and send the evidence package so the investigation can start with the event itself.