Every digital controller runs its PID math on a fixed clock, recomputing the output once per execution interval rather than continuously. That interval is the sample time, and it quietly shapes how the loop behaves. Choose it well and the discrete controller acts almost exactly like the textbook continuous one; choose it too slow and you inject dead time, starve the derivative term, and can push a stable design into oscillation.
PID sample time in one line: The sample-time effect is the change in a PID loop's behavior caused by executing the control algorithm at a fixed interval instead of continuously. A too-slow sample time adds effective dead time, coarsens the derivative calculation, and reduces stability, so the interval must be chosen relative to the speed of the process being controlled.
A classical PID is written in continuous time: it integrates error and differentiates the measurement instant by instant. A PLC or flow computer cannot do that. Instead it wakes up on a timer, reads the current process variable, computes a fresh output, writes it, and sleeps until the next tick. The gap between ticks is the sample time, sometimes called the execution interval, loop update time, or scan rate for that task. Between updates the output is held constant, so the real actuator sees a staircase of held values rather than a smooth signal.
This discretization is usually invisible when the interval is short compared with how fast the process moves. A temperature loop on a large vessel that responds over many minutes barely notices whether it updates every 100 milliseconds or every second. The trouble starts when the sample time grows large relative to the process time constant and dead time. Then the held output and the delayed correction become a meaningful part of the loop dynamics, and the controller you tuned on paper is no longer the controller that is actually running.
It helps to picture the sample time as a delay you are adding on purpose. On average the controller reacts half a sample period after a disturbance arrives, because it does not see the change until its next scheduled read. That average half-interval behaves like extra dead time stacked on top of whatever transport and measurement lag the process already has, and dead time is the single hardest thing for any feedback loop to cope with.
Two mechanisms make a slow sample time dangerous. The first is the added effective dead time just described: roughly half a sample interval of extra delay, which erodes phase margin and makes the loop more prone to oscillate as you push gain up. The second is the derivative term. Derivative action estimates the rate of change of the measurement by dividing the change since the last scan by the sample time. When the interval is long, that estimate is coarse and noisy, so the derivative can lurch, amplify measurement noise between reads, and kick the output around rather than smoothly anticipating the trend it is meant to predict.
Integral action is more forgiving but not immune. Because the controller accumulates error only at each tick, a very slow update can let error build up between reads and then apply a large correction all at once, encouraging overshoot. If the sample time is not stable - if the task sometimes runs late because the CPU is busy - the effective integral and derivative gains wobble from scan to scan, which shows up as erratic, hard-to-reproduce behavior that no amount of retuning fully cures.
The classic symptom of a sample time that is too slow is a loop that oscillates or hunts even though its gains look conservative, with the oscillation period roughly a small multiple of the update interval, and a derivative term that makes things worse instead of better. Likely causes include an execution task set far slower than the process needs, a controller sharing a slow scan with hundreds of other blocks, or a task that is being preempted and running at an irregular rate. Diagnose it by first checking the configured execution interval against the process response time, then trending the actual update timestamps to confirm the interval is steady, and finally testing whether shortening the interval or disabling derivative calms the loop.
The practical rule of thumb ties the sample time to the process dynamics rather than to what feels fast. A common guideline is to execute the loop somewhere between about ten and twenty times faster than the dominant closed-loop response you want, or equivalently to keep the sample interval to a small fraction of the process time constant plus dead time. Fast pressure and flow loops may need to run several times per second; slow temperature and level loops are perfectly happy running once a second or slower. Faster is not automatically better either, because an unnecessarily short interval wastes CPU and can amplify high-frequency measurement noise into the derivative term.
Aliasing is the subtler trap. Sampling a signal that contains fast fluctuations at too slow a rate can make those fluctuations masquerade as a slow trend that is not really there, and the controller will chase the phantom. Anti-aliasing - filtering the measurement before it reaches the sampler, or simply sampling fast enough to resolve the real dynamics - keeps the discrete controller honest. This is why measurement filtering and sample time have to be chosen together rather than in isolation.
In a cloud SCADA context the sample time that matters is the one inside the field controller, not the reporting interval at which the SCADA polls that controller. The PID executes on the PLC or flow computer clock, and Merobix reads the resulting output, setpoint, and process variable for trending and alarming at its own, usually slower, cadence. Keeping those two concepts separate is important: a loop can update ten times a second in the field while the dashboard trends it once a second, and that is fine. Where cloud monitoring earns its keep is in catching sample-time problems after the fact, by trending a loop that hunts with a period tied to its execution rate, or by flagging a controller whose actual update timing has become irregular, so an engineer can look at the task configuration before the instability gets worse.
A widely used rule is to run the loop roughly ten to twenty times faster than the closed-loop response you are targeting, which keeps the sample interval to a small fraction of the process time constant plus dead time. Fast flow and pressure loops often need several updates per second, while slow temperature and level loops run happily once a second or slower. The goal is to make the discrete controller behave like a continuous one, not to sample as fast as physically possible.
Because the controller only reads the measurement at each scheduled tick, a disturbance that arrives between ticks is not seen until the next read, on average about half a sample interval later. That built-in delay behaves like extra dead time stacked on the process, and dead time reduces phase margin and makes the loop harder to stabilize. The longer the interval, the more dead time you add.
No. The PID sample time is the execution interval inside the field controller, where the loop math actually runs, while the SCADA polling or reporting rate is how often the monitoring system reads values from that controller. The loop can execute many times per second in the field while the dashboard trends it far less often, and confusing the two leads people to blame the wrong thing when a loop misbehaves.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.