Upgrading PID_Compact V1.x to V2.x on S7-1200 with TIA Portal V16

Overview

The PID_Compact instruction that ships with STEP 7 (TIA Portal) underwent a substantial revision between the V1.x and V2.x instruction libraries. The V2.x branch is bound to S7-1200 CPU firmware V4.x and exposes a redesigned I/O signature, expanded configuration substructure, and a different operating-mode state machine than V1.x. Engineers who maintain long-lived projects in TIA Portal V16, who are replacing first-generation S7-1200 CPUs with second-generation hardware, or who are debugging field reports of "PID drops into manual every minute with output pinned at 50%" need to plan around three coupled constraints: (1) the PID_Compact instruction library version bundled with the active TIA Portal installation, (2) the target CPU firmware version, and (3) the S7-1200 hardware generation that physically hosts that firmware.

This reference documents the procedure for updating an existing program from PID_Compact V1.2 to V2.2 inside TIA Portal V16, the firmware and hardware prerequisites that govern the migration, the interface delta between V1.x and V2.x, the modified error-handling semantics, and the field-proven technique for eliminating the most common V1.x field complaint: the controller dropping from automatic to manual mode with a 50% output excursion.

Prerequisites

Before swapping the PID_Compact instruction version inside your project, verify the following items. Skipping any one of them typically results in a compile error, a download refusal, or a runtime fault.

• TIA Portal installation: STEP 7 (TIA Portal) V16 or higher is required. PID_Compact V2.2 is distributed as part of the instruction library bundled with V16 service packs.
• Target CPU firmware: PID_Compact V2.x requires an S7-1200 CPU running firmware V4.0 or higher. The V2.x instruction code is part of the firmware V4.x technology object family.
• Hardware generation compatibility: S7-1200 CPUs that ship with firmware V4.x are part of the second-generation S7-1200 hardware family. The V3.0 CPU modules cannot be field-flashed to V4.x — the firmware V3.0 → V4.0 transition requires a hardware module replacement.
• Clean baseline: The current project containing PID_Compact V1.x must compile cleanly before the swap. Archive the project before any instruction update so you can roll back.
• Documented interface wiring: Capture the current wiring of every PID_Compact input and output, including HMI tag bindings, faceplate references, and any external supervisory code that writes Mode, ManualEnable, or ManualValue. The interface change requires manual code adaptation; auto-rewiring is not provided.

Identifying Your Current PID_Compact Version

The instruction version lives inside the project library and is selected at the call site. Open any code block that calls PID_Compact (OB, FB, or FC) in the programming editor and look at the right-hand "Instructions" task card. The version number is shown next to the PID_Compact block. Alternatively, double-click the PID_Compact call to open the block interface; the multi-instance DB comment header records the instruction library version and the TIA Portal version that originally inserted the call.

Two version families are relevant for the migration described here:

• PID_Compact V1.x (V1.0, V1.1, V1.2) — first generation instruction, available on S7-1200 firmware V1.x through V3.x. The version encountered in the field report is V1.2.
• PID_Compact V2.x (V2.0, V2.1, V2.2) — second generation instruction, requires S7-1200 firmware V4.x. The target version in the field report is V2.2.

Step-by-Step: Updating PID_Compact V1.x to V2.x in TIA Portal V16

1. Open the project that contains the existing PID_Compact V1.x call in TIA Portal V16. Verify the project compiles before any modification.
2. Navigate to the network containing the PID_Compact block. Click anywhere in the network to give the editor focus.
3. Open the "Instructions" task card on the right edge of the programming editor.
4. Locate PID_Compact in the task card tree. Right-click the entry and select the desired version (V2.0, V2.1, or V2.2, depending on your TIA Portal V16 service pack level and the target CPU firmware).
5. Drag the new version onto the existing call site, or right-click the existing block and choose "Replace with → PID_Compact V2.x" from the context menu.
6. TIA Portal inserts a fresh multi-instance DB with the V2.x interface. Your old V1.x instance DB remains in the project as an unreferenced block; delete it after you confirm the migration.
7. Re-wire every input and output. The V2.x interface is not binary-compatible with V1.x: tag names, data types, and ordering have changed. The Siemens Help entry PID_Compact interface change V1 to V2 catalogs the deltas.
8. Compile the program. Resolve any type mismatches reported by the compiler. Common errors include BOOL vs REAL mismatches at the Setpoint/Input parameters, missing Config substructure fields, and references to V1.x tag names that no longer exist.
9. Download the project to the target CPU. The download includes a STOP-to-RUN transition; plan the outage accordingly and confirm bumpless hand-off of any external controlled process.
10. Verify tuning data and reference model. The V2.x tuning algorithm footprint differs from V1.x, so values you tuned under V1.x must be re-validated before relying on them in production.

Firmware V3.0 to V4.0: Hardware Replacement, Not Firmware Update

The S7-1200 firmware V3.0 to V4.0 transition is not a service-pack update that the existing CPU module can absorb. The CPUs that ship with firmware V4.0 are part of the second-generation S7-1200 hardware family. The migration therefore follows a hardware-replacement procedure rather than a firmware-flashing procedure.

The hardware-generation gap drives several field-level consequences that you must plan for:

• The CPU ASIC revision is different, which alters the onboard PROFINET interface behavior, the onboard analog I/O channel architecture, and the technology object (TO) execution model.
• The device configuration in TIA Portal (module rack, I/O assignments, PROFINET device names, IP address) must be re-created for the new module. Re-use the configuration where mechanically identical, but plan for re-entry of all project-level settings.
• Retentive tag mappings, IP addresses, and PROFINET device names must be migrated by export/import or re-entered manually. Recipes and operator passwords follow the same path.
• The PID_Compact V2.x instance DB does not migrate from a V1.x instance DB. You must re-enter configuration parameters — Setpoint limits, input scaling, output limits, sampling time — from your commissioning records.
• Signal modules (SM), communication modules (CM, CP), and technology modules (TM) attached to the original CPU may have different compatibility status with the second-generation CPU. Cross-check the module manual entries before re-attaching them.

The dedicated Siemens Support entry on this hardware migration is ID 82140966 — What to watch out for in TIA Portal when replacing an S7-1200 V3 with a V4. Read it before commissioning the new module.

Interface Changes Between V1.x and V2.x

The PID_Compact V2.x interface supersedes the V1.x interface. The official change list is published under Siemens Support entry 108210036 / 50237046539 — Interface change PID_Compact V1 to V2. The principal differences you must adapt in your program are summarized below.

Field implication: any program logic that listens for the V1.x "drop to inactive on error" behavior must be rewritten. V2.x stays in its current operating mode and surfaces the error condition through the error outputs. If your HMI faceplate used the inactive state as a fault indicator, you must rewire the logic to watch the Error BOOL and decode ErrorBits.

Error Handling Differences: Inactive State vs Stay-in-Mode

The single most consequential behavioral change between V1.x and V2.x is how the instruction reacts to error conditions. In V1.x, whenever one of the documented error conditions occurred, the instruction transitioned itself to the inactive state (State = 0). In V2.x, the instruction remains in its current operating mode and reports the error via the Error BOOL and the bitfield ErrorBits.

The error conditions are catalogued under Siemens Support entry 108210036 / 96782740619 — Error conditions for PID_Compact. The error conditions include, among others:

• Invalid input value (Input_PER out of range, Input not finite)
• Invalid setpoint value (Setpoint not finite)
• Invalid manual value during manual mode
• Configuration error in the Config substructure (out-of-range limits, inverted scaling)
• Output value cannot be calculated (integral wind-up limit reached with an invalid proportional path)

The decoded ErrorBits semantics for V2.x follow the layout defined in the help entry. Typical bit positions encountered in field reports include the configuration-error bit, the input-value-error bit, the setpoint-error bit, and the manual-value-error bit. A summary bit is set when any individual error condition is reported.

Operating Modes and the State Parameter

The current operating mode of PID_Compact is reported at the output parameter State. According to the official example program documentation for PID_Compact V2 — see Example program for PID_Compact V2 — and the canonical Siemens Online Help, the State values are:

The mode is commanded by the Mode input. Writing the integer value 4 requests manual mode; writing 3 requests automatic mode; writing 1 requests pretuning; writing 2 requests fine tuning. The instruction honors the requested mode on the next call provided the enable chain is satisfied.

Switching to Manual Mode: Two Supported Mechanisms

Per the Siemens Help entry for PID_Compact, there are two supported ways to force the instruction into manual mode:

1. Mode input write: Drive the Mode input (or the V1.x sRet.i_Mode) to the integer value 4. The instruction enters manual mode at the next call.
2. ManualEnable rising edge: Apply a rising edge to the ManualEnable BOOL input. The instruction enters manual mode on the next call after the edge is detected.

Both mechanisms converge on the same internal state. Once in manual mode, the controller holds the last automatic output until your program updates ManualValue; after that, the output tracks ManualValue directly. To return to automatic mode, write Mode := 3. Returning to automatic mode is naturally bumpless only if the integral path has tracked the manual output during the manual period — see the bumpless-transfer discipline below.

Why Your Output Drops to 50% on Manual Entry

The single most common field complaint when migrating from V1.x to V2.x — and even on first-time V1.x deployments — is that the control output abruptly settles at 50% whenever the controller enters manual mode, then resumes automatic control from there. This is not a bug in the instruction; it is the predictable consequence of how the instruction handles an uninitialized ManualValue.

The PID_Compact instance DB initializes ManualValue to a default value on first download. If your program code forces the controller into manual mode without first writing the current automatic output into ManualValue, the output snaps to the instruction's default output value at the moment the manual transition takes effect. The visible result is an output step (in many plants reported as "output pinned at 50%"), followed by the output tracking your subsequent ManualValue writes.

The same mechanism causes the "automatic to manual every minute" symptom reported in the field report: an external supervisory routine (typically a watchdog, a bumpless-transfer sequencer, or a sequencing FB that toggles ManualEnable on a schedule) drops the controller into manual mode without first priming ManualValue. The output snaps to the default value, the operator intervenes, the supervisory code re-enables automatic, the loop runs for a minute, and the cycle repeats.

Bumpless Transfer to Manual Mode

The fix is the bumpless-transfer discipline: before any code path drives the controller into manual mode, it must first write the current automatic output into ManualValue. When this discipline is enforced, the transition from automatic to manual mode is a smooth step with no output excursion, no process bump, and no operator-visible disturbance.

Reference implementation in Structured Control Language (SCL):

// Always prime ManualValue from the current controller output.
// This network MUST run on every cycle, before the PID_Compact call.
"PID_DB".ManualValue := "PID_DB".Output;

// Then drive Mode / ManualEnable as normal.
IF "Go_Manual" THEN
    "PID_DB".ManualEnable := TRUE;
END_IF;

// Optional: clear the rising edge after the mode change has taken effect.
IF "PID_DB".State = 4 THEN
    "PID_DB".ManualEnable := FALSE;
END_IF;

Reference implementation in ladder logic:

// Network 1 — prime ManualValue from current output (every cycle)
      PID_DB.ManualValue    PID_DB.Output
   |----------------------------------|

// Network 2 — assert ManualEnable on rising edge of operator request
      Go_Manual    PID_DB.ManualEnable
   |   |P|----|

// Network 3 — clear ManualEnable once the controller has entered manual mode
      PID_DB.State == 4    PID_DB.ManualEnable  (R)
   |----------------|

Important details for the priming network:

• Scaling: ManualValue and Output use the same 0–100% engineering units. No conversion is required between them when copying within the same loop.
• Order: The priming assignment must execute before the same cycle's PID_Compact call processes the mode change. Placing the priming network in the cycle immediately upstream of the call guarantees the correct order. Inside the same FB, place the priming write at the top of the network, with the PID_Compact call at the bottom.
• Edge-triggered mode logic: If you use ManualEnable (rising-edge), the priming write should happen on the same OB cycle that asserts ManualEnable. The instruction will see ManualValue already primed when it processes the edge.
• Returning to automatic: When you command automatic mode after a manual period, the integral path of the PID_Compact instruction will reconcile against the manual value if you primed correctly. The standard Siemens example relies on the integral path automatically reconciling on return to automatic mode; no separate priming is required.
• Multiple supervision paths: If multiple sources can drive the controller into manual mode (operator HMI, watchdog, sequencer), each source must respect the priming discipline. Centralize the priming write in a single network that runs unconditionally, then let any source assert ManualEnable or write Mode.

Common Error: Manual Mode Forced by Program Logic

If your code exhibits "PID drops to manual every minute, output snaps to default," verify the following before suspecting the controller itself:

1. Search the entire program for any write to PID_DB.Mode with a value of 4. Use cross-references in TIA Portal (right-click → "Cross-references").
2. Search for any rising-edge write to PID_DB.ManualEnable. A common culprit is a "bump-less transfer" sequencer that reasserts ManualEnable on every watchdog tick.
3. Search for any HMI tag or operator faceplate that writes either of the above. Operators occasionally bind these tags to a momentary pushbutton that the HMI retriggers on a slow polling interval, producing a steady 50–60 second cycle that matches the field report exactly.
4. Inspect any watchdog or sequencer FB that may be toggling ManualEnable as part of a fallback sequence. Replace ad-hoc toggling with a state machine that only asserts manual mode on a true process-condition.
5. Inspect the V1.x legacy fallback: if the project is on V1.x and the controller is transitioning to inactive on error, the program logic that brings it back to automatic may be inadvertently setting manual mode first. Insert a priming network upstream so that the controller does not bump to the default output during the recovery sequence.

Verification Procedure

After completing the migration and deploying the bumpless-transfer fix, run the following verification sequence. Every step should be repeated after any future change to the PID_Compact call site.

1. Open a watch table on the PID_Compact instance DB. Confirm State = 3 (automatic mode) after a warm restart.
2. Force a manual transition from the engineering station by writing Mode := 4 and observing State advance to 4 on the next cycle.
3. Watch Output over the transition. The expected trace is a smooth continuation from the last automatic output — not a step to the default value. If you see a step, the priming discipline is missing from at least one transition path.
4. Return to automatic mode (Mode := 3). Confirm State returns to 3 and that the controller resumes tracking Setpoint without an output excursion.
5. Force an error condition (e.g., set Input to a non-finite value or write outside the configured input range). On V2.x, confirm that the controller remains in its current mode and that Error transitions to TRUE. Confirm that ErrorBits shows the expected bit position.
6. On V1.x, repeat the error condition and confirm the controller transitions to State = 0 (inactive) — the legacy behavior that V2.x removes. This step is the explicit behavioral difference and is the most useful regression check after migration.
7. Verify tuning data: run pretuning (State = 1) and fine tuning (State = 2) on a representative process excursion. Confirm that the calculated Retain.CtrlGain, Retain.Ti, and Retain.Td parameters land in plausible ranges for your plant. Pretuning must run from a stable operating point with the process at or near setpoint.
8. Long-duration stability test: leave the controller in automatic mode for at least one full process cycle (typically 24–72 hours for thermal or pressure loops). Confirm that State never falls to 0 (inactive) or 4 (manual) unexpectedly. Capture a trend of Output, Setpoint, and Input for review.

Troubleshooting Matrix

Configuration Substructure: Scaling and Limits

The V2.x instance DB introduces an expanded Config substructure with explicit scaling fields. Two scaling paths must be configured before first RUN:

• Input scaling: the engineering-unit range corresponding to the analog input's electrical range (for example, 0–100 °C for a 4–20 mA input). The configuration is a linear mapping.
• Output scaling: the engineering-unit range of the controller output (typically 0–100% for a continuous actuator, or a three-position range for a split-range or motorized-valve actuator).

Both paths include upper and lower limits that the algorithm uses to clamp the working range, detect out-of-range inputs, and bound the integral accumulator. If either is left at the default zero values, the algorithm will not function correctly. Confirm the values before downloading the migrated project.

Cyclical Execution: Where to Place the PID_Compact Call

PID_Compact V2.x is designed to run in a fixed-time cyclic OB. The recommended placement is in OB30 through OB38 (cyclic interrupt OBs), with the cycle time of the OB matching the configured sampling time of the controller. Avoid placing the call in OB1 with no fixed-time discipline: variable cycle time degrades the tuning result and produces inconsistent error reporting.

When migrating from V1.x, the placement typically does not change — most V1.x installations already use a cyclic OB — but the configured sampling time may need to be re-entered in the V2.x instance DB because the parameter name and field location differ.

Retention and Restart Behavior

Tuning parameters live in the Retain substructure of the instance DB. The Retain substructure is non-volatile across warm restarts and cold restarts provided the CPU's retentive tag area is configured to include it. After a factory reset or a download that initializes all retain tags, the controller loses its tuning parameters and must be re-tuned.

Operational parameters that do not belong in Retain include the current Setpoint, ManualValue, the running Output, and the State value. These reset to defaults on every cold restart and the controller re-enters automatic mode with the most recent tuned parameters. The bumpless discipline for the cold-restart case is to wait one full cycle before applying any external manual mode write, so that the controller's internal Output tracks the live process.

FAQ