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>< D6 ><56><01><03><02><00><03>< F8 > - 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>< D6 ><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>< D6 ><56>_
Then it calculates the correct length of bytes to be received and reads all replied bytes that are:
<01><03><02><00><03>< F8 ><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>< D6 ><56><01><03><02><00><03>< F8 ><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?

[karlp]

That just looks like you have a rs485 dongle that is listening to what it sends. There are use cases for that, but modbus is not one of them.

[calin-baciu]

Hi @karlp !

Unfortunately your're right. :))

uint8_t request[] = {0x01, 0x03, 0x09, 0x01, 0x00, 0x01, 0xD6, 0x56};

n = write(fd, request, sizeof(request));

printf("Requested %d bytes: ", sizeof(request));
for (int i = 0; i < n; i++) {
    printf("<%02X> ", request[i]);
}
printf("\n");

sleep(1);

n = read(fd, buffer, sizeof(buffer));

printf("Received %d bytes: ", n);
for (int i = 0; i < n; i++) {
    printf("<%02X> ", buffer[i]);
}
printf("\n"); 

Terminal output:
Requested 8 bytes: <01> <03> <09> <01> <00> <01> < D6 > <56>
Received 15 bytes: <01> <03> <09> <01> <00> <01> < D6 > <56> <01> <03> <02> <00> <03> < F8 > <45>

Thank you for your time and patience to help me! I'll try to change the dongle or lastly the library.

If you consider this scenario useful an improvement can be added to the library. There are many Chinese USB-RS485 dongles on the market.

Thanks again!

[mhei]

I have a branch available with a feature, which drops such "echo" bytes. You have to use an additional call modbus_rtu_set_suppress_echo to enable it. Testing and feedback to this branch is welcome.

[calin-baciu]

Hello @mhei!

Thank you for your reply! I will check it and I will let you know how it works for me.

[calin-baciu]

Hello again, @mhei !

It works like a charm! Now I can see the correct reply from the VFD in the terminal.

Opening /dev/ttyUSB0 at 38400 bauds (N, 8, 1)
Bytes flushed (0)
[01][03][09][01][00][01][D6][56]
Waiting for a confirmation...
<01><03><02><00><03>< F8 ><45>
Bytes not read in TTY buffer 0:
//----- I print the previous message to check if there are some remaining bytes in buffer, it's perfect, all bytes were read by the library

Many thanks for your help!