For serial, the frame timing is computed from the baud rate and the register counts, including the 3.5 character silence the protocol requires between frames. For Ethernet, give the measured round trip instead.
The controller's scan cycle is counted twice on purpose: once before your read is fresh, and once after your write before it takes effect. Leaving out the second one is the most common way a budget is quietly wrong.
| Term | Time | Share of loop | Share of deadline |
|---|---|---|---|
| Read over the protocol | 32.9 ms | 35.0% | 32.9% |
| Controller scan before the read is fresh | 10.0 ms | 10.6% | 10.0% |
| Preprocessing | 2.00 ms | 2.1% | 2.0% |
| Inference | 12.0 ms | 12.8% | 12.0% |
| Post-processing | 1.00 ms | 1.1% | 1.0% |
| Write back | 26.0 ms | 27.7% | 26.0% |
| Next scan before the write takes effect | 10.0 ms | 10.6% | 10.0% |
| Total | 94.0 ms | 100% | 94.0% |
Modbus RTU protocol time, by baud rate and register count
One read transaction, in milliseconds, before the device has done anything. This is the floor your loop is built on and it is fixed by the wire, not by your code. Add your device's processing time, which is typically 2 to 50 ms, and then everything above.
| Registers read | 9,600 baud | 19,200 baud | 38,400 baud | 57,600 baud | 115,200 baud |
|---|---|---|---|---|---|
| 1 | 25.2 ms | 12.6 ms | 6.30 ms | 4.20 ms | 2.10 ms |
| 5 | 34.4 ms | 17.2 ms | 8.59 ms | 5.73 ms | 2.86 ms |
| 10 | 45.8 ms | 22.9 ms | 11.5 ms | 7.64 ms | 3.82 ms |
| 20 | 68.8 ms | 34.4 ms | 17.2 ms | 11.5 ms | 5.73 ms |
| 50 | 138 ms | 68.8 ms | 34.4 ms | 22.9 ms | 11.5 ms |
| 100 | 252 ms | 126 ms | 63.0 ms | 42.0 ms | 21.0 ms |
Function code 03, one master, no contention. Request 8 bytes, response 5 + 2N bytes, 3.5 character silence before each frame, 11 bits per character. Amber is over 20 ms, red is over 50 ms, because past those a 100 ms loop has already spent a fifth or a half of its budget on the wire.
A worked example
A vision system on a 100 ms loop, reading 10 registers over Modbus RTU at 19200 baud from a controller with a 10 ms scan cycle and 10 ms of device processing. Inference measures 12 ms on the target hardware, which the team reports as comfortably inside budget.
The read is 32.9 ms: 22.9 ms on the wire plus the device's 10 ms. The scan cycle before that read is fresh is 10 ms. Preprocessing is 2 ms, inference 12 ms, post-processing 1 ms. The write back is 26 ms, and the next scan before it takes effect is another 10 ms. That totals 94 ms against a 100 ms deadline. It closes, with 6 ms to spare, and it passes on the bench every time.
Then the line runs other masters on the same link at 30 percent utilisation. The protocol terms are 59 ms of that 94, and they are the ones that queue, so they stretch by about 1.4x and the loop goes to 119 ms. It now misses, intermittently, under load. A 1.5x jitter allowance puts the worst case at 179 ms. The trace shows inference at 12 ms every single time.
The actionable number is the inference budget: 18 ms nominal, and negative at worst case. Inference is 13 percent of the loop and the protocol terms are 63 percent, so no amount of model optimisation reaches this. The cheapest fixes are fewer registers per cycle, a faster baud rate, or taking the other masters off the link, and not one of them is a machine learning decision.
The arithmetic, so you can check it
Modbus RTU frames one character as 11 bits: a start bit, eight data bits, a parity bit and a stop bit. So a character takes 11 / baud seconds, and the protocol requires 3.5 character times of silence before each frame. A read of N holding registers is an 8-byte request and a 5 + 2N byte response.
Contention is modelled as a queueing stretch of 1 / (1 - utilisation), applied to the protocol terms only, since those are the ones that share the link. It is a crude model and it is the right shape: the cost of contention is flat until it is not, and the knee arrives sooner than people expect.
This is a budget, not a measurement. Real controllers do not implement the standard uniformly: register maps differ from documentation, word ordering varies between vendors, and behaviour on a malformed request ranges from a clean exception to a device that needs power-cycling. Treat the device as the specification, put a passive tap on the link, and record what actually happens. The number here tells you whether the design can work; only the tap tells you whether it does.
The reasoning behind every term is in PLC to model: where industrial AI actually breaks, and the same structure applied to a robot in perception to control.
Questions
Seven terms, not one: the protocol read, the controller scan cycle before that read is fresh, preprocessing, inference, post-processing, the write back, and the controller's next scan before the write takes effect. Contention from other masters on the link stretches the protocol terms on top of that. Inference is usually the smallest of the seven and the only one anybody measures.
A character is 11 bits, so at 19200 baud one character is 0.573 ms. A read of 10 holding registers is an 8-byte request and a 25-byte response, with a 3.5 character silence before each frame, giving 22.9 ms of protocol time before the device has done anything. At 9600 baud the same read is 45.8 ms. Add the device's own processing, typically 2 to 50 ms, on top.
Once before your read, because a value is only as fresh as the last scan that wrote it, and once after your write, because the output does not take effect until the next scan. Leaving out the second one is the most common reason a budget that looked fine on paper misses in the field.
Almost always contention. The protocol terms queue behind other masters on the same link, so they stretch under load while inference does not. A loop that closes with a quiet bus and misses with a busy one is the signature, and it is invisible in any measurement taken on a test rig with one master.
Because inference is one of seven terms. Teams measure the term they own, find it comfortably inside budget, and never add up the other six. The useful number is the inference budget: the deadline minus everything else, which is what this calculator returns.
The structure does. Switch the transport to Ethernet and supply your measured round trip instead of a baud rate; every other term is unchanged. The serial mode computes frame timing from first principles because that is where the arithmetic is least obvious.