Modbus Status 110: Troubleshooting Python Reset Logic

Modbus status 110 indicates a timeout in the supplied evidence. When piTest can reset the status but Python cannot, the immediate cause is process-image synchronization: the Python application can keep rewriting the reset output before the Modbus subsystem completes its reset sequence.

Why the Python reset remains active

With autorefresh=True, RevPiModIO maintains the values assigned by the application in the process image. The Modbus subsystem may clear FAN_P_STATUS_RESET internally, but Python does not automatically adopt that change and can write True again.

Implement the reset handshake

Set the reset output, hold it until FAN_P_STATUS changes to 0, and then clear the reset output. Do not issue consecutive True and False assignments without waiting for status confirmation.

rpi.io["FAN_P_STATUS_RESET"].value = True

# Wait until autorefresh reports that the Modbus status was cleared.
while rpi.io["FAN_P_STATUS"].value != 0:
    continue

rpi.io["FAN_P_STATUS_RESET"].value = False

Autorefresh synchronizes the process image every 20 ms according to the evidence, so a reset pulse shorter than a refresh cycle will usually fail. The status transition, rather than an assumed delay, is the reliable completion condition.

Use shared process-image access when required

Initialize RevPiModIO with shared_procimg=True when Python must accept output changes made by the Modbus subsystem instead of continuously enforcing its local output copy.

rpi = RevPiModIO(autorefresh=True, shared_procimg=True)

This option does not eliminate the handshake requirement. Keep FAN_P_STATUS_RESET asserted until the refreshed value of FAN_P_STATUS confirms the reset, then write the reset output back to False.

Diagnose status 110 timeouts

1. Confirm the current setting name and units. The initial report calls 1000 ms an action interval, while the successful change is described as an action timeout.
2. Record the status with piTest -r FAN_P_STATUS before changing communication timing.
3. Test the reported 2200 ms action-timeout setting. This value cleared the timeout in the reported installation, but the evidence does not establish it as a universal requirement.
4. Verify that status 110 no longer returns over repeated Modbus actions.

The connected-device information reportedly recommends a maximum timeout of 60 ms. Do not assume that this value and the RevPi action timeout represent the same timer: the evidence does not define either field precisely, and the reported successful 2200 ms setting conflicts numerically with that recommendation. Identify each timing parameter in the two device configurations before applying the result elsewhere.

FAQ