ReadDeviceInformationRequest fails with struct error

[dhoomakethu]

Versions

• Python: 2.7/3.x
• OS: NA
• Pymodbus: 1.5.2
• Modbus Hardware (if used): Veris-8036 / Schenier EM-6400

Pymodbus Specific

• Client: rtu-sync

Description

Trying to execute mei message (ReadDeviceInformationRequest) and ReportSlaveIdRequest results in struct error. This is partly because these requests do not get_response_pdu_size methods implemented and expected response length is passed as None . The _wait_for_data method in client.sync.ModbusSerialClient class for some devices does not wait for the complete data to come in to the read buffer, thereby returning partial data .

Code and Logs

error: unpack requires a string argument of length 2
(7 additional frame(s) were not displayed)
...
  File "pymodbus/transaction.py", line 164, in execute
    request.unit_id)
  File "pymodbus/framer/rtu_framer.py", line 217, in processIncomingPacket
    if self.checkFrame():
  File "pymodbus/framer/rtu_framer.py", line 89, in checkFrame
    self.populateHeader()
  File "pymodbus/framer/rtu_framer.py", line 152, in populateHeader
    size = pdu_class.calculateRtuFrameSize(data)
  File "pymodbus/mei_message.py", line 118, in calculateRtuFrameSize
    _, object_length = struct.unpack('>BB', buffer[size:size+2])

unpack requires a string argument of length 2

[chintal]

This should be fixed in ModbusRtuFramer.checkFrame(), which should catch the struct error from populateHeader() and return False, as it already does with IndexError and KeyError. There should also be some kind of timeout which ensures advanceFrame() is called if the packet is irretrievably broken or will never come, but I expect that's already there since you're already handling IndexError and KeyError in exactly the same way.

A time.sleep() timeout is not the best thing to add here.

[dhoomakethu]

Fixed with v2.1.0

[aharrah]

Hello,

I've run into a curious issue in sync.py's _wait_for_data().

I have two USB to RS485 converters. One behaves well, but the other, which unfortunately I am strapped with, does not.

Specifically the poorly behaving converter will send along about 9 bytes, then buffer the remaining bytes. This buffering takes longer than the 0.01 second threshold in _wait_for_data(), such that _wait_for_data() breaks out of its while loop since it sees no new data for more than 10ms.

The response is approximately 119 bytes long (ReadDeviceInformationRequest)

Changing
time.sleep(0.01)
to
time.sleep(0.03)

works around the problem, at least for the length of data I'm expecting. Do you think increasing that timeout is wise? Is there a better approach?

Here is a link to the code in question:
https://github.com/riptideio/pymodbus/blob/31c165026f94dccb851a05f0fb32adcbf39003eb/pymodbus/client/sync.py#L536

Thank you for your time,
Andy