Fix the PID function block not allowed compile error

What does the "PID function block not allowed" compile error mean?

The message is a task-placement restriction: the compiler rejects any PID function block placed in a task configured to run every second, and it keeps rejecting the project until the block sits in a task that executes every scan.

The message carries two separate facts. Cannot compile "Run every second PID Loop" names the task where the compiler found the block, and PID function block not allowed is the reason. The reason is about location, not about the loop's gains, scaling, setpoint or wiring: changing gains or wiring leaves the error in place, because the restriction applies to the block's task assignment. No PID loop in the timed task means no compile, however well the loop is tuned.

Why is a run every second task not allowed to hold a PID loop?

The controller's documented rule gives a PID loop one allowed home, a normal task executed every scan, because PID output depends on elapsed time between updates and the controller pins that timing to the scan instead of letting the 1 s timed task own it.

A task that fires every second looks like a perfectly regular sample time, and for a slow process it would be. The rule is still unconditional. Vendors pin loop execution to a schedule the controller controls so the integral and derivative bookkeeping always works from a known interval; a timed task takes that control away. Where tasks sit in the execution order, and which logic wins when schedules overlap, is its own subject; the walkthrough on tracing PLC execution order across task layers covers it.

Which task is the PID block actually in?

Open the task configuration and check which task contains each PID rung: the error text itself names the task, Run every second PID Loop, so the block is either sitting in that 1 s timed task or in a second instance you have not found yet.

The symptoms and what each points to:

• The compile error names the run-every-second task. A PID function block is assigned to that timed task. Move it; the steps are below.
• The reason line reads PID function block not allowed. The placement rule is firing. Gains, scaling and wiring are not part of it.
• The error survives after you move one loop. A second PID instance remains in the timed task. Search the project for every PID instruction, including copies parked on unused rungs.
• The block looks like it lives in the normal task. Confirm the task assignment itself. A rung referenced from normal-task logic does not count if the block's own assignment still points at the timed task.

The check that settles it: read each task's type and interval in the task configuration. The every-scan task is the normal or scan task, and the timed task shows its interval next to its name.

How do you move the PID loop into the normal scan task?

Cut the PID rung from the run-every-second task, paste it into the normal task that executes every scan, confirm the block's task assignment actually reads the normal task, and compile again; the placement error clears with no change to gains, scaling or wiring.

1. Open the task configuration in the programming software and list every task with its type and interval. Identify the normal task that runs every scan and the timed task running every 1000 ms.
2. Search the project for every PID function block instance, including copies on unused rungs.
3. Cut each PID rung out of the timed task and paste it into the normal task's program.
4. Confirm each block now belongs to the normal task in the task configuration. A reference from normal-task logic is not an assignment.
5. Leave the rest of the timed task's logic where it is; only the PID block has to move.
6. Compile and confirm the placement error is gone.

Gains, alarm limits and the loop's mode are entries in the programming software's PID setup dialogs, and the move leaves those entries untouched. Retuning is a deliberate second step, covered next.

What changes when the loop updates every scan instead of every 1000 ms?

The loop's sample interval drops from 1000 ms to the controller's scan time, typically a few milliseconds on a small program, so a handful of milliseconds replaces one update per second and the gains you had no longer produce the same response.

Three things follow from the faster cadence. The integral term accumulates far more often per second, which is the change you will see first. Derivative action sees fresher samples, which exposes noise that a 1 s sample hid; use the derivative filter in the PID setup, or trim the derivative gain. And any edge-detect contact or one-shot that moved with the rung now fires per scan, the same class of behavior documented for PAC firmware edge contacts that copy data on every scan. Logic elsewhere carries the same trap: an SCL FOR loop on an S7-1200 executes fully on every scan cycle, however short the scan is.

Whether your controller's PID rescales its terms by the measured interval is a question its PID documentation answers; plan the first run in auto as a retune either way. Keep heavy logic out of the normal task as you add to it: a task that monopolizes scan time is the pattern behind a status task spin watchdog exception, and the PID's update interval slows with every millisecond the scan grows.

What does the timing change look like in a worked example?

A worked example shows the size of the change: a program whose diagnostics page reads a 5 ms scan time moves its PID from 1 update per 1000 ms to 200 updates per second, a 200-fold increase in how often the integral term adds its increment.

Scenario: a packaging-line temperature loop, tuned while the PID sat in the timed task, now relocated to the normal task. The diagnostics page reads a 5 ms scan time after the move. The arithmetic:

• Updates before: 1000 ms ÷ 1000 ms per update = 1 update per second, or 60 per minute.
• Updates after: 1000 ms ÷ 5 ms per scan = 200 updates per second, or 200 × 60 = 12,000 per minute.
• Integral action left unchanged: the old tuning moved the output 1% per second at a steady error, which at 1 update per second is 1% per update. At 200 updates per second, the same increment drives 1% × 200 = 200% of output per second, and the valve saturates on the first step.
• Starting point for the retune: 1% per update × 200 updates per second × 1/200 = 1% per second, so an integral gain one two-hundredth of the old value reproduces the old output rate. Tune from there against the step response, and leave derivative off or heavily filtered for the first auto runs.

The 5 ms reading is an illustrative number. Take the real scan time from your controller's diagnostics page before you divide.

Can I put the PID back on a 1 second cadence?

Recreating the old per-second cadence is possible only if your controller's documentation allows a gated PID rung; this controller documents one allowed home, the every-scan task, so run the block every scan and slow the loop's response with its tuning instead.

The task rule has no timed-task exception in the documented guidance, so a 1 s update comes from tuning, not placement. Sampling far faster than the process moves costs nothing physically: a temperature loop with a 30 s response time behaves the same whether the controller samples it every scan or once per second. The algorithm's bookkeeping changed, and the retune absorbs that. If the process needs slower logic around the loop, keep ramping, rate limiting or output staging in the timed task where it is allowed, and let the PID rung alone live in the normal task.

What should you check before the loop goes back to auto?

A clean compile clears the placement error and nothing else; before returning the loop to auto, verify the process-variable, setpoint and output connections, watch one step change on a trend, and compare the response against the behavior you tuned for.

• Connections: process variable, setpoint and output match the rung's design, with scaling unchanged from the version that ran before the move.
• Manual first: put the loop in manual, step the output by hand, and confirm the process variable moves in the right direction at the expected pace.
• Trend: watch the step on a trend with timestamps. If the loop shows on an HMI trend, mind the trend's own update budget, which is separate from the PID's scan cadence; the piece on why an HMI trend graph will not update every half second explains that limit.
• Operator on the loop: keep one person watching for the first auto step, with the manual station within reach, because a retuned loop can drive its output far faster than the old 1 s cadence did.

Recommendation: move every PID function block in the project into the normal every-scan task in one pass, compile until PID function block not allowed is gone, read the measured scan time from the controller's diagnostics, divide the integral gain by the update-rate ratio, and return the loop to auto only after a manual-to-auto step looks right on the trend.

Questions