[BUG] Modbus RTU CRC and Data Length Errors

[raHa358]

Description When using FUXA with Modbus devices, data cannot be received by FUXA. This was tested for two different devices, resulting in _readMemory CRC errors for one, and both CRC errors and Data length errors for the other. The errors are as per the below:

When using SerialPort, in the case of the first device, 'IOT Board,' no data is read. In the case of the second device, 'Test,' every few transmissions one or two are successful and data is shown in the FUXA tags. Both devices were tested independent of FUXA with Modbus Poll, and data is able to be transmitted and received accordingly.

When using RTUBufferedPort, there are no errors for 'IOT Board,' but all values received in Tags are 0. For 'Test,' there are no errors and all data is received.

Edit: I suspect some form of baud rate / timing related issue in FUXA, as for the device 'Test,' using SerialPort, where every few transmissions, some are successful, the pattern seems to be cyclic. E.g, when polling is done every 3 seconds, for every 2 transmissions resulting in an error, the following transmission is successful. When polling is set to 2 seconds, every 4~6 transmissions is followed by ~4 successful transmissions.

As mentioned in some other Issue threads opened on Modbus related bugs, the frame delay setting was tested with both devices for 10ms, 100ms, as well as a few other values, and polling was tested at 1s, 5s, and 10s. None of the mentioned parameters fixed the errors.

Example successful transmissions logged by Modbus Poll are shown below for each device:

'Test'

Tx:- 06 03 00 00 00 02 C5 BC

Rx:- 06 03 04 01 30 02 42 0C 51

'IOT Board'

Tx:- 01 03 9C 40 00 1A EB 85

Rx:-01 03 34 00 01 00 01 00 02 00 2D 00 09 00 09 00 01 00 00 00 00 00 02 00 00 00 01 01 29 EE EE 09 4C 01 29 01 96 01 26 00 00 EE EE 00 2A 00 00 00 00 EE EE 00 00 00 01 A3 84

Environment

• FUXA version: 1.1.19
• Node.js version: 14.21.3
• npm version: 6.14.18
• Platform/OS: Windows 11
• Browser: Firefox

[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.