Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-59286

Modbus serial slave does not clear receive message buffer

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 5.12.0 Beta 3
    • 5.7.0, 5.11.0 Alpha
    • SerialBus: MOD Bus
    • None
    • Windows 7 x64, 2 x RS232 serial ports connected back to back
    • 682c5ca041483b7d3e8994e7fac5bcab6327e5c2 (qt/qtserialbus/5.12)

    Description

      The Modbus serial server does not clear its receive buffer under the following circumstances, potentially causing the serial server to stop responding until it is disconnected/re-connected:

      • Modbus t3.5 timeout expired
      • Spurious characters cause incorrect function code to be checked

      In the first case I would expect anything in the buffer to be cleared so it can recover after a delay.

      In the second case this seems to be caused by checking the received length before the checksum, which I assume is done to capture messages that are received across multiple QSerialPort::readyRead signals.

      To replicate:

      • Have 2 RS232 serial ports connected back to back
      • Run the Modbus slave example in debug mode and connect to RS232 port, server address 1
      • Run a serial terminal on the other RS232 port
      • Send 'U' from serial terminal
      • Send hex data "\x01\x04\x00\x01\x00\x01\x60\x0A" from serial terminal. This is valid Modbus message to server address 1 to read 1 input register starting from 1.
      • Wait > t3.5
      • Send hex data "\x01\x04\x00\x01\x00\x01\x60\x0A" from serial terminal. This is valid Modbus message to server address 1 to read 1 input register starting from 1.

      What you see in the debug log is:

      qt.modbus.lowlevel: (RTU server) Received ADU: "55010400010001600a"
      qt.modbus: (RTU server) ADU does not match expected size, ignoring

      qt.modbus.lowlevel: (RTU server) Received ADU: "55010400010001600a010400010001600a"
      qt.modbus: (RTU server) ADU does not match expected size, ignoring

      I would have expected the buffer to clear after the 'U' due to t3.5 being so short and again after the first valid message, but it does not. And the data stays in the buffer until you disconnect the slave and re-connect, meaning the server never responds.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              ablasche Alex Blasche
              dmcminn dmcminn
              Votes:
              6 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes