[3.6-dev] Modbus Frame Delay Issues

[benagricola]

FAO @dc42

Testing the Modbus code as it stands in 3.6-dev using the following macro:

    ; Read spindle state bitmap
    M261.1 P1 A1 F3 R4097 B1 V"spindleInputState"

    ; Read requested frequency
    M261.1 P1 A1 F3 R4098 B1 V"currentFrequency"

    ; Read the output frequency, current, voltage
    M261.1 P1 A1 F3 R4099 B1 V"spindleOutputState"

    echo { var.spindleInputState }
    echo { var.currentFrequency }
    echo { var.spindleOutputState }

I would quite consistently get no or bad response from Modbus device from the second or third M261.1 call, unless I added G4 P1 between each call.

The code currently calculates a frame delay of 4 characters, which gets rounded down to 2ms at 38400bps (the configuration on my UART).

The delay function documentation says The actual delay may be up to 1 millisecond less than this, or arbitrarily greater. - and I think in my case this is consistently coming up at less than 1ms, for example:

This shows the delay between the end of the reply from the initial command, and the start of the request for the second command - which is actually less than 1ms.

The legacy modbus spec seems to suggest that for baud rates over 19200 a static frame delay should be used of at least 1.75ms, but this isn't mentioned at all in the most recent spec.

Either way, if I add +1 to the calculated frame delay to account for it possibly waiting 1ms less than expected, it always works.

[github-actions]

This issue has been automatically closed because it does not originate from a Duet3D administrator.
Please create a discussion on https://forum.duet3d.com first and fill out the corresponding GitHub template if the bug or feature request is acknowledged.

[dc42]

Thanks for your report. It seems odd that a delay(2) call could end up delaying less than 1ms. Anyway, I've added another 1 to the value that CalcTransmissionTime returns.