Modbus RTU - RS485 - Polling Question

[kurt.brinker]

I am trying to figure out some communication specifics for a Modbus RTU network that I will be integrating with and could use some help to make sure I am on the right track.

The networks are 2-wire RS485, 19200bps, 8N1.
Each network will accommodate up to 16 slave devices. (Identical units)


I will be using function code 3 to poll for a block of 11 registers from each unit.


I am trying to determine what my actual update rate will be after all nodes are scanned.


In this thread the mighty Ken Roach wrote a reply which is nearly identical to my current request.

The two most time-consuming steps are usually the time it takes for the Slave devices to answer, and the inter-request delay by the Master device.

The actual wire time of the data is straightforward to determine. With ordinary 8/N/1 framing, each byte is encoded in 10 bits.

A Modbus RTU read of 10 registers using Function Code 0x03 will have an 8-byte Poll and a 25 byte Reply.

At 19200 bits per second, 32 bytes = 320 bits/19200 = 16.7 milliseconds.

So the wiretime is not the biggest factor.

If you do any serial analysis work, even with an easy-to-interpret protocol like Modbus RTU, I strongly recommend you get your hands on a Stratus Engineering serial tap. There's nothing quite as powerful as getting the data right off the wire, so you don't have to predict, infer, or guess what each device is doing.

Just so i understand, is the 8 byte address based on the following message frame?
Slave Address|Function Code|First Address and Register Count|CRC
1+1+2+2+2


The reply is based on
Slave Address|Function Code|Byte Count|10x2(n*byte count)|CRC

1+1+1+20+2


Assuming that is the case...

A Modbus RTU read of 11 registers using Function Code 0x03 will have an 8-byte Poll and a 27 byte Reply.

At 19200 bits per second, 35 bytes = 350 bits/19200 = 18.2 milliseconds.



I am thinking i also need to include the required 3.5 character inter-frame delay which would bring me up to around 21.7ms

Now, I know that is just the wire time and does not reflect the time it take the slave to reply or other factors I am not considering, however, given that scanning 16 devices per second gives me 62.5ms per device. Is it reasonable to expect that I could receive a full network update each second?

 

[Steve Bailey]

I don't think I've ever been able to do better than four or five Modbus transactions per second consistently and reliably.
If your Modbus slaves have nothing else to do but respond to requests from the Modbus master you might be able to better that, but if the slave devices have other tasks (like executing a PLC program) you're probably asking for too much. I think sixteen transactions per second is way too optimistic.

 

[Mark-]

Is it reasonable to expect that I could receive a full network update each second?

Can the master device poll fast enough? Some devices do not like (can not switch fast enough) fast transitions from receive to send and vice versa.

Can the slaves actually turn around and respond in X milliseconds?
What happens, time wise, when a device does not respond in X time?
How long will the master wait for a reply?
Is it possible for one device to go offline and the balance of the process keep running?

Can the 16 devices be split into 2 485 loops?

Or are you only talking a theoretical possibility?

 

[Peter Nachtwey]

Why Modbus RTU?
If you have control of the master and slaves then you can use any protocol you want.


I hate Modbus RTU with a passion because there are always incompatibilities between devices unless the code is written by the same company or user.


A question I have is can the master and slaves send packets without having a gap of 1.5 characters? A common problem is the gaps between characters occur because the PLC or device has the interrupts or serial port off during "house keeping". A common "cure" is to allow gaps of 2 or more characters but this slows down the transmissions/recovery times.


The slaves must be able to put the output part of the serial interface in a tri state mode and enable it only when transmitting. If the slave get hung up it might keep is transmitting interface on and interfere with the next transmission. This output buffer is usually controlled by the RTS pin of the serial port.


Since a two wire RS-485 is being use. All slaves must listen to what the master sends on the line even if the traffic is not meant for that slave.
This wastes a lot of time on the slave that weren't the destination.


What happens if the master is sending a packet to slave 1 but slave 2 somehow gets it wrong? What will slave 2 do? It should do nothing because it should speak unless spoken to.


I have found that few devices implement the Modbus RTU protocol correctly. In my case I could use DMA so a packet would be sent out without fear that interrupts could be turned off and cause a gap between characters.


I preferred the Rockwell DF1 packets when I had control of the master and the slaves. DF1 has a packet start and stop character and are not timing dependent.

 

[Lare]

Schneider have listed polling times on their old serial manual.

As modbus is invented by Modicon / Scheider on 70's this should be accurate for also others.



https://damrexelprod.blob.core.windows.net/medias/c96d78f7-e2cc-47d6-8d7e-f0376c13d1f9
page 190


(Scheider Premium and Atrium Using Unity Pro
Asynchronous Serial Link User Manual 35006178 04/2015)

100 words

baud    scan  read_time 



19200  cyclic  215-228ms

19200  10ms     216-239ms

19200  50ms     251-280ms

This probably don't take account that there needs be gap between different slaves.

I assume that it is only one read to one slave not continuous.



3-5 different slaves / second is best as Steve allready mentioned.





Polling time depends little bit also if you are using which PLC manufacturer or read directly to Scada.




Some PLC have modbus possible only on main program (main scan affects), some can have faster program interrupts for communications.



As there needs to be gap between different slaves this can make slight difference on different PLC.


If you have PLC whit 50ms scan time, then gap between different slaves is 50ms on program side. (Hardware can have own communication processor, but code execution is slower on PLC)





If you have PLC whit 50ms scan time and communication can be on interrupts then you can have gap smaller than on other PLC.


Usually this isn't problem and you don't need even think if communicatios is coded to main program or to faster interrupts.
From manual we can seee that 10ms and 50ms scan time change have also 40ms slower read to 100 words on Schneider.

 

[lfe]

I assume that your master is a PLC, which does not normally have an exclusive CPU for serial communications.

Often communications are only processed once per scan or a request is sent or a response is received and therefore the speed will also depend on the scan time and it will be much lower than what you propose.

 

[Lare]

I assume that your master is a PLC, which does not normally have an exclusive CPU for serial communications.

Often communications are only processed once per scan or a request is sent or a response is received and therefore the speed will also depend on the scan time and it will be much lower than what you propose.

Exatcly. On code side 1st scan time sends, 2 or scan times after that gets reply from slave, then you need also gap between slave.



1st = send, 2nd=reply from slave processing, 3rd=gap, 4th=send, 5th=reply from slave processing, 6th=gap



This if PLC have slow scan time. On faster scan times this is still same principle.

On which scan time PLC code gets reply can't be on same scan than sending modbus request on asyncronous communication.

 

[Puddle]

I don't think I've ever been able to do better than four or five Modbus transactions per second consistently and reliably.

I have a Siemens S7-1211 which exists almost exclusively to gather data from 41 temperature controllers through two communication loops, split into 20 and 21 instruments on each loop at 38400bps baud. It sends two read requests to each on in sequence and takes about 1.5 seconds to go through that sequence to gather 40/42 registers. Now you’ve said that, I’m wondering if I’ve made an error with the timer than displays the execution time. The response time is pretty good though, one of the values can be written through the HMI and it doesn’t seem far off.

 

[kurt.brinker]

Thanks for all the great replies!!


I should have provided more information up front, i'll do that now.

A 1 second network scan time is not required, I was really just trying to set expectations on the front end. If I have an idea on what to expect, it will hopefully prevent needless troubleshooting later on.

Background info:

These networks have been in service for right at 20 years. The sensors are daisy-chained and the networks are spread out so that each network has a sensor operating at every level of the facility. This was done so that we would not lose coverage if a single network failed.
To change this and split up the networks is technically possible but we would be looking at some major cable pulls to bring new networks online.
A different protocol or sensor is effectively out of the question since 50 of the sensors were replaced in past year to maintain compatibility with the old system. The overall cost to replace just the sensors was north of $350K so i expect we will stick with these and just migrate the networks over to the new serial hardware. The master will be an Emerson M series serial card.


@Mark
The master serial card is programmable with a retry count and timeout.
This will be set initially to 1 retry and a 100ms timeout, allowing the card to continue polling the other slaves. We will also receive an informational log entry if a poll fails.


@Peter
The slave networks are already established and they only support Modbus RTU. (well, that and 4-20) If we were designing from scratch, this setup wouldn't even be considered.
I am running sample hardware in a lab environment right now and thankfully the setup was simple. (I too have battled Modbus integrations before)
Concerning the 1.5 character gap, neither the master or slave is programmable to tolerate an increase in gap. As far as i know, they adhere strictly to the spec of 1.5
The serial card has two dedicated com ports and the slaves aren't executing any customer logic. Fairly basic devices

I am running a test right now with BaseBlock Com Test Pro and a single sensor. Even with windows, a software forced 5ms delay, and a 232-485 converter in the mix, i am still getting 11-12 transactions a second when requesting 11 holding registers. This at least lets me know the slaves have a snappy response.


I think the general consensus is not to get my hopes up.

I'll keep testing and get a couple versa taps on order.


Thanks again for all the replies and thought-provoking information.

 

[lfe]

In the past I set up dozens of installations with Mitsubishi FX reading temperatures, valve positions, pressures etc. through serial port from Advantech ADAM modules, up to 30 channels read one by one at 9600 baud.

In the program I put counters to know how many readings per minute but unfortunately I don't remember how many they were, but they were read faster than once every 3 seconds, which was how often the regulation was executed.

I think that every 1.5 seconds or so they are all read.

There was very little improvement in increasing the speed to 19200, the main delay was caused by the scan time.