Deadband Minimum of 1.0
When migrating PID blocks from older versions that used INT data types to newer versions using REAL, the deadband parameter needs attention. Set the deadband to a minimum of 1.0.
The reason: with REAL data types, the process variable will almost never land on exactly the same value twice. A deadband of zero (or near-zero) means the PID block recalculates its output on every single scan, even when the process value has only changed by a fraction of a unit. This creates unnecessary output chatter and can wear out actuators.
Why the Change from INT to REAL Matters
- INT-based PID: Process values were whole numbers. A deadband of 0 still had an effective resolution of ±1 count. The PID only recalculated when the value actually changed by at least 1.
- REAL-based PID: Process values have decimal precision. Noise, A/D converter jitter, or floating-point rounding means the value changes by tiny amounts every scan. Without a meaningful deadband, the PID never stops recalculating.
Periodic Tasks for PID Sections (Allen-Bradley)
On Allen-Bradley platforms (ControlLogix, CompactLogix), consider moving PID logic into a periodic task rather than running it in the continuous or main task. Benefits:
- Fixed execution interval — The periodic task fires at a deterministic rate regardless of what the continuous task scan time is doing. PID tuning parameters (integral time, derivative time) depend on a consistent time base. If your PID runs in the continuous task and scan time varies from 50ms to 150ms depending on load, your tuning is effectively different on every scan.
- Predictable control response — Set the periodic task rate to match your PID update rate requirement (typically 100–250ms for most process loops). The PID block’s internal calculations assume a fixed dt — give it one.
- Isolation from main logic — Heavy PID processing won’t stretch the continuous task scan time, and changes to the main program won’t affect PID execution timing.
Produce/Consume Tags for PID Triggers (Allen-Bradley)
On Allen-Bradley systems, if PID sections need data from other controllers or need to be triggered by events across a ControlNet or EtherNet/IP network, Produced/Consumed tags are the right mechanism. This is specific to the Logix platform:
- Produced tags broadcast data from one controller to the network at a configured RPI (Requested Packet Interval).
- Consumed tags in the receiving controller pick up that data with deterministic timing.
- This avoids the overhead and non-determinism of MSG instructions for time-critical PID data like cascade setpoints, feedforward signals, or interlock triggers between controllers.
- RPI must be coordinated — The Consumed tag RPI should be equal to or faster than the periodic task rate running the PID. If your PID runs every 200ms but the Consumed tag updates every 500ms, the PID is working with stale data for 3 out of every 5 executions.
Scan Time Awareness
Regardless of platform, always verify the actual PLC scan time after making PID changes. A PID block that assumes a 100ms execution interval but actually runs at 250ms (because the scan got longer) will have its integral and derivative actions effectively de-tuned.
On Allen-Bradley, check the periodic task actual scan time in the controller properties — not just the configured rate. If the task is overrunning its configured period, the PID timing assumptions are broken.
On Schneider M580, check the MAST or FAST task configured period and actual execution time in the diagnostics. If PID logic is in the MAST task, it’s subject to scan time variation from everything else in MAST.
Monitor scan time and set the PID time base parameter to match actual execution — not what you think it should be.