Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
multiple slaves with RTU communication #18
I've got a problem with RTU communication.
The problem is, that when a master starts a "modbus_read_input_registers" communication. The starting message arrives for both of the slave. The one, which is addressed acknowledges the message, creates the reply and sends it back. The other one, with different salve id, receives the first message, it sees that he is not the one who is addressed, so does nothing.
But when it receives the reply of the first slave, it reports an error, because of the wrong CRC. The problem is that, the reply is a longer message, and the second slave doesent see that, and checks the CRC from false part of the reply message.
How should I handle this situation?
Thanks in advance,
I thought I will let you know, how I have solved this problem.
Instead of reading out a register, I'm reading out coils. If I want to be specific, then 24 bits. Because in this case all the messages have the same size.
In my case, because I try to read out two int-s, with one message, this means that each of the integers is 12 bit long, so the biggest number is 2047.
I have the same problem as artopta. The reply from the first slave will be seen as a new request in the other slaves. The receivefilter as I can see is made for real requests not replies. I made some debugs today and I can reproduce the problem. I don't really know how to solve this but maybeI can see two ways 1) enhance the filter but how to know when it's an reply 2) start with the adresscontrol and do the best as possible with the filter.
Opening COM8 at 9600 bauds (N, 8, 1)
The correct answer is: 01 03 04 00 1D 00 30 6A 21 with dec value 29 and 48
The first answer in the logfile is from libmodbus slave itself and the second with address 1 is a controller.
Any idea how to solve this
libmodbus isn't time based so it doesn't wait for a fixed period to analyze request.
I think about some ideas to fix this issue but I'm not sure about the best solution.
It's certainly possible to mix the 2 solutions to achieve more robust management.