Issue with "modbus_read_registers" function

[calin-baciu]

Hello Stephane!

Firstly I would like to thank you for your work! It was not easy to implement this library and you put a lot of effort in it.

I started to use this library and I have issues with it. I will put here some details that I spotted, perhaps I'm doing something wrong.
I have a USB-RS485 converter and I try to create a small software that communicates with a Delta VFD - Variable Frequency Driver (http://www.realimpeks.co.rs/download/delta_vfd_el.pdf) via Modbus in RTU mode. Details about RTU mode of the VFD can be found on page 131. It's worth to mention that VFD sends back CRC CHK Low and the last byte of the frame is CRC CHK High. The main issues are that the library skips to red the last CRC byte and calculates the CRC for the entire sent message + received one.

I call the function like this:
uint16_t status[256];
rc = modbus_read_registers(ctx, 0x0901, 1, status);

Address 0901 is the baud rate of the VFD, pages 60 and 127 in the mentioned datasheet. The request is sent correctly to VFD and it also replies correctly. The driver is in debug mode and below is the output in the terminal:

<01><03><09><01><00><01><56><01><03><02><00><03> - Later edit: output from library debug mode
ERROR CRC received 0xF803 != CRC calculated 0x9CF0 - Later edit: output from library debug mode
Received 1 bytes: <45> - Later edit: I added this line to print what remains in the TTY buffer after modbus_read_registers function call

• the first part in bold is the request which is correct, the italic part is the reply without the last CRC byte. I suppose the driver don't calculate correctly the length of the replied message and stops to read the list byte.
• I noticed that the driver calculates the CRC for both the sent message and received one. The library calculates the CRC for this bytes:
  <01><03><09><01><00><01><56><01><03><02><00> and the result is indeed the calculated 0x9CF0.
• <45> this is the last byte sent by the VFD but skipped by the driver

My expected behavior is this. The library sends the read request as it is above:
<01><03><09><01><00><01><56>_
Then it calculates the correct length of bytes to be received and reads all replied bytes that are:
<01><03><02><00><03><45>
Afterward calculates the CRC only for the received bytes and compares with received CRC
<01><03><02><00><03> - received bytes and <45> - received CRC

I changed in "compute_meta_length_after_function" the default: length = 2; instead of 1 in the switch case.
The read command sent and answer received is correct, including the missing CRC <45>.
<01><03><09><01><00><01><56><01><03><02><00><03><45>
And the library result is this:
ERROR CRC received 0x45F8 != CRC calculated 0x45DC

By using an online calculator it's clear that the library calculates the CRC over the entire sent command+received answer which is the calculated 0x45DC:
https://crccalc.com/?crc=01%2003%2009%2001%2000%2001%20D6%2056%2001%2003%2002%2000%2003&method=CRC-16/MODBUS&datatype=hex&outtype=hex

Please let me know if I do something wrong or there is indeed a bug in the library.
Many thanks in advance,
Calin Baciu

[karlp]

Are you sure you have the correct parity/word bit size set? Even in debug mode, you should be seeing the request/response on different lines, you're not even seeing the complete details, I'm used to the debug mode of libmodbus showing the full transmissions, IF they are actually there.

Your expected fields don't look right though, but I think that's just a side effect. Either way, people have been using libmodbus with it's existing crc calculations and checks with millions of devices for years so it's definitely not a problem with the libmodbus crc calculation. From skimming the manual of your device, I think it's most likely that you don't have the same baud/parity settings on each side as you expect. This also correlates with what appears to be overlapping request/response. Alternatively, you might have a second device with the same address on the line?

[calin-baciu]

Hi Karlp!

Thank you for your quick reply!

I put a few Later edit: tags above. In my setup I have 3 devices: orangePi (USB-RS485 converter), VFD and a laptop with Windows (I have the same USB-RS485 converter connected to my laptop).

The VFD is configured in Modbus RTU mode, protocol <8,N,1>, I double checked right now in datasheet and in VFD menu, parameter 09.04 = 6.

The modbus driver is initialized with the same parameters:
#define UART_PORT "/dev/ttyUSB0"
#define BAUD_RATE 38400
ctx = modbus_new_rtu(UART_PORT, BAUD_RATE, 'N', 8, 1);
// I skiped to copy some checks
modbus_set_debug(ctx, TRUE);
modbus_rtu_set_serial_mode(ctx, MODBUS_RTU_RS485);
// I skiped to copy some checks

I use the laptop just to monitor the RS485 bus. With Realterm I can see that the message is correctly sent by the orangePi and the reply is correct from VFD. OrangePi calculates the correct CRC value for request and the VFD calculates CRC just for it's own reply.

From my tests the library expects less with 1 byte to read and calculates the CRC over the entire frame: "data sent+data received". It should calculate CRC just for received message from VFD.

I don't have any ideas to try. Any help is highly appreciated!

[karlp]

no, the crc is per message, not some sort of combined "sent plus received" you have definite data collisions somewhere, or multiple masters you aren't aware of. you should a request message with a crc and then a reply message with a crc clearly distinguished by the t3.5 time. seeing it all smashed together and missing bytes is an indication that you have something else wrong. I would suspect baud/parity and/or extra devices reading/writing at the same time.

sometimes trying to have multiple ports open will give you missing bytes as they are "consumed" by the other application for instance. You really shouldn't be seeing request/reply all smashed on the same line like that.