Follow the packet from SCADAbr to the USB/serial converter, across the serial wiring, and into the slave. The converter LED shows that activity reached the adapter, but the failed node search does not show where the return path stopped. The disappearing port and Function code: 0x60 must therefore be diagnosed as separate observations until an operating-system event or captured response connects them.
Which troubleshooting approach fits this failure?
| Approach | Result or decision value | Limitation |
|---|---|---|
| Reinstall SCADAbr | The problem continued after reinstallation. | Does not test USB enumeration, port ownership, serial settings, wiring, or slave response. |
| Replace the USB/serial converter | The same behavior occurred with another converter. | Reduces the likelihood of one defective adapter, but leaves the host USB path, driver, cable, application state, and serial network unchanged. |
| Monitor Linux device events | Distinguishes a real USB removal from a port hidden or held by SCADAbr. | Must run while the datasource changes state and the failure occurs. |
| Check the complete Modbus serial path | Separates transmit-only activity from a valid slave response. | Requires the slave address, framing, wiring, and timing to be checked against the connected device. |
Start with Linux device-event monitoring, then check the serial path. Reinstalling again has little diagnostic value, and replacing more converters repeats a test that has already produced the same result.
Where does the Modbus request stop?
The request originates in the enabled SCADAbr datasource. SCADAbr opens /dev/ttyUSB, applies the configured serial settings, and transmits node-search requests through the converter. The flashing converter LED proves that the adapter sees activity; it does not prove that bytes reached the correct slave or that a reply returned with valid framing and error checking.
| Path stage | Observed indication | What to verify next |
|---|---|---|
| SCADAbr to Linux serial interface | The port is selectable while the datasource is disabled. | Whether SCADAbr can open the same device when enabled and whether another process already owns it. |
| Linux to USB/serial converter | The converter LED flashes during node search. | Whether Linux logs a removal, reset, driver unbind, or immediate re-enumeration. |
| Converter to serial bus | No node is found. | Signal wiring, reference conductor where required, interface type, and transmit direction control. |
| Serial bus to Modbus slave | No valid response is reported. | Slave power, node address, baud rate, framing, response timing, and whether another master is using the bus. |
The port disappearing from the SCADAbr selection page after the datasource is enabled may mean that the application has opened it exclusively. Some interfaces list only currently available ports, so an open port can vanish from the selector without leaving Linux. Only device-event monitoring can distinguish that normal ownership state from a real USB disconnect.
Is Linux actually removing the USB serial device?
Layer one first. Open a Linux console and start the device monitor with udev monitor. Leave it running while reproducing the complete sequence: disconnect the converter, reconnect it, reload the SCADAbr page, enable the datasource, and start the node search.
| Monitor result | Meaning | Next action |
|---|---|---|
| Removal or unbind event occurs when polling begins | The host is losing the USB device or its driver association. | Check the USB cable, connector, host port, available USB power, driver messages, and whether the converter immediately re-enumerates. |
| Reset followed by re-enumeration | The adapter is dropping and returning rather than remaining continuously attached. | Record the event sequence and correlate it with datasource activation; test a different host USB connection while keeping the serial side controlled. |
| No removal or reset event |
/dev/ttyUSB remains present at the operating-system layer. |
Treat its disappearance from the page as port ownership or UI filtering, then continue with SCADAbr logs and serial-path checks. |
Also compare the device identity before and after the event. A reconnect can create a new device association even when the displayed path looks similar. SCADAbr must open the device that Linux currently exposes, and the service account running SCADAbr must have permission to access it. A permission or busy-port failure can occur without any USB removal event.
Could the serial settings explain the failed node search?
Yes. A stable device node only proves that the local adapter exists. Modbus serial communication also requires both ends to use matching framing and a valid physical interface. Read the configured values from the slave or its documentation rather than selecting likely defaults.
| Setting | SCADAbr side | Slave-side comparison |
|---|---|---|
| Port | /dev/ttyUSB |
Confirm this is the converter physically connected to the target bus. |
| Node address | Used by the node search | Read the active slave address and confirm that it is included in the search. |
| Baud rate | Configured in the Modbus serial datasource | Must match the slave exactly. |
| Data bits, parity, and stop bits | Datasource framing | Must match the slave framing exactly. |
| Response timing | Datasource timeout and scan behavior | Compare with the slave response characteristics and converter behavior. |
| Serial electrical interface | Determined by the converter | Must match the slave interface and wiring topology. |
If the link uses a differential multidrop interface, verify conductor polarity, common reference requirements, biasing, and termination appropriate to that network. If it uses a point-to-point interface, verify transmit, receive, and signal reference connections. Do not change several settings at once; otherwise a successful poll will not identify which correction mattered.
Treat Function code: 0x60 as the exception text reported by the SCADAbr Modbus master, not as proof that a slave returned that function code. Determine its origin by checking whether any receive bytes arrived and whether they form a valid Modbus frame. With no valid reply, investigate port access, framing, wiring, addressing, and timing before diagnosing slave application logic.
What procedure isolates and fixes the fault?
- Disable the SCADAbr datasource and confirm that
/dev/ttyUSBappears in the application. - Run
udev monitorin a Linux console and record the events produced by one controlled disconnect and reconnect. This establishes the normal event pattern. - Keep the monitor active, enable the datasource, and start one node search. Note whether Linux reports removal, reset, unbind, or re-enumeration at the instant the port disappears from the page.
- If no device event occurs, verify that only SCADAbr is opening the serial port and that its service account has access. A port held by another process can block the master even though the device remains attached.
- If a device event occurs, isolate the host-side path: inspect the USB connection and driver messages, then test a different host USB connection. Two converters producing the same symptom shifts attention toward the shared cable, host, power, or driver path.
- Confirm the converter’s electrical interface matches the slave network. Correct the conductors, reference, and any topology-dependent termination or biasing before changing Modbus parameters.
- Copy the slave’s active node address, baud rate, data bits, parity, and stop bits into the datasource. Set response timing from the slave documentation or a measured response, not by guessing.
- Enable the datasource once and poll a known node. Preserve the udev output and SCADAbr exception text if the fault returns.
How do I verify that the correction worked?
- Watch
udev monitorthrough repeated polls. Datasource activation must not produce a removal, reset, or re-enumeration event. - Confirm that SCADAbr opens
/dev/ttyUSBwithout a busy-port or permission failure. The selector may hide an exclusively opened port, so judge success by datasource status and communication, not by the selector alone. - Poll the intended slave and verify that SCADAbr receives valid Modbus responses rather than only flashing the converter LED.
- Repeat the poll cycle and confirm that the node remains reachable and
Function code: 0x60does not return.
FAQ
Can I fix a disappearing Modbus serial port by reinstalling SCADAbr?
Reinstallation did not change this failure. Test Linux device events, serial-port ownership, service permissions, and the physical link before repeating application installation.
Does a flashing USB/serial converter LED prove the Modbus slave replied?
No. It proves adapter activity, but a successful transaction requires a correctly addressed request and a valid response using matching baud rate and framing.
Can I treat Function code 0x60 as a slave fault?
Not without a valid received Modbus frame. Run udev monitor, confirm the device stays attached, then verify that repeated polls return valid slave data without Function code: 0x60.