Skip to content

Modbus connection issues

Symptom umbrella: the control software cannot read or write the drive. The footer indicator is red, the live readout is frozen, writes return errors.

First three checks

  1. Network reachability: Test-NetConnection -ComputerName 192.168.50.10 -Port 502 from PowerShell.
  2. RETA-01 LEDs: check the LEDs on the adapter inside the drive enclosure (visible without opening the cabinet).
    • All green → adapter is healthy.
    • MODULE STATUS red → the adapter cannot reach the drive's internal bus. Power-cycle the drive (open and close the main switch with a 30 s wait between).
    • LINK / ACTIVITY off → the Ethernet cable is unplugged or dead.
  3. Drive keypad: check for fault codes.
    • Fault visible → Faults and alarms.
    • LOC in the upper-left → press LOC/REM to switch to remote.
    • REM in the upper-left and no fault → drive is fine; the problem is upstream.

Application-level issues

If the network reaches the drive but the application still cannot operate it, walk through:

Wrong Modbus profile

51.16 PROTOCOL must be 0 (Modbus/TCP, ABB Drives profile). If it has been changed to a different protocol, the register map is wrong and every read/write looks like nonsense.

Fix: keypad → PARAMETERS → 51 → 16 → set to 0 → save → power-cycle drive.

Wrong critical parameters

The four parameters that must be set for remote control:

  • 99.02 = 1 (ABB Standard macro)
  • 98.02 = 4 (EXT FBA, RETA-01)
  • 10.01 = 10 (COMM start/stop)
  • 11.03 = 8 (COMM REF1)

If 10.01 = 10 is wrong, the drive ignores all start/stop writes. If 11.03 = 8 is wrong, the drive accepts the start but spins at zero. Restore from Parameter recovery.

Wrong calibration constant in the software

If the drive accepts the start and spins, but at the wrong speed compared to the requested setpoint, the REF1 = drive_RPM × 22.42 constant in the software has drifted from what the drive currently does. Re-run ref1_sweep.ps1 and update.

Connection conflict

The RETA-01 is happy with one Modbus master at a time. If two clients (e.g. WindTunnelControl.ps1 and ADCL WinSoft, or AeroWare and one of them) try to talk to it concurrently, they will both see flaky reads and missed writes. Close all but one.

pymodbus version skew (ADCL WinSoft only)

pymodbus 3.13 renamed slave= to device_id=. If the dev venv has been upgraded out from under the project, register reads silently raise TypeError. The .exe builds with the pinned version from pyproject.toml; if the bundled .exe works but the dev install does not, recreate the venv from pyproject.toml.

What "flaky" usually means

If the connection works but reads time out occasionally:

  • Bad Ethernet cable is the most likely culprit. Swap with a known-good cable.
  • Two masters connected at once (see above).
  • High-rate polling against a fresh-socket-per-call client. Not an issue at our current rates but if you increase the polling rate above 10 Hz in WindTunnelControl.ps1 you will hit this.

When all else fails

If none of the above is the answer, open a WT_MS_<n>/debug_session.md and start a methodical bring-up: PowerShell + Test-NetConnection, then WindTunnelControl.ps1 against the drive, then ADCL WinSoft. Each step that works narrows the failure scope; each that does not is documented with the exact symptom. This is the same pattern that produced the WT_MS_2 diagnosis of AeroWare's broken Modbus path.