Device works in 2400 baud rate & do not work in 9600 baud rate

One of the device i.e UPS Modbus RTU Slave RS485 is working with my device (Modbus Master) on 2400 baudrate serial communication while when UPS baud rate is changed to 9600 , then it do not communicate with my device. All setup remains same, just after baud rate change , device do not communicate .

what should be main factor for such type of issue ?
You need to first ensure that both the UPS Modbus RTU Slave and your device (Modbus Master) have actually been changed from 2400 baud to 9600 baud. Note that some devices require a power cycle for changes to take effect. If one device is currently configured for 9600 baud and the other is still 2400 baud, then of course they will not communicate.

Other causes could be wiring/electrical/noise related. Make sure you're using proper RS-485 cabling (1 twisted pair conductors with another conductor, or pair, for 0V ground reference) and that you have wired the +, -, and 0V ground reference wires correctly to both devices (since you have successful communication at 2400 baud, the + and - must already be wired correctly) . Note that the 0V ground reference is NOT the same as cable shielding. If your cabling is shielded, the shield should be earthed at one end (typically the master side) and taped back on the other end.
Thanks for reply.

Yes Baud rate is changed - becuase the UPS modbus RTU Slave device works well with Modscan Master Simulator tool over 9600 baud & with same setup the slave device is not communicating with My device ( Modbus RTU Master)

I will check for cable shielding etc & use proper cable again for testing.
Meanwhile I got some traces of serial communication between Modscan & UPS Modbus Slave - PFA. Can you comment for timing parameters adjustment?

I think some timing parameter like response timeout / delay/ cycle time needs to be matched in order to communicate with my Master device.

Thanks in advance


Testing the UPS with ModScan is a very good idea. I also recommend testing your Modbus Master device with WinTech's slave simulator tool - ModSim. If you also have the same baud rate issue when using ModSim, the issue is likely with your Modbus Master device.

Regarding your serial communication traces, it appears these were captured with the Eltima Serial Port Monitor software. This software is required to view your attached .spm files, however, this software is not free (only a 14 day demo) and the timestamping in this software only goes down to the second, therefore it is not very useful for millisecond timing purposes. I cannot make any comments on these captures, as they do not provide any meaningful information. On a side note, if you need to attach Modbus captures in the future, please export a TXT version of the Dump view and Modbus view so that no special software is required to view the captures.

Modbus timing parameters certainly could be another cause of communication not working when switching baud rates. However, it is more common to see issues (due to timeouts) when lowering the baud rate, not increasing it. It may be possible that your master is making requests too quickly, such that the slave is not yet ready to receive. This would typically result in every other request timing out, but still receiving valid responses for half of the requests.

I will try to explain the common timing parameters and their effect on communication in detail.

Modbus Master Timing Parameters
Timeout / Response Timeout
This controls how long the master will wait to receive a response from the slave after sending a request. Some masters define receiving a response as receiving the first byte, but most define it as receiving the entire packet. For the latter, the length of the response (i.e. the number of registers requested), as well as the baud rate, will affect the required timeout time. The longer the length and the lower the baud rate, the more time it will take for the packet to be transmitted on the bus, which will require a larger timeout value.

Scan Rate / Poll Delay / Request Delay
This controls how fast the master sends the next request after receiving a response or the request timing out. Poll Delay or Request Delay configures the time the master will wait between each request.

Scan Rate can mean one of two things, depending on the master. It can mean the same as Poll Delay / Request Delay, which is simply the time to wait between each request.

For some masters, though, it controls the request cycle time and is a sort of target value (the master will try to achieve the desired scan rate, but other timing factors such as transmission time and slave response time may prevent this). For example, if the master is configured to make several read requests - Request A, Request B, Request C - the Scan Rate setting controls how often the entire read request cycle executes. It is the time from when a specific request (say, Request A) is made until that same request is made again (i.e. the time from Request A to the next Request A).

Note that masters using this second meaning of Scan Rate may also have a Poll Delay / Request Delay setting to control the minimum time between each individual request. Using the example above, this would be the time between Request A and Request B, between Request B and Request C, etc.

In practice, these settings control how fast each parameter updates. The maximum time for these settings is typically dictated by the update rate required by the overall application. These settings can also be used to throttle communications for certain Modbus slave devices (typically older devices or when using radios/wireless) that are not yet ready to receive a new request immediately after sending a response. Therefore, the Poll Delay / Request Delay setting can be used to add artificial waiting time after a request is received by the master, allowing more time for the slave to become ready to receive.

Modbus Slave Timing Parameters
Timeout / Request Timeout
This sets how long the slave will wait for a request (after having already received a valid request) before declaring a timeout condition. A timeout condition is used to take some sort of fail-safe action internally in the slave. The slave may also have a Timeout Action setting to configure what action is taken on a timeout condition. Slaves that do not support fail-safe actions do not have this setting. On most slave devices that support this setting, timeout processing may be disabled by setting this value to 0.

Response Delay
This controls how long the slave will wait (typically in addition to any processing delays) before sending a response. This is typically only used with older Modbus master devices (or when using radios/wireless) that are not yet ready to receive a response immediately after sending a request. Therefore, usually this setting should be set to 0. Not all slaves have this setting.