Polling over Modbus RTU - continuous CRC errors

[tfboy]

I'm trying to obtain data from an Aira heat pump which has an existing and operational data connection between itself and a Carlo Gavazzi ET340 energy meter.

I've tapped into the Modbus bus and have found the communication settings used - 19200 baud, 8 bits, even parity...

However, I get continuous CRC errors, for example:

14.05.2025 09:57:07.113 'Port' Info: Start polling
14.05.2025 09:57:07.113 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:07.298 'Device' Rx: 02 03 28 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 44 DA 02 03 2B D3 00 14 BD EB 02 03 28 32 34 30 38 30 37 31 30 38 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C BC 
14.05.2025 09:57:07.299 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:08.075 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:08.267 'Device' Rx: 02 03 08 47 00 B6 41 02 03 26 00 00 00 00 00 00 01 18 00 72 00 06 F5 F8 00 00 0E 30 0B B8 0B B8 00 00 10 92 10 B3 12 51 79 12 25 0B B8 00 00 0A DF 
14.05.2025 09:57:08.269 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:09.076 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:09.252 'Device' Rx: 14 04 00 34 00 02 32 C0 14 04 04 14 00 00 FA 7D 
14.05.2025 09:57:09.252 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:10.077 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:10.144 'Device' Rx: 02 03 28 32 34 30 38 30 37 31 30 38 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C FE 00 14 BD EB 
14.05.2025 09:57:10.145 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:11.078 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:11.251 'Device' Rx: 14 04 00 00 00 06 72 CD 14 04 0C 09 A1 00 00 00 00 00 00 00 00 00 00 5A 5A 
14.05.2025 09:57:11.253 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:12.080 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:12.189 'Device' Rx: 02 03 2B 70 00 14 4D C9 
14.05.2025 09:57:12.190 'Device' Error: Not correct response. Requested unit (unit) is not equal to responsed
14.05.2025 09:57:13.082 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:13.220 'Device' Rx: 02 06 07 CF 00 00 B8 B2 02 06 07 CF 00 00 B8 B2 
14.05.2025 09:57:13.222 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:14.082 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:14.267 'Device' Rx: 14 04 00 0C 00 06 B2 CE 14 04 0C 01 80 00 00 00 00 00 00 00 00 00 00 14 B9 
14.05.2025 09:57:14.268 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:15.082 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:15.236 'Device' Rx: 02 03 2B 98 00 14 CD FD 
14.05.2025 09:57:15.237 'Device' Error: Not correct response. Requested unit (unit) is not equal to responsed
14.05.2025 09:57:16.085 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:16.205 'Device' Rx: 02 03 08 33 00 14 B7 99 
14.05.2025 09:57:16.206 'Device' Error: Not correct response. Requested unit (unit) is not equal to responsed
14.05.2025 09:57:17.085 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:17.283 'Device' Rx: 14 04 00 34 00 02 32 C0 14 04 04 14 00 00 FA 7D 
14.05.2025 09:57:17.284 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:18.084 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:18.190 'Device' Rx: 02 03 28 32 34 30 38 30 37 31 30 38 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C BC 
14.05.2025 09:57:18.191 'Device' Error: Not correct response. Requested unit (unit) is not equal to responsed
14.05.2025 09:57:19.085 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:19.283 'Device' Rx: 02 03 2B 98 00 14 CD FD 02 03 28 31 30 30 30 37 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 AE BB 
14.05.2025 09:57:19.284 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:20.085 'Device' Tx: 01 03 00 00 00 0A C5 CD 
14.05.2025 09:57:20.283 'Device' Rx: 02 03 08 47 00 B6 41 02 03 26 00 00 00 00 00 00 01 18 00 72 00 06 F5 F8 00 00 0E 30 0B B8 0B B8 00 00 10 92 10 A4 12 51 79 12 25 0B B8 00 00 44 6B 
14.05.2025 09:57:20.284 'Device' Error: RTU. Wrong CRC
14.05.2025 09:57:20.742 'Port' Info: Finish polling

Now I don't think it's necessarily a problem with the ModbusTools application, probably just some strange communication setting. But I have no idea how to troubleshoot.
Can you offer any advice?

Many thanks for this amazing looking open source software BTW!

[serhmarch]

Hello.

In this log window, it looks like something is wrong with the serial port settings, especially the baud rate.

Maybe try combining different serial port settings and see what happens.

[tfboy]

Hello.

In this log window, it looks like something is wrong with the serial port settings, especially the baud rate.

Maybe try combining different serial port settings and see what happens.

Many thanks for your quick response.
I'll try, but the number of permutations are crazy.

One question: I'm using the Windows version of the app. Do the Port settings defined in the app override the communication settings set in device manager? Or do I need to change both simultaneously so they have the same settings?

[serhmarch]

Do the Port settings defined in the app override the communication settings set in device manager?

Yes

Or do I need to change both simultaneously so they have the same settings?

No

[zizzbird]

@serhmarch
Everything works fine when the software-simulated device is the only slave. However, when I add another physical slave device, I consistently get errors from it in the logs, similar to what @tfboy showed in his picture. Although everything still operates normally, I've noticed that the simulation program on the master station now experiences significant delays, eventually timeout before it continues to run.

How can I configure the simulation program to only respond to the RX data for the specific unit referenced in the device?

[serhmarch]

Hello.

I guess in your case reducing port setting Timeout Inter Byte should help (set it like 2 milliseconds or something).

Here the similar issue.

[zizzbird]

Hello.

I guess in your case reducing port setting Timeout Inter Byte should help (set it like 2 milliseconds or something).

Here the similar issue.

The problem still exists. I tried changing the "Timeout Inter Byte" to 1 and setting the frame interval on the master station to 3ms. However, when it encounters data from the physical slave, it still reads that data, causing the bus to be blocked until a timeout occurs. I read the issue you mentioned, and it seems that listening exclusively to a specific slave ID is an unsolvable problem.

I tried another simulator and everything worked perfectly, but it doesn't allow me to configure more than 200 registers, which makes it difficult for me to simulate my physical device.
open modsim

[serhmarch]

Maybe I didn't fully understand the problem. Let's take it one step at a time.

You want to combine a physical slave and a ModbusTools server in one Modbus network (for example, RS-485), right?

1. If so, then the first thing you need to do is to make sure that the serial port settings (baud, data bits, stopbits, etc.) in the ModbusTools server are correct so that they are the same as both the physical slave and the master.

2. Make sure that the addresses of the physical and simulator Modbus devices (unit id, slave id) are different !!!, otherwise it can lead to errors like you described before. To do this, you can use the context menu for Device in ProjectView, select Edit Device Ref ... and edit the Units field:

[zizzbird]

I completely understand the operation you described. As shown in the picture, I used ModbusTools to simulate a device with slave ID:2. Additionally, I have a physical device with slave ID:4 on the bus. The master station periodically polls the registers of both slave ID:2 and slave ID:4.

1. When the master polls the ModbusTools simulated device with slave ID:2, ModbusTools responds quickly, taking only 1-10ms.
2. When the master polls only the physical device with slave ID:4, it also only takes 1-10ms. However, when the ModbusTools simulated slave ID:2 is added to the bus, it takes the master 200-400ms to read data from the physical slave ID:4.

I've observed the logs in ModbusTools and noticed that it always processes the frames intended for the physical device with slave ID:4. I suspect this is what's causing the delay.

[serhmarch]

First of all these

Rx: 04 06 31 00 00 00 87 63 04 06 31 00 00 00 87 63

are 2 Modbus packets joined into single packet because Timeout interbyte port setting is too big. You must reduce it and then you can see something like this:

Rx: 04 06 31 00 00 00 87 63
Rx: 04 06 31 00 00 00 87 63

which is master request + physical slave response (06 - WriteSingleRegister Modbus function, when request and response are always equal). And ModbusTools simulator is simply ignores it because it intended for device with ID:4 (packet with Wrong CRC-error ignored as well but for a different reason).

I don't know how ModbusTools server app can affect the delay because it ignores bad requets or reguests not intended for it.

Maybe it is not software issue?

[zizzbird]

I tried to set the baud rate to 9600 to make sure that the frame interval of the T3.5 is greater than 1ms. And set the Timeout inter-byte to 1ms, but the situation remains the same. Perhaps the physical slave's response is just too fast, which makes it impossible for the software to recognize the frame gap.
I am certain that the high baud rate and slave settings work perfectly fine in other simulation programs.

Your program is excellent, and I would be very grateful if you could provide a better solution!