Modbus RTU EuroAir 250

Hi, I'm trying to read the Modbus protocol via RTU from a ventilation system but the bus response with checksum error.
Can it be that the protocol does not correspond to the standard?

Modbus RTU
Communication Settings:
9600 baud
8 data bits
No parity
1 stop bit

Supported Functions:
Request:
Byte 0 : FC = 0x3
Byte 1-2: Address
Byte 3-4 : Number

Response:
Byte 0 : FC = 0x3
Byte 1 : Number of bytes
Byte 2-n: Values

Exceptions:
Byte 0 : FC = 0x83
Byte 1 : 0x02 (Illegal adres)

With which software could this dialect be read out? The aim would be to process it with codesys.

Thx!
 

Attachments

A checksum error could be caused by incorrect wiring or incorrect communication settings.

How do you have the devices wired together? Keep in mind that notations such as "A" and "B" are not standardized amongst vendors, so you may need to swap your A and B connections at one device. If the terminals are labeled with + and -, then connect + to + and - to -. Are you using a 3rd wire for common-mode (0V) reference?

Confirm that your master device is configured for the correct communication settings. From your attachment, it appears the Modbus slave device uses 9600 8N1.

Also make sure you are accessing the correct register numbers. Since the documentation you've attached has register number 0, that means it's using 0-based addressing. You may need to add 1 to the register number, or perhaps add 40,001 if your Modbus master expects 5-digit reference notation.

I recommend trying to communicate to the slave device using a computer, USB to RS-485 adapter, and Modbus master software such as ModScan, Simply Modbus, Modbus Poll, etc.
 
Thank you for the detailed description and suggestions!

Today I tried to read the Registers with the modbustool.
Unfortunately, it was still not possible to read registers, not even when swapping polarity A, B with the error message Checksum error.

Do you think it is a standard modbus or has the protocol been migrated? According to the documentation, the byte order is function, ID, etc.. different from normal, right?
 

Attachments

This is almost assuredly not an issue with this device not implementing Modbus correctly. The device does seem to use standard Modbus. The confusion probably comes from the fact that this vendor's documentation only shows the Modbus PDU instead of the entire ADU (refer to page 3 of the spec here: https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf). The "Address" field in the below is the Register Address. The Slave Address is not shown in this vendor's documentation.
Request:
Byte 0 : FC = 0x3
Byte 1-2: Address
Byte 3-4 : Number


Looking at your Modbus Poll captures, there appear to be master requests for function code 06 (Write Single Register) being received by Modbus Poll.

Here is what Modbus Poll sends:
Read Holding Registers 1 - 10 (01 03 00 00 00 0A C5 CD)

And it is receiving several of the following packets all in a row:
Write Single Register 2, Value = 1 (01 06 00 01 00 01 19 CA)

So either you have another master device already connected to the EuroAir device, or the EuroAir device itself is configured as a master instead of a slave.
 
Thanks again, it works as a slave.
Please clarify. Did you reconfigure the EuroAir device from being a master to a slave and now everything is working as expected or are you simply saying that the EuroAir device is a slave?

Are there any other devices or equipment connected to this RS-485 network?
 
I would be happy to clarify.

The topology and the connection terminals can be seen on figures 9 and 13 of the operating instructions.

The web controller port does not work with Modbus. The room control unit is apparently a slave participant and the ventilation system is the Modbus master. When the room control unit is disconnected, the Modbustool can display the register as a slave.
 

Attachments

OK, am I understanding correctly that you've resolved your issue then? The problem was that you had two masters connected to the RS-485 bus at the same time. When you disconnect the other master, Modbus Poll can successfully communicate to the slave device. Is this correct?
 
Top