Deterministic Modbus

You can calculate the number of bytes to transfer over Modbus for your application. And you know the baudrate and Modbus idle time. Thus you can calculate the theoretical transfer time.

This transfer time could grow, if your computer would not be able to deliver the bytes quick enough (under every load). So the answer depends on your computer. A modern computer should be able to deliver a byte stream without delays. For this, your Modbus driver could run on a high priority.
Yes. There is maybe some doubt because some Modbus solutions/implementations are loose, or some masters are based on non-deterministic OSs. Just considering a standard serial Modbus implementation in a good network configuration, its so deterministic as any master-slave media access control.

This is refering to a PLC-network, not a PC-PLCs network.
With this scheme, its possible be sure all IO will be scanned in a perfectly periodic and known time, or how much time it will take to recover from a defective comunication.

In short: Modbus standard is deterministic, but many implementations are not. The problem is the interface with the OS (even some RTOSs) and hardware. Same question (and some answer): CAN is deterministic? Profibus?...

Replies are welcome.
Best regards,
Yes, but you would have to calculate and test for repeatability. Modbus messaging is master/slave - query/response (there is no "token" involved that would guarantee device access times) and you would have to consider items such as:
1. The processing time of the sending (master) device. How fast can it compose and often can it send the message? In a PLC this is usually 1 scan.
2. The transmission time, which is affected by the baud rate, the number of characters in the message and the number of bits per character.
3. The CRC or LRC calcuation time
4. The network propagation time. How long a distance?
5. The time for the slave device to process the message and respond (worst case). In a PLC the worst case is usually 2 scans.
6. Time for the master to process the response.

Event.. master device composes and sends message
Delay.. message sent to slave device
Delay.. slave device receives message and formats response
Delay.. response sent to master device
Delay.. master device processes response

You will get a max query/response time that will be the same for each similar event and thus deterministic.
Generically, any serial communication that provides an error reply in the case of lost message/incorrect request can be viewed as deterministic. It all depends on the type of resolution you need in terms of sampling. How often do you need to see data to consider it a continous time line?

Modbus over Ethernet via TCP/IP is utilized routinely for Control Networks. It is NOT deterministic by definition, but if designed correctly in terms of network and its parameters, can perform as if it were...

The question really comes down to HOW OFTEN DO YOU NEED TO SEE NEW DATA??? As an example, a 300 Baud serial connection is deterministic, but it may take too long for you to receive that data back after a request to make it worthwhile for your purposes. This can be true even though you can precisely measure and routinely know its roundtrip arrival time.
Please don't confuse Mr. Roberts. Others have correctly assured him that Modbus is deterministic since it operates in master-slave mode. Modbus TCP when using full duplex switched Ethernet is also deterministic. Determinism means that there are no uncertain delays in network transmission. The old collision domain Ethernet protocol used statistical setback as the resolution to collisions
on the network, but full duplex switched Ethernet has NO collisions and is deterministic.

You are addressing a different property - repeatability or jitter. Controls in which timing errors can be a disaster require time synchronization that is something else. To get accurate time synchronization, you must use a scheduler that is real-time clock dependent like the Link Active Scheduler of Foundation Fieldbus. PCs can also achieve accurate time synchronization as long as you don't need it to less than about 100 ms. PLCs can only achieve accurate time synchronization if you use a clock function for scheduling. Normal logic processing can have too much jitter for accurate scheduling on a PLC.

Dick Caro
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Buy my books:
Automation Network Selection
Wireless Networks for Industrial Automation
The Consumer's Guide to Fieldbus Network Equipment
for Process Control
By the way, I would dare to say: it is better than deterministic: it is SO simple, that the user and the costs are deterministic either... :)


Vladimir E. Zyubin

Hello automation,

Errors (that lead to a delay) depends on the baud rate and the length of the wires, etc... (it is not collisions issue only)... ;-)

And it seems to me question is not in a definition of the word "deterministic", but in the protocol behavior.

Best regards.
= Vladimir E. Zyubin