I have an RTU program that communicates with 15 devices via MODBUS RS485. After the RTU queries the devices, it receives a response from 12 devices. 3 devices, however, do not send a response back. In a previous revision of the RTU program, a response is received from 14 devices, with 1 (different) device not sending a response back.

The RTU reads 51 holding registers from 15 devices, with a 1 second poll rate per device.
In the previous revision, the RTU read 50 holding registers from 15 devices, with a 1 second poll rate per device.
All the communications configuration is the same for each of the 15 devices, but 3 are not sending a response back.
I have tried decreasing the poll rate, resetting devices, all with no success.

What can I do to get these devices to communicate consistently?

 

Could it be the delay before sending?
In many modbus interfaces you can adjust the time between receiving a message, and sending a response back. Sometimes this is set default to 0, try 10ms for example and see what happens.

It could also be the power driving capability of the driver that drives the current signals on the RS485 interface. There are interfaces that cannot drive enough power when many slaves are connected. A booster can solve this, see the PM485REP repeater on page 123 of the leaflet Promux document, this can solve such problems: https://cascade.net/en/modular-plcs/
It could also be the impedance of the cabling, remember to connect 120ohms between the A and B line at the end of the RS485 interface (last slave). Use proper 120ohm impedance corrected cable, like Lapp Unitronic bus LD cable. Can be ordered per meter at Conrad: https://www.conrad.com/en/p/lapp-21...2-x-0-22-mm-violet-sold-per-metre-600095.html

 

devices, however, do not send a response back. In a previous revision of the RTU program, a response is received from 14 devices, with 1 (different) device not sending a response back.

The RTU reads 51 holding registers from 15 devices, with a 1 second poll rate per device.
In the previous revision, the RTU read 50 holding registers from 15 devices, wit

If the RTU program does not respond when communicating with 15 MODBUS RS485 devices, you can try the following methods to solve the problem:

Check the device address: Make sure that the MODBUS addresses of all devices are unique and there are no conflicts.
Check the line connection: Confirm that the cable connection is good and that the terminal resistor is correctly installed.
Confirm the communication settings: Make sure the baud rate, data bits, stop bits, and parity of the device are consistent with the RTU program.
Increase the timeout period: Extend the device response timeout period to avoid timeout errors.
Check device failure: Verify that the device is working properly and use a test tool to confirm that the device responds.
Roll back the program version: Check if the new program introduces problems and try to test with an older version.
Check the power supply: Make sure the power supply to the device is stable and there is no voltage fluctuation.
Optimize the polling rate: Consider further reducing the polling rate or optimizing the device load.

 

How are you determining that the slaves do not send a response back? Could the slaves instead be sending an exception response?

What is your RTU's timeout time? In other words, how long does it wait for a response from each slave?

Are all 15 devices the same (i.e. same vendor and model)? If not, perhaps these 3 devices have a limit of 50 for the number of registers that can be read in a single request.

 

How are you determining that the slaves do not send a response back? Could the slaves instead be sending an exception response?

What is your RTU's timeout time? In other words, how long does it wait for a response from each slave?

Are all 15 devices the same (i.e. same vendor and model)? If not, perhaps these 3 devices have a limit of 50 for the number of registers that can be read in a single request.

I am determining slaves not sending a response back by monitoring the polls with Wireshark. Successful polls have a query and response, but for those 3 devices, I do not get any response apart from only one [BoundErrorUnreassembled Packet] a few seconds later. Can not find an exception response.

Timeout time is 5000ms with no retries. I have tried with extra retries and still had the same issue.

All 15 devices are the same - Multilin 369 with the same model.

 

If the RTU program does not respond when communicating with 15 MODBUS RS485 devices, you can try the following methods to solve the problem:

Check the device address: Make sure that the MODBUS addresses of all devices are unique and there are no conflicts.
Check the line connection: Confirm that the cable connection is good and that the terminal resistor is correctly installed.
Confirm the communication settings: Make sure the baud rate, data bits, stop bits, and parity of the device are consistent with the RTU program.
Increase the timeout period: Extend the device response timeout period to avoid timeout errors.
Check device failure: Verify that the device is working properly and use a test tool to confirm that the device responds.
Roll back the program version: Check if the new program introduces problems and try to test with an older version.
Check the power supply: Make sure the power supply to the device is stable and there is no voltage fluctuation.
Optimize the polling rate: Consider further reducing the polling rate or optimizing the device load.

All addresses are unique with no conflicts.
Cable connection checked with end-of-line 120ohm resistor and 1nF capacitor in series per GE Multilin manual.
Communication settings all consistent.
Previous revision asks for a read of one less register per device. In this revision, those 3 devices communicate, with one different one not communicating. This additional register is required to be read.
I can poll every device successfully, but the poll only sends a request to read one holding register.
Power supply is OK.

 

Could it be the delay before sending?
In many modbus interfaces you can adjust the time between receiving a message, and sending a response back. Sometimes this is set default to 0, try 10ms for example and see what happens.

It could also be the power driving capability of the driver that drives the current signals on the RS485 interface. There are interfaces that cannot drive enough power when many slaves are connected. A booster can solve this, see the PM485REP repeater on page 123 of the leaflet Promux document, this can solve such problems: https://cascade.net/en/modular-plcs/
It could also be the impedance of the cabling, remember to connect 120ohms between the A and B line at the end of the RS485 interface (last slave). Use proper 120ohm impedance corrected cable, like Lapp Unitronic bus LD cable. Can be ordered per meter at Conrad: https://www.conrad.com/en/p/lapp-21...2-x-0-22-mm-violet-sold-per-metre-600095.html

Tried to add a post & pre-transmission delay of 10ms with no change. I did, however, increase the amount of holding registers read from each device from 51 to 62 (after trying a few different numbers with no success), and the number 62 seemed to have worked, with all devices communicating OK afterwards. I am unsure why this fixed it, but it did...

 

Tried to add a post & pre-transmission delay of 10ms with no change. I did, however, increase the amount of holding registers read from each device from 51 to 62 (after trying a few different numbers with no success), and the number 62 seemed to have worked, with all devices communicating OK afterwards. I am unsure why this fixed it, but it did...

Doesn't surprise me, I once had a device which worked fine if you'd want to read 4 or 6 bytes from it, but failed to work on 5.