RS485 timing considerations

V

Thread Starter

Vijay Deshmukh

Can anybody tell me the timing considerations of RS485 network with Modbus Protocol. I have about 47 devices connected over the serial network of Modbus (using RS485). If a master initiates a broadcast command to all its slaves, how much time will it take for master to read the data of all slaves? Each slave is going to transmit 4 words of data.
 
R

Rob Hulsebos Philips CFT

>Can anybody tell me the timing considerations of RS485 network
>with Modbus Protocol. I have about 47 devices connected over the
>serial network of Modbus (using RS485). If a master initiates a
>broadcast command to all its slaves, how much time will it take for
>master to read the data of all slaves? Each slave is going to
>transmit 4 words of data.

Broadcasts don't make sense for read-commands, since no answer is sent back.

And note that support for broadcasts is not always implemented in every device-type.

Greetings,
Rob Hulsebos
 
D

Darold Woodward

There are broadcast messages in Modbus, but I have yet to see a slave device that supports them. The reason is that Modbus does not have any kind of collision avoidance or resolution. Your devices may have something, but you're
going to have a potential problem.

In order to get the timing, look at your channel speed and the lengths of the messages. All of the information necessary for this is contained in the Modbus specs on www.modicon.com What you will find if you really look closely though is that the "wakeup and respond" time for your slave devices dominates if your channel is fast. If your channel is very slow ( <9600 bps) then the channel speed may dominate. In your situation, you will have as many bytes on the wire from overhead (message header & CRC) than data.

Each response will probably contain the following: aa ff 08 d1 d2 d3 d4 d5 d6
d7 d8 cc cc
aa - slave addr
ff - function code
08 - data byte count
d1 - d8 - data bytes
cc - crc bytes

At 9600 bps where 1 character is 1ms, the response is 13 ms. If you assume 50 ms of "dead air" on the line between messages, then you have 63 ms X 47 = 2.961 seconds. Adding some time for the initial request, I'd say you'd be lucky to
see 3 seconds for an update time. However, unless the slaves have some collision detection or collision avoidance backoff or other algorithm built in, you won't get this or it may be worse depending on that algorithm,

Typical polling of each slave device would go more like:

8 characters data request from master
100 ms wakeup & respond time
13 ms response
50 ms until next request

This adds up to 171 ms x 47 = 8.037 seconds. You can increase the channel speed all you want, but even if it is infinite, the wakeup & respond time is the most sigificant piece and unless you understand it for your unique devices, you won't
be able to understand timing.

Darold Woodward PE
SEL Inc.
[email protected]
 
S

Steven E. Braun

A broadcast command is defined by the Modbus specification as a Master request to node address 0. It is only valid for some functions such as
functions 5,6,15, and 16. By definition, there is NO response expected or even required by the Slave. Within the standard Modbus specification, there is NO provision for line contention. This would be required if Modbus Slaves were to respond either unsolicited or simultaneously.

Currently, my company has been doing some throughput testing of a PLC system with a standard Modbus Master and a Modbus Slave. We are working with a public electric utility. Testing consists of identifying an input, sending a Modbus command 15 (set multiple coils), waiting at least 50 mS to ensure the remote breaker trips, sending a Modbus command 1 (read output coils), and finally evaluating the logic to see if the remote coils were set.

The overall average performance of this particular Modbus Master/Slave/PLC combination is about 155 mS. The baud rate is 9600. The contents of the write consist of one 16 bit register and the contents of the read consist of one 16 bit register.

Doubling or even tripling this baud rate is not going to significantly improve the performance. This is a point to point connection. On a
multipoint connection, we would issue a broadcast write command and then issue a read command to each node in order to evaluate the output bits.

The timing considerations for a multipoint write and individual read would be :

Send a command 15 broadcast - 15mS
Delay time for first node only - 50mS
Total - 65mS

Send a command 1 to each node - 15mS
Overall Slave response - 35mS
Master turnaround - 50mS
Total - 100mS

47 devices times 100 mS each plus the 65 mS broadcast equals approximately 4.8 or about 5 seconds depending on the asynchronous nature of the PLC scan time.

This is an exceptionally good response (IMHO) and I normally do not expect this type of response from the vast majority of the systems that we test.

BTW: The 155 mS of the point to point response was not acceptable to the client and 47 devices on a Modbus network is probably going to need a RS-485 booster unless the Slaves are 1/4 or 1/2 unit loads.

Steven E. Braun
SEBraun, Inc.
1126 Sudden Valley
Bellingham, WA 98226
Office 360.734.4817
FAX 360.647.0910
[email protected]
 
Top