S7-PDIAG: Resolving 'Not Up to Date' Block Consistency Warning

Overview

The STEP 7 optional package S7-PDIAG provides automatic process diagnostics for S7-300 and S7-400 controllers. It captures supervision and interlock results from S7-Graph sequencers, FB/FC blocks, and SFC charts, then exposes them through standardized diagnostic data blocks (DBs 0–127 in the PDIAG range) for HMI visualization through ProAgent on ProTool, WinCC flexible, or TIA Portal HMI panels. When the S7-PDIAG database in the offline project does not match the diagnostic configuration of the user program, STEP 7 raises a block-consistency warning:

This warning is generated by the Check Block Consistency function (right-click on the Blocks folder → Check Block Consistency) and stops the download-to-target workflow until the diagnostic data is regenerated. The condition is not a syntax error in the user code; it is a desynchronization between the offline PDIAG configuration and the offline user program blocks. The standard manual defines the rebuild flow in the S7-PDIAG Configuring Process Diagnostics manual (entry ID 1137078).

Problem Manifestation

Field reports cluster around three observable symptoms:

1. The compiler produces a single non-fatal warning during block consistency check and refuses to continue until acknowledged.
2. Subsequent downloads to the CPU are blocked because the generated diagnostic DBs (DB 0–DB 127) are flagged inconsistent.
3. The HMI runtime shows "no diagnostic data available" or gray step numbers in the ProAgent unit overview, even though S7-Graph sequencers contain valid supervision and interlock logic.

Typical environment for this fault:

Root Cause Analysis

The S7-PDIAG database is a hidden sub-tree inside the S7 program that holds the diagnostic configuration (which addresses to monitor, which message classes, which message numbers, and which operands in S7-Graph steps are linked to the diagnostic DBs). Whenever you change an S7-Graph sequencer — add a step, change an interlock address, rename a symbol, or move blocks between projects — the PDIAG configuration must be re-derived. If the derivation does not run, the database goes "stale."

Common root causes, ordered by frequency in field cases:

Diagnostic Prerequisites

Before applying any of the recovery methods below, verify the following baseline. Skipping this step leads to the warning reappearing after the next save.

1. Open SIMATIC Manager → Options → Module Information on the station and confirm a CPU 31x/41x is configured. PDIAG is unsupported on S7-1200/1500 controllers — those use the integrated diagnostics of TIA Portal.
2. Open Options → Configure Process Diagnostics. If every input field is grayed out, the option package is not installed. Close the dialog and resolve licensing first (see KB 18385271).
3. In the project tree, expand the S7 program and confirm whether a PDIAG sub-folder is present. If visible, note its size and timestamp — a folder with a modification time older than the most recent S7-Graph save is the prime suspect.
4. Open any S7-Graph sequencer and confirm that supervisions (red circles) and interlocks (green circles) are present. Empty sequencers do not require PDIAG data and the warning should not appear in that case.

Recovery Methods

Use the methods in the order shown. Method 1 is the in-place rebuild recommended by Siemens; Method 2 is the most common workaround when no PDIAG license is available; Methods 3–5 address secondary causes.

Method 1 — Configure Process Diagnostics: Compile All

1. Open SIMATIC Manager.
2. Select the S7 program node (not the Blocks folder).
3. Choose Options → Configure Process Diagnostics.
4. In the dialog, set the diagnostic data block range (default DB 0 – DB 127) and confirm Generate message numbers automatically is enabled.
5. Click Compile All. STEP 7 walks every FB, FC, SFB, SFC, S7-Graph FB, and instance DB, regenerates the PDIAG database, and writes the matching diagnostic DBs.
6. Close the dialog and rerun Check Block Consistency. The warning should be replaced by "No errors found."

Method 2 — Delete and Regenerate the PDIAG Sub-Folder

Use this when the project was inherited from a customer, contains residual PDIAG data, or when no S7-PDIAG license is present on the engineering station and you want a clean shell.

1. Close STEP 7 completely.
2. Using Windows Explorer, navigate to the project directory:

3. Delete the entire PDIAG folder.
4. Reopen the project in SIMATIC Manager.
5. Right-click Blocks → Check Block Consistency. STEP 7 detects the missing PDIAG database and creates a new, empty one. The warning about being "not up to date" disappears because the project is now internally consistent (it has nothing to be out of date from).
6. If you have an S7-PDIAG license, immediately follow with Method 1 to populate the freshly created folder with the correct diagnostic data.

Method 3 — Recreate the Project from Source Blocks (Not Copy/Paste)

Siemens field documentation explicitly states that copy/pasting blocks between S7 programs does not carry the PDIAG attributes. A diagnostic-enabled block pasted into a fresh program has no PDIAG anchoring, so the warning returns on the first consistency check.

1. Archive the original customer project using File → Archive (do not copy individual blocks).
2. Open the archive in a fresh working directory and de-archive it. This rebuilds the entire S7 program tree, including the PDIAG folder structure.
3. Apply your modifications directly inside the de-archived project. Do not use Windows Explorer to copy blocks into it.
4. Re-run Check Block Consistency.

Method 4 — Resolve Block-Number Conflicts

The S7-PDIAG manual reserves the block-number range normally used for the diagnostic DBs. If your user program happens to occupy those same numbers, PDIAG cannot write its generated DBs and the consistency check fails with a hidden conflict.

1. Open Options → Configure Process Diagnostics and note the configured DB range (default 0–127).
2. Open the symbol table and search for any user DBs whose numbers fall inside that range.
3. Either renumber the user DBs (recommended: move user DBs above 200) or shift the PDIAG DB range in the configuration dialog to an unused range.
4. Recompile and re-check.

Method 5 — Open a Siemens Support Request

If Methods 1–4 do not clear the warning — typically when the project tree itself is structurally corrupt and STEP 7 cannot read the PDIAG sub-folder — escalate through official Siemens support with the following information attached:

• Compressed project archive (.zip of the full project directory).
• Output of Station → Consistency Check in text form.
• Screenshot of the Check Block Consistency warning.
• Version of STEP 7, S7-PDIAG, and S7-Graph installed (from Help → About).

Working Without an S7-PDIAG License

Engineers who receive a customer project but do not own an S7-PDIAG license face a specific problem: the consistency warning cannot be cleared through Configure Process Diagnostics → Compile All because the menu is grayed out per KB 18385271. The supported path in that case is:

1. Apply Method 2 to obtain a clean, license-free PDIAG shell.
2. Continue editing the user program (S7-Graph, FB, FC) without diagnostic configuration.
3. At the point of final acceptance or hand-back, hand the project to an engineering station that has the S7-PDIAG license so the diagnostic data can be regenerated before commissioning.

Do not attempt to populate message texts or unit assignments without a license; the fields are read-only and any manual edits to the S7 program that rely on PDIAG attributes will not be reflected in the runtime diagnostic DBs.

Block Number Allocation Reference

To prevent block-number conflicts at the design stage, observe the following allocation, taken from the S7-PDIAG manual:

Verifying the Fix

After applying any of the recovery methods, perform the following verification sequence:

1. Offline consistency: Right-click Blocks → Check Block Consistency. Expected: "No errors or warnings found."
2. Cross-reference check: Open one S7-Graph sequencer, click on a supervision (red circle), and confirm the Cross-References view shows the diagnostic DB. If the cross-reference is empty, the supervision is not anchored to PDIAG.
3. Download and online test: Download the entire program to the CPU in Stop mode, restart in Run, and force one supervision condition. The ProAgent unit view on the HMI should display the corresponding step number, message text, and timestamp within 2 scan cycles (typical CPU 315-2 DP: 40–80 ms).
4. Online PDIAG status: In SIMATIC Manager, choose PLC → Diagnostics/Setting → Process Diagnostics. The status should read "PDIAG active" and list the configured units.

Preventive Best Practices

• Always run Configure Process Diagnostics → Compile All immediately after any S7-Graph edit. Treat it as a mandatory post-step, not an optional one.
• Archive the entire project (not individual blocks) when handing work to a colleague or contractor. PDIAG data only survives an archive/de-archive cycle, not a copy/paste.
• Reserve DB 0 – DB 199 for PDIAG in your coding standard, even if your current PDIAG range is narrower. Future reconfiguration will then be non-breaking.
• Document the S7-PDIAG option package version in the project header. Mixing PDIAG V5.3 projects with PDIAG V5.6 engineering stations has been observed to produce silent attribute loss.
• If you work in a mixed team where some engineers have a PDIAG license and others do not, keep the diagnostic configuration frozen on a single engineering station. Edits by un-licensed stations will be rejected by the consistency check.

Troubleshooting Matrix