[BUG] Modbus RTU CRC and Data Length Errors

[raHa358]

[BUG] Modbus RTU CRC and Data Length Errors

[raHa358]

I've just noticed that both within FUXA's web UI as well as in fuxa\runtime\devices\modbus\index.js (Lines 640 and 695), the addresses used are 6 decimal digits, and not 5. Apologies if I'm mistaken as I'm not too familiar with JS, or Modbus in the first place, but could this be the source of my issue, as well as some of the other issues submitted on Modbus RTU? From what I see online, Modbus addressing is usually 5 decimal digits as per the below.

This would also explain why my issue is only present for IOT Board and not for Test, as Test is reading from address 000000 (6 digits), and I'd assume reading from address 00000 (5 digits) wouldn't be different, where IOT Board is trying to read from address 400000 (6 digits), but values are stored at 40000 (5 digits).

[rvbatista]

Hello @raHa358,

The number of digits in addresses are irrelevant in this case. The table that you sent is classic Modbus, where the devices implement only 1-9999 "memories" for each FC. Modbus today uses 1-65536, with the 4x, 3x, 1x and 0x been only the indication of different memory areas.

Now about your zero length and CRC erros. Can you use Wireshark to investigate how fuxa is forming the request to the devices?

There is a know issue with too fast request and Ethernet por where the requests are not sent correctly.

[raHa358]

Couldn't quite figure out how to monitor USB using wireshark, so here's the logged data packets from a different port sniffer. Polled the device once from FUXA for the first 4 holding registers. Packets 40 and 54 seem to be Tx and Rx.

Edit: It would seem I confused myself reading this device's documentation through google translate from chinese, and I should've been reading from address 40000 within the memory area 4x. So 44000 and onwards. Now that I put in the correct addresses, both of my devices are essentially in the same situation. Values can be read and written, but only one of every few transmissions is actually valid. I'll log the data packets to show both the ones with data length / CRC errors and the successful ones in a bit.

[raHa358]

Polled the device four times. The packets sent at 44:10 and 44:16 resulted in CRC Errors, and the packets at 44:07 and 44:13 were received properly.