Slave RTU problem when several slaves on the same serial bus #17
Description
During the development of a project in which I have to communicate several slave devices with a master via a single RS485 bus using the Modbus RTU protocol, I have found that when attempting to read (input registers) different slave devices (with different IDs, obviously) sequentially, I had to introduce a delay between readings, otherwise an error 56 (timeout) occurred. The delay required to prevent this error is much longer than the specifications of the Modbus protocol, preventing the rapid reading of these different slaves.
I have also observed that if consecutive readings are made from the same slave device, it is not necessary to pause (as it should be).
After many hours of testing and debugging, I have verified that the problem lies in ‘RTU Data Unit::Read ADU Packet.vi’. This subVI reads the header of a packet (6 or 3 bytes) from the serial port, which includes the slave ID, and only continues reading the bytes of the packet if it matches the device ID.
If the ID does not match, the rest of the bytes in the packet remain waiting to be read on the bus and are read by the subVI's internal loop as if they were a packet header.
The problem occurs when the packet size is not a multiple of 6 (e.g. 8 bytes, 6+2), then the subVI reads the last bytes of a packet (2 bytes in the example) with the first bytes of the next packet (4 bytes of the header) and does not correctly identify the packet, so it is unable to detect that new header and the second packet, that could have an ID associated with that slave, is lost, and therefore the master never receives the response because the slave does not receive the packet.
When a delay is introduced in the master between readings to different slaves (with distinct IDs), the slave timeout causes the last bytes of the packet with a distinct ID to be discarded, and when the packet with the ID corresponding to the slave arrives, it is detected and decoded correctly.
As a workaround for this issue, I have modified the subVI so that regardless of the ID received, the subVI processes (reads) the entire packet but only terminates when the ID matches that of the slave. In other words, I have extended the internal loop to cover the entire packet processing and not just the header reading.
In the tests carried out, it seems to solve the issue. I will continue testing and if I do not detect any other problems, I will upload the solution in a few days.