CEMAT V7.1 Supervision Error: Fixing ES_MAP Block Issues in PCS7 V7.1 SP3

Symptom: A flashing red "F" appears in the CEMAT V7.1 supervision screens of a PCS 7 V7.1 SP3 project, group consumers are missing from the group overview, and the diagnostics flag blocks whose author is "ES_MAP" together with FC1061 / FB1010 errors. This article documents the field-proven diagnostic and recovery path for these ES_MAP generated runtime artifacts in the CEMAT mineral/cement library.

1. Problem Overview

CEMAT V7.1 uses a two-layer architecture: the automation layer (AS) running CFC/SFC charts compiled into the S7-400 CPU, and the OS layer (WinCC) running the supervision graphics and archive system. Between them sits a set of interface blocks that are generated automatically by the CEMAT engineering tool whenever you change the project structure. These generated blocks are written by the engineering system with the author tag ES_MAP.

The typical failure pattern reported in the field looks like this:

• A solid or flashing red "F" (Fault) icon appears in the CEMAT supervision overview, normally in the area overview or motor overview faceplate.
• The "Consumers of group" popup in the group display is empty or shows broken references.
• The CPU diagnostic buffer logs entries referring to FC1061 and FB1010 (FB1010 = CEMAT group block), sometimes with OB121 / OB122 fault indications.
• The S7 program blocks whose AUTHOR attribute equals ES_MAP are missing, inconsistent, or refer to deleted instances.
• Charts beginning with @ exist in the S7 program but contain stale or partial logic.

The root cause is rarely the S7 hardware and almost always an inconsistent state between the CEMAT master data library, the project-specific instance DBs, and the OS server packages.

2. Root Cause Analysis

2.1 What "ES_MAP" really means

Every CFC block in a PCS 7 project carries an AUTHOR attribute that identifies who created it. Three values dominate in CEMAT V7.1:

If you ever see a "block not found", "instance DB inconsistent", or "unknown symbol" diagnostic referring to a block authored by ES_MAP, the generation cache of the CEMAT engineering tool is out of sync with the AS program. The mapping blocks were regenerated in the ES but the old versions are still loaded in the CPU, or vice-versa. The red "F" is the OS-level representation of one or more of those instances going into the STOP / fault state.

2.2 What the "@" charts are

CFC charts whose names begin with @ are generated runtime charts. They are created by the CFC compiler whenever you place an instance of a multi-instance block (typical for CEMAT group and driver blocks). They contain the call hierarchy and instance-DB wiring produced at compile time. They are not source charts, and they should never be hand-edited.

The "@" charts can become a problem when:

• A CEMAT block type is upgraded (library patch) but the old @-chart instances are still referenced.
• You copy/paste charts between projects – the @-charts of the source project are pulled in but reference symbols that do not exist in the target.
• The CFC compiler was interrupted (ES crash, power loss) leaving partial @-chart content.

2.3 Why FC1061 and FB1010 specifically

Both blocks are symbols of the underlying ES_MAP inconsistency, not the root cause. Treating them in isolation (e.g. forcing a value via the watch table) only masks the fault.

3. Diagnostic Procedure

Before changing anything in the project, capture the current state. CEMAT V7.1 does not have a single "consistency check" button – you assemble the picture from several tools.

3.1 Inspect the CPU diagnostic buffer

1. In SIMATIC Manager, right-click the AS → Target System → CPU Messages / Diagnostic Buffer.
2. Filter for entries containing FC1061, FB1010, OB121 (Programming error), and OB122 (I/O access error).
3. Note the date/time of the first occurrence – this usually points back to the last AS download or library upgrade.

3.2 Inspect block consistency in NetPro / HW Config

1. Open HW Config and verify the CPU order number matches the CEMAT V7.1 compatibility list (typical: 6ES7414-3EM07-0AB0 or higher).
2. In NetPro check that all connection partners (AS-OS couplings) compile cleanly – a warning here usually explains why "Consumers of group" cannot be resolved at OS runtime.

3.3 Look at the block headers directly

In the S7 program, open any block that is named in the diagnostic buffer. The block header inspector (right-click → Object Properties) shows the AUTHOR and the FAMILY. If you find:

• AUTHOR = ES_MAP and the block has a newer timestamp than the rest of the program, the mapping cache was regenerated.
• AUTHOR = ES_MAP and the timestamp is older than the FB1010 call site, the CPU is running stale code.

3.4 Cross-check the OS server packages

Open WinCC Explorer on the OS server and run Server Data → Compile OS. If the compiler reports "Variable not found in S7 program" for any CEMAT tag whose name starts with @, the OS server package is referencing blocks that no longer exist in the AS.

4. Resolution Path A — Archive, Clean, and Full Recompile

This is the canonical recovery for an ES_MAP / @-chart mismatch in CEMAT V7.1. It is destructive but reversible from the archive you just created.

4.1 Archive the project

1. In SIMATIC Manager: File → Archive.
2. Choose the entire multiproject (S7 program, OS, source files).
3. Store the archive on a network share that is not the ES hard disk – ES disk failures are common during long compile runs.

4.2 Delete the generated @ charts

1. Open the S7 program in the component view.
2. Select all charts whose name starts with @ (use the search filter Name: @*).
3. Right-click → Delete. Confirm that CFC allows the deletion; if any @-chart is "in use", close the chart, save the S7 program, and retry.
4. Repeat for the OS source files (right side of the component view).

4.3 Delete ES_MAP blocks

1. Open the Blocks container of the S7 program.
2. Switch to the offline view.
3. Right-click → Object Properties on each suspect block, verify AUTHOR = ES_MAP, then delete.
4. Pay particular attention to FBs whose number is in the CEMAT mapping range (typically FB900–FB1099 in a default CEMAT V7.1 project) and to instance DBs whose names match those FBs.

For bulk deletion of ES_MAP blocks you can use the SFC tool:

This calls the Siemens SFC Bulk Tool (s7wb27a) that ships with the PCS 7 Engineering Toolset. Always run a dry-run first without the /force flag and inspect the resulting CSV log.

4.4 Full recompile of the S7 program

1. In the CFC editor: Options → Chart Check → Compile (entire program).
2. When prompted, allow the compiler to regenerate every @-chart.
3. Confirm that the compiler finishes with 0 errors and 0 warnings. A warning about "unconnected pins" is acceptable; an error is not.
4. In SIMATIC Manager: PLC → Compile and Download Objects → choose Compile only for this pass.

4.5 Full recompile of the OS project

1. Open WinCC Explorer on the OS server.
2. Server Data → Compile OS. Choose Complete recompile, not incremental.
3. Verify the compiler output for "new variable created" vs. "variable already exists" — a healthy run produces only the first kind for ES_MAP-generated tags.
4. If the project includes redundant OS servers, repeat the compile on each server before reloading the server packages.

4.6 Download to the AS

1. Bring the AS to STOP.
2. From SIMATIC Manager: PLC → Download.
3. Select Entire program (not "Download to target device only") so that ES_MAP blocks are replaced cleanly.
4. Restart the CPU (STOP → RUN).
5. Clear the CPU diagnostic buffer and watch it for 10 minutes – it should stay empty.

5. Resolution Path B — Recompile OS and Reload Server Packages

If the AS program itself is clean but the OS layer still shows the red F (typically because "Consumers of group" is empty in the group overview), the problem is on the OS side. Path B is shorter and avoids the AS download.

1. On the ES station: SIMATIC Manager → Options → OS → Compile OS.
2. Wait for "Compile finished without errors".
3. On the OS server: stop the WinCC runtime.
4. Server Data → Load Server Packages → load from the ES path.
5. Restart WinCC runtime.
6. Open the supervision overview and verify the red F is gone and the group consumer list is populated.

6. Handling FC1061 and FB1010 Errors Specifically

FC1061 and FB1010 are the most-cited blocks in CEMAT V7.1 group supervision incidents. Treat them as follows:

6.1 FB1010 (Group block)

• Do not re-instantiate FB1010 by hand. The instance DBs are owned by the @-chart generator.
• If Path A cleared the @-charts and the recompile did not produce a new FB1010 instance for a group that previously had one, check the group definition in the CEMAT engineering tool: CEMAT → Project → Groups → Synchronize.
• Confirm that the group's "Driver list" is non-empty. An empty driver list causes the @-chart to generate a stub FB1010 whose internal status word remains at the initial value 0x0001, which the OS interprets as "fault pending" – hence the red F.

6.2 FC1061 (Driver / mapping FC)

• FC1061 is normally called inside the @-chart of the group block. After Path A, verify in the @-chart that FC1061's input EN is wired to a TRUE constant.
• If FC1061 triggers an OB121, the offending instruction is almost always an indexed access with an out-of-range index coming from the @-chart regeneration. Re-running the full S7 compile (step 4.4) usually fixes it; if it does not, the issue is a corrupted instance DB and a manual regeneration of the DB through CFC is required:

1. Open the affected @-chart.
2. Right-click the instance DB → Instance → Update.
3. Save and recompile the chart.

7. Restoring the "Consumers of Group" View

When the group overview opens but the "Consumers of group" popup is empty, the cause is normally one of three:

1. The driver list of the group has not been re-published after a structural change (renaming a motor, adding a valve). Fix: CEMAT → Project → Groups → Synchronize, then recompile OS.
2. The OS server package on the client is older than the one on the server. Fix: reload the client package (Server Data → Load Server Packages on the client).
3. The WinCC picture @CEMAT_GROUP.EMF references a tag prefix that no longer exists after the @-chart regeneration. Fix: open the picture in Graphics Designer, replace the broken tag link with the new tag name (visible in the WinCC tag management after the OS recompile).

8. When to Escalate to Siemens Support

If Path A and Path B both fail, escalate via the Siemens Industry Online Support portal with a Support Request that contains:

• The complete diagnostic buffer export (CSV) covering the last 48 h.
• The full project archive (use the SIMATIC Manager "Archive with SDBs" option).
• The output of CEMAT → Help → System Information, which lists the exact CEMAT V7.1 build number and the master data library revision.
• A screenshot of the red F faceplate with the diagnostic popup visible.

Reference the relevant Siemens Knowledge Base entries when opening the request:

• Entry ID 109751706 – "CEMAT V7.1: Notes on ES_MAP blocks in CFC" (search the Siemens support portal for the exact ID).
• PCS 7 V7.1 SP3 Service Pack notes, available under 109482539.
• WinCC V7.0 SP3 server package documentation: 43453463.

9. Verification Checklist

After applying Path A or Path B, run the following checks before returning the plant to operation:

10. Troubleshooting Matrix

11. Field-Proven Caveats

• Copy/paste between projects is dangerous in CEMAT V7.1. When you copy a chart from an old project to a new one and the new project does not have the same CEMAT master data library revision, the @-charts of the copied chart reference blocks that do not exist in the target. Recreate the chart in the target from the CEMAT template, never copy it.
• Library upgrades are not backward compatible. If you upgrade the CEMAT master data library mid-project, expect ES_MAP blocks to regenerate with a new internal layout. Plan an AS download window – running an AS with a mixed set of old and new ES_MAP blocks produces exactly the symptoms described in this article.
• Force / skip on a single block hides the problem. Setting a force on an instance DB of FB1010 may clear the red F on screen but the underlying inconsistency remains and will resurface on the next CFC compile.
• CEMAT V7.1 is end-of-life. Plan a migration to CEMAT V9.x on PCS 7 V9.0 or to the current version on the Siemens platform. The CEMAT V7.1 SP3 master data library is no longer maintained and the issues documented here cannot be expected to disappear with future SPs.
• Picture-level tag renames propagate silently. If you rename a CEMAT driver in the AS but forget to recompile the OS, the group picture keeps the old tag prefix and shows "no consumers" without raising any compile error in WinCC.