What This Page Covers (and What It Doesn’t)

An Edge PID / Loop Controller is the last-mile controller that closes a physical loop locally with deterministic timing. It combines precision ADC/DAC, a low-jitter time base, and robust safety supervision (watchdog + hold-up + safe outputs), plus a local HMI for commissioning, diagnostics, and recovery.

• What readers should be able to design after this page

  A loop-controller architecture that remains stable, low-noise, and deterministic under real scheduling, conversion delay, and output non-idealities.

• What readers should be able to budget and verify

  End-to-end latency + jitter from sensor → ADC → compute → DAC/PWM → actuator, with measurable timing checkpoints and acceptance limits tied to loop bandwidth and stability margins.

• What readers should be able to harden for field reality

  Fail-safe behavior that survives brownouts and software faults: watchdog policy, hold-up behavior, deterministic safe outputs, and post-fault evidence (reason codes + event logs).

System Architecture Blueprint (Signal, Time, Safety)

This blueprint decomposes an edge loop controller into three planes that must align: Signal (what is measured/commanded), Time (when sampling and actuation happen), and Safety (what happens when power or software becomes untrustworthy). The goal is a design that can be mapped to hardware and firmware in minutes, and verified using measurable checkpoints.

• Signal plane (sensor → compute → actuator)

  Sensor front-end and anti-aliasing define in-band noise and phase. ADC conversion + digital filtering define group delay. Output DAC/PWM defines settling, update boundary, and safe clamps.

• Time plane (low-jitter clock → schedule → timestamp)

  A low-jitter time base and deterministic schedule define sampling instant, compute window, and output update instant. Timestamping turns timing into evidence and enables repeatable debugging.

• Safety plane (watchdog + brownout + hold-up + safe outputs)

  Supervision must define safe output values and transitions under faults. Hold-up time is budgeted to preserve safe actuation and capture reason codes and last-gasp logs during brownouts.

Deliverable checklist: For every block below, pin down (1) a spec that matters for loop stability or safety, (2) how it is measured, and (3) the failure signature that will appear in logs or waveforms when it is wrong.

Deterministic Timing Model (Latency + Jitter Budget)

Many field issues that look like “bad tuning” are actually time-domain failures: sampling instants drift, compute deadlines slip, or outputs update at inconsistent moments. A deterministic timing model converts the full loop path into a budget that can be measured, validated, and enforced.

Budget fields to compute (must-have)

Precision ADC Design for Control Loops (Accuracy vs Speed vs Noise)

ADC selection defines what can be measured in the loop bandwidth that matters. The key trade is not only resolution versus sample rate, but also in-band noise, group delay, and drift—all of which directly shape stability margins and steady-state performance.

• Input conditioning: anti-alias corner vs loop bandwidth

  Anti-alias filtering must suppress out-of-band noise while keeping phase loss small near crossover. Every filter adds phase and must be included in the H2-3 timing budget.

• Reference strategy: external vs ratiometric

  Reference noise appears as measurement noise; reference drift appears as slow PV bias that the integrator must carry. Choose ratiometric sensing when sensor output scales with the same reference.

• Calibration policy: offset/gain + temperature compensation

  Define when calibration runs (factory, commissioning, maintenance), how data is validated (CRC/version), and how temperature compensation is applied without destabilizing the loop.

• Over-sampling & decimation: noise benefit vs group delay

  Over-sampling can improve in-band resolution, but decimation filters can add large group delay. If phase margin degrades, noise improvement becomes counterproductive.

DAC / PWM Output Stage (Settling, Glitch Energy, and Safe Clamps)

Output-stage non-idealities often drive “mystery” overshoot, limit cycles, and hard-to-reproduce artifacts. A robust output stage must treat the command as a time-aligned physical signal: it must settle quickly, avoid impulse-like glitches, remain phase-transparent (no hidden delay), and enforce safe bounds under both normal operation and faults.

• DAC settling and update boundary alignment

  Define an update boundary and verify that the DAC output reaches the required error band before the next update. Record settle-to-threshold time (e.g., 0.1% / 0.01%) and treat residual settle as effective delay in the timing budget.

• Glitch impulse control

  Capture the output around update instants to quantify impulse-like glitches. If the plant rings after every update, prioritize glitch reduction and synchronous updating before changing PID gains.

• Output filtering with explicit phase accounting

  Any RC/active filter must publish its group delay (or phase at crossover) as a first-class budget item. Filtering that “looks good on noise” but erodes phase margin will amplify overshoot and instability risk.

• Slew-rate limiting / rate clamp

  Apply rate limits to avoid exciting mechanical or thermal resonances and to protect actuators. Rate limiting is a nonlinearity; its interaction with the integrator must be defined (freeze, back-calc, or conditional integration).

• Clamps and safe bounds (hard + soft)

  Define hard limits (absolute safety) and optional soft limits (comfort zone). A clamp strategy must specify integrator behavior to prevent windup, limit cycles, and slow recovery after saturation.

• PWM as DAC: resolution, dither, edge jitter, synchronous update

  PWM output quality is set by effective resolution, edge placement jitter, and whether updates are synchronized to a fixed boundary. Dither can spread quantization artifacts; unsynchronized edge timing behaves like output phase noise.

• Failsafe output definition (fault/brownout)

  Specify the exact safe output value (voltage/duty), the transition profile (hard cut vs ramp), and the time-to-safe requirement. Safe output behavior must remain deterministic even when software is untrusted.

Discrete-Time PID Done Right (Not Just Kp/Ki/Kd)

A PID controller is an embedded component with state, timing, and nonlinear boundaries. Correct behavior requires discretization consistent with the sample period, noise-aware derivative design, saturation-aware integration, and deterministic mode transitions that prevent output jumps.

• Discretization choices: Tustin vs backward Euler vs matched pole-zero

  Select a discretization aligned to the expected operating bandwidth and timing constraints. If delay/jitter is non-negligible, use the H2-3 budget to determine the safe crossover region before selecting the discrete form.

• Derivative filtering: band-limited derivative

  Implement derivative action with an explicit low-pass limit. Without band-limiting, measurement noise and sampling jitter translate into output chatter and resonant excitation.

• Setpoint weighting (β, γ)

  Apply setpoint weighting to reduce overshoot on setpoint changes while keeping disturbance rejection aggressive. Weighting should be logged alongside step-response tests for reproducibility.

• Anti-windup: back-calculation vs conditional integration

  Back-calculation provides smoother recovery but requires a well-chosen tracking time constant; conditional integration is simpler but needs strict saturation and direction rules. Choose based on clamp behavior and recovery requirements.

• Bumpless transfer: manual↔auto, mode changes, setpoint steps

  Ensure mode transitions do not introduce output discontinuities. Align integrator state and output command at the transition boundary, and apply setpoint ramping when required by actuator constraints.

• Output saturation handling and integrator freeze policies

  Define integrator behavior under saturation and slew limits (freeze, back-calc, or conditional). Record saturation duration and integrator state to diagnose slow recovery and limit cycles.

Loop Shaping Toolkit (Bode, Margins, and Compensation Patterns)

This chapter turns tuning into a repeatable workflow: measure the plant response, set explicit margin targets, and select compensation patterns that trade phase, noise, and delay in a controlled way. The goal is not perfect modeling; it is a defensible bandwidth and robustness reserve backed by evidence.

Practical toolbox (what to do and when)

• Plant identification: dominant poles and effective delay

  Use measured response to locate slope changes and phase roll-off that reveal dominant dynamics. Extract effective delay and treat it as a hard constraint on crossover. Avoid relying on ideal plant order assumptions when fixtures, sensors, or computation introduce hidden dynamics.

• Lead compensation (add phase near crossover)

  Use lead when phase margin is short near the desired crossover. Place the lead action around the crossover region to boost phase while minimizing excessive high-frequency gain that can amplify measurement noise.

• Lag compensation (increase low-frequency gain)

  Use lag to reduce steady-state error and lower integrator burden when the plant allows it. Explicitly account for the phase penalty and ensure the added low-frequency gain does not increase saturation time or limit-cycle risk.

• Notch filters (resonance suppression with a latency trade)

  Use a notch when a resonance peak dominates the response near or below the intended crossover. Tune notch center frequency from measured resonance; keep bandwidth only as wide as required. Document the added phase/group delay impact.

• Feedforward (reduce integrator burden for predictable loads)

  Use feedforward when disturbance or load is measurable or predictable. Validate that feedforward reduces residual error and integrator activity without degrading stability margins.

• Cascaded loops (inner/outer bandwidth separation)

  Use an inner loop to linearize and speed up a fast dynamic, then wrap an outer loop for slower regulation. Maintain clear bandwidth separation so the outer loop does not fight the inner loop or inject delay into the fast path.

• Deadband / hysteresis (nonlinear effects on limit cycles)

  Deadband and hysteresis can create limit cycles and bias. Treat them as nonlinear elements: identify signatures in residual error and output histograms, then apply linearization or redesign boundaries rather than “tuning harder.”

Robustness in the Real World (Noise, Drift, Quantization, and Nonlinearities)

Field stability is often lost to “small” effects that are invisible in ideal models: quantization creates limit cycles, drift biases the integrator, deadzones introduce stick-slip behavior, and temperature shifts move gain and phase. Robust designs treat these effects as first-class elements with clear signatures and logging evidence.

Signatures and first fixes

• Quantization limit cycles

  Signature: periodic residual error and output toggling near steady state. First fix: add controlled dither or increase effective resolution; reduce derivative sensitivity to quantized PV noise.

• Sensor bias drift

  Signature: slowly growing DC residual error and integrator state drift. First fix: implement offset estimation/compensation with a slow time constant; validate via temperature-tagged logs.

• Actuator stiction / deadzone

  Signature: output increases without plant response until a threshold, then motion jumps. First fix: deadzone linearization and hysteresis rules; avoid aggressive relay-like probing that destabilizes the loop.

• Temperature gain/phase drift

  Signature: performance changes with temperature, including reduced phase margin and new oscillation bands. First fix: gain scheduling with smooth interpolation; log PM proxies vs temperature to prevent discontinuities.

• Rate limits and saturation as nonlinear elements

  Signature: slow recovery after saturation, persistent offset, or limit cycles near clamps. First fix: align anti-windup policy with clamp/slew behavior; verify saturation time percentage decreases.

Safety Supervision (Watchdog, Brownout, Hold-Up, Safe State)

A loop controller must fail predictably. Safety supervision defines health criteria, supply-fault behavior, hold-up obligations, and safe outputs in measurable terms—then proves them with reset reasons, brownout flags, timing evidence, and event logs.

Design decisions to pin down (and how to prove them)

• Watchdog policy: simple vs windowed + “healthy” definition

  Choose simple watchdogs for basic hang detection, or windowed watchdogs to also catch runaway timing. Define “healthy” as a combination of heartbeat presence and deterministic execution evidence (e.g., control loop deadlines met, sampling/output tasks observed). A feed should be allowed only when health evidence is valid.

• Brownout detection: early warning vs hard reset thresholds

  Set an early-warning threshold that triggers safe-state entry and log preparation, and a lower hard-reset threshold that forces a reset when reliable control is no longer possible. Validate both thresholds against real supply dip waveforms and detection latency.

• Hold-up time budget: what must remain correct during supply collapse

  Define the hold-up obligation explicitly: maintain safe outputs for a guaranteed minimum time and complete the minimum evidence logging path (event sequence counter + timestamp + reset/brownout cause). Measure time-to-safe and last-gasp completion under worst-case dips.

• Safe state definition: clamp/ramp/latch and timing

  Safe state is an output behavior contract. Specify the safe output value (or duty), whether the transition is a bounded ramp or a hard clamp, and the maximum time-to-safe. Ensure the safe output is maintained through the hold-up window and after reset (if required).

• Fault taxonomy: recoverable vs latched vs degraded

  Classify faults so recovery is predictable: recoverable faults can retry with bounded attempts; latched faults require explicit user/service action; degraded faults reduce bandwidth/output limits while preserving safety. Define retry counts and backoff time to avoid rapid oscillation between states.

• Event log integrity: monotonic counters, timestamps, and last-gasp strategy

  Logs must survive power events: use a monotonic event sequence counter to prevent ambiguity, store timestamps from the same timebase used by the control loop, and implement a “last-gasp” write path that commits the final cause codes before brownout reset. Record commit success as part of the evidence.

Firmware Execution Model (Determinism First)

Determinism is an architecture property. The control loop must run at a fixed rate with bounded jitter while comms and UI execute in lower-priority lanes. Parameter updates must be atomic at defined boundaries, sampling must be timestamped consistently, and commits must support rollback to prevent half-written states.

Architecture patterns (determinism-first)

• Fixed-rate control lane + non-real-time lanes

  The control loop runs on a fixed-rate ISR or highest-priority task with bounded worst-case execution time. Communication, UI rendering, and logging run in lower-priority lanes and must be rate-limited to protect deadlines.

• Double-buffered setpoints and synchronous parameter swaps

  Use two copies of setpoints/parameters: one “active” used by the control loop and one “staging” written by comms/UI. Swap pointers only at a defined boundary (e.g., loop tick) so updates are atomic and deterministic.

• ADC DMA + timestamping strategy (sampling instant is a contract)

  Trigger sampling in a deterministic way (timer-driven), use DMA to move samples, and attach timestamps using the same timebase as the control loop. Record ISR latency distribution and DMA overruns to prove stability under load.

• Calibration updates and commits: atomicity + rollback

  Treat calibration/configuration as transactional: write to a staging slot, verify integrity (CRC), then commit with a single state flip. On failure, keep the previous known-good slot and record rollback evidence.

• Timebase health monitoring and jitter monitoring

  Monitor timebase health continuously: detect abnormal jitter growth and, if applicable, clock source faults. Trigger safe degradation policies when timing quality cannot be guaranteed.

Local HMI for Commissioning & Operations (Make Field Debug Cheap)

A local HMI should answer decisive questions quickly: current mode, target, PV/SV behavior, alarms, and I/O health. The goal is not “more screens”—it is a minimum set of screens and guided flows that reduce mis-tuning, speed up triage, and keep changes auditable even when the network is unavailable.

Screen set (minimum) and required fields

Commissioning flows (guided, safe by design)

• Flow A — Sensor zero/span (with commit/rollback)

  Step 1: ensure mode=Manual and safe output bounds are active. Step 2: capture zero reference, then span reference; validate adc_valid and range flags. Step 3: write calibration to staging and verify integrity; then atomically commit (or rollback on failure).

• Flow B — Actuator direction check (small step + bounded ramp)

  Apply a small output step through a bounded ramp. Confirm PV changes in the expected direction. If direction is wrong, fix mapping before enabling auto control. Log the action with an audit record.

• Flow C — Auto/manual transition (bumpless enable)

  Preload the output and integrator state to match current PV. Switch to auto using bumpless transfer rules. The HMI should display time-to-stable and saturation percentage during the first seconds after enable.

Guided diagnostics (symptom → evidence → first safe action)

• If oscillating → check jitter and delay first

  Evidence: jitter_pkpk (or output update timing), deadline_miss_count. First action: reduce loop bandwidth (lower update rate or add filtering) and lock parameter updates to boundaries.

• If slow → check total delay and output settling

  Evidence: latency budget counters, DAC/PWM update-to-settle time, and PV trend slope. First action: remove hidden delay (excessive filtering), then retune for the effective delay.

• If no response → check I/O path liveness before tuning

  Evidence: adc_valid, overrun flags, I/O range flags, and output clamp state. First action: force a safe manual test step and validate direction and sensor range.

• If saturating → treat it as a nonlinear event, not a tuning event

  Evidence: saturation %, integrator state snapshot, output clamp/rate limit active. First action: enable/adjust anti-windup policy and confirm safe bounds are correct for the actuator.

MPN examples (local HMI + field debug BOM)

Figures & “Cite this figure” Plan (3:2 SVG set)

This subpage uses three reusable 3:2 block-diagram figures. Each figure is designed to be understandable in seconds, with minimal text (≥18px) and high diagram density. The “Cite this figure” block is intentionally visible to support reuse and referencing.