Computing Library › Real Time Systems
Real Time Systems

Control-Loop Timing

A control loop must sense, compute, and actuate within its period every cycle; the choice of period couples timing engineering to control theory.

The Loop as a Clocked Contract

A digital control loop repeats a fixed sequence at a fixed rate: read sensors, compute the control law, and drive actuators. The loop period sets both the timing requirement for the software and the achievable dynamics of the controlled system. Choosing it well means balancing what the physics needs against what the computer can guarantee.

Choosing the Period

Kronos motion — cycle loop

The period must be short enough to observe the plant's fastest relevant dynamics. A common guideline places the sampling rate at ten to thirty times the closed-loop bandwidth you intend to achieve. Sample too slowly and the controller is blind between updates; sample too fast and you spend computing budget and amplify sensor noise without benefit. The Nyquist limit is a floor, not a target: you generally sample well above twice the highest frequency of interest.

Sensor-to-Actuator Delay Within a Cycle

Where in the period the computation happens matters. If you sample at the start of the period and output at the end, you add nearly a full period of delay. Many designs sample, compute quickly, and output as early as possible to minimize the delay from measurement to action, because that delay directly reduces phase margin.

Timing the Loop in Practice

Overruns

An overrun occurs when a cycle's work does not finish before the next cycle should start. A robust loop detects this and responds by a defined policy: skip, hold the previous output, or trip a fault. Silent overruns cause the loop period to stretch unpredictably, which introduces both delay and jitter and can destabilize an otherwise sound controller. Timing budgets and worst-case analysis exist precisely to prove that overruns cannot occur under normal operation.