A one-second PID scan rate is a default, not a universal tuning target. Select the update interval from measured process dynamics and the slowest element in the measurement-to-output path. A faster PID calculation provides no benefit when the analog input continues returning the same process value.
When a One-Second Scan Rate Is Defensible
The cited sampled-data guidance uses an interval near 10% of the dominant process time constant as a practical starting point. It is therefore plausible for a slow loop but unsupported for a process with dynamics measured in milliseconds.
Another stated criterion is to keep the controller update time below the loop's equivalent dead time. These rules are starting points rather than guarantees: sensor conversion, I/O freshness, actuator response, controller execution, and process lag must all support the selected interval.
| Observed quantity | Evidence | Engineering consequence |
|---|---|---|
| Fast tension-loop time constant | Approximately 100 ms | A one-second update is too slow relative to the stated process dynamics. |
| SNAP-AIMA-8 freshness | 280 ms maximum | A millisecond-level PID schedule cannot create fresh measurements at that rate. |
| Observed pass-through update | Approximately 340 ms | The measured response agrees with input freshness plus analog scanning and processing delay. |
| SNAP-AIMA measured response | 19 ms average; 10 to 42 ms range | A 25 ms PID interval became supportable for the tested installation. |
| Winder dead time | 130 ms in torque control; approximately 220 ms in speed control | Torque control provided the shorter measured delay for this application. |
Separate PID Execution from Data Freshness
In the tested rack-based architecture, the PID calculation was interrupt-driven at the selected rate. Closing the programming software and using a minimal debug compile did not change the approximately 340 ms output steps. In velocity mode, the proportional calculation used the change between successive process values. At short scan intervals, that difference remained zero because the analog value had not refreshed; nonzero changes appeared consistently only when the interval exceeded about 350 ms.
The SNAP-AIMA-8 specified 280 ms maximum data freshness. Adding two reported analog scans of about 20 ms gives 280 ms + 2 × 20 ms = 320 ms. Additional processing accounts for the remaining difference to the observed approximately 340 ms response. This establishes stale input data—not failure of the PID timer—as the supported cause.
Account for Local and Hosted I/O
Local rack-based PID execution can remain tightly scheduled independently of the controller strategy's polling cycle. That timing does not ensure that each execution receives a new process value.
If an input or output resides on another rack and is configured as hosted I/O, the strategy must transfer the PID input or output. Actual closed-loop timing then also depends on program execution and network design. Measure the complete path instead of treating the configured PID interval as the effective control interval.
Diagnose and Select the Update Interval
- Measure the sensor directly. In the documented test, an oscilloscope sampling at 1000 Hz showed a smooth sensor waveform, eliminating slow sensor conversion as the immediate explanation.
- Configure a proportional-only pass-through test. The test used a parallel-form PID with a 1 ms configured interval to transfer the analog input to an analog output.
- Measure output step spacing. Approximately 340 ms steps showed that the loop could not act on new data every 1 ms, even though the PID calculation was scheduled faster.
- Compare the result with module freshness and analog scan time. The SNAP-AIMA-8 freshness and reported 15–20 ms analog scan time explained the measured delay.
- Remove the limiting element or slow the PID schedule. Replacing the SNAP-AIMA-8 with a SNAP-AIMA reduced measured response to a 19 ms average, with a 10–42 ms range.
- Choose the interval from both measured freshness and process dead time. A 25 ms setting was selected after 104 of 121 logged steps measured 21 ms or less; under the recorded 42 ms maximum, at least every second 25 ms execution would encounter a refreshed value.
- Repeat the step test and retune after changing the scan interval. Verify response in both directions and confirm that the actuator, sensor, I/O, and process all support the final rate.
Apply the Result to the Center-Winder
The center-winder was tested in speed and torque modes. Speed control behaved as an integrating process: a speed command below equilibrium reduced tension toward zero, while an excessive command increased tension until material failure or torque limiting intervened. It also allowed the upstream drive speed to serve as a feed-forward term.
Torque control produced a new steady dancer position after an open-loop torque-command change. Its measured dead time was 130 ms, compared with approximately 220 ms for speed control. The drive architecture explained the difference: the speed loop was an outer loop feeding the inner current loop.
The selected 25 ms interval was close to the fast end of that range and was practical only after improving analog freshness. With the former approximately 340 ms measurement response, the effective update was about 2.6 times the 130 ms process dead time, causing either overshoot or severe detuning.
Verify the Final Configuration
Log actual process-value changes rather than relying only on the configured scan rate. Confirm that measured input freshness, PID execution, output delivery, actuator response, and total process dead time remain stable under operating load. If velocity-form proportional action repeatedly sees zero process-value change, first verify data freshness before modifying gain.
The one-second default is acceptable only when measurements demonstrate that it is suitably short relative to the process. For this winder, the measured millisecond-scale dead times and improved input response justified a millisecond-scale update instead.
FAQ
Why does a 1 ms PID scan produce 340 ms output steps?
The SNAP-AIMA-8 input had 280 ms maximum data freshness. Combined with analog scans and processing, the measured path updated in approximately 340 ms even though the PID calculation ran more frequently.
What PID scan rate was used after replacing the analog module?
The SNAP-AIMA produced a 19 ms average measured response with a 10–42 ms range. A 25 ms PID interval was selected after 104 of 121 logged steps were 21 ms or less.
Should PID scan time be based on dead time or the default?
Base it on measured loop dynamics and data freshness.