Field report · SerialMon
A commissioning day
A 132 kV bay, a new RTU, and a SCADA master that will not accept a single indication. This is what a commissioning day can actually look like. We follow the signals all the way.
The bay is energised at ten past seven and nothing works. The RTU has power, the SCADA master is polling, and the operator three hundred kilometres away sees an empty list where twelve indications should be. Nobody in the control building can say whether the problem is the RTU, the cabling, the protocol configuration, or the master. That is the ordinary state of a commissioning morning, and it is exactly why a protocol analyzer is valuable on site.
The instinct is to start changing settings. But that is almost always wrong. Every setting changed before the link is understood is one more variable to unwind later, and on a live bay the unwinding happens under time pressure with a customer waiting. The alternative is to look first: put a passive tap on the line and read what the two ends are actually saying to each other.
Tapping the link
A serial tap is a passive listener. It does not answer, does not poll, and does not appear on the bus as a device — which matters, because on a bay that is already energised you cannot introduce new equipment without consequences. SerialMon is connected to the tap and decodes both directions at once.
Within ninety seconds the picture is different. The master is polling. The RTU is answering. Frames are moving in both directions and the checksums are good — so the cable, the wiring and the baud rate are all fine, and three of the four candidate causes are gone before anyone has touched a configuration screen.
The link was never broken. It was answering a question nobody had asked it. Substation commissioning
Reading the telegrams
Raw bytes alone would not have settled it. 68 0E 0E 68 is a frame header and nothing more; what matters is the ASDU inside it, the cause of transmission, and the information object address. Seeing the parsed telegram beside the raw bytes — same row, same instant — is what turns a byte stream into an answer.
The RTU was sending its indications with a common address of one. The master was configured to expect two. Every telegram was well-formed, correctly framed, and quietly discarded at the far end. No error was raised anywhere, because from each end's point of view nothing had gone wrong.
Where the day went
Twenty minutes of listening replaced what would otherwise have been a morning of guessing, and the rest of the day went where it was supposed to go: proving every point in the signal list, one at a time, with a record of each result.
