Resolving WinCC OS Project Editor Process Tags Warning

Problem Overview

Engineers running a WinCC OS (Operator Station) compile inside the SIMATIC Manager — most commonly inside a SIMATIC PCS 7 multiproject — frequently encounter the following entry in the compile log:

*** Warning(s) ***: Because the OS project editor was not started, the process tags in the block list could not be created. Please start the OS project editor for the relevant OS.

The operator observing the warning typically reports that all visible HMI tags and alarms are nevertheless produced: WinCC still creates the tag table, the alarm logging database is filled, and the OS server can be started. The warning nevertheless repeats on every compile and is a strong indicator that a key step in the PCS 7 compile chain has been skipped. When the OS is later downloaded to a server, missing or stale process tags surface as runtime "Tag not connected" alarms, as messages without acknowledgement bits, or as 0xFFFF placeholder values in faceplates. Over time, the inconsistency can lead to silent failures in operator actions, because a control tag that is missing from the WinCC tag set rejects operator input without raising an error in the HMI.

Technical Context: Anatomy of the Warning

The warning string can be decomposed into three independent statements. Each one identifies a different link in the OS compile chain and a different recovery action. Reading the warning as a chain rather than as a single sentence is the key to choosing the right fix.

Read in sequence, the warning is a chain: no OS Project Editor run → stale DTL → no process tags generated. The fact that some tags nevertheless appear in WinCC is a side effect of three independent facts: WinCC re-reads the binary .pdl configuration from the OS database on every compile, the OS Project Editor only overwrites entries it has source data for, and any tag that has been touched manually through WinCC Explorer persists. The visible tag set is therefore a mix of project-correct tags, stale tags from previous OS Project Editor runs, and hand-edited tags — none of which is a reliable indicator that the OS Project Editor has been run. The only reliable indicator is the modification timestamp of the OS.ed object in the STEP 7 database.

The OS Project Editor

The OS Project Editor is the central PCS 7 configuration utility for OS-side parameters. It is invoked from the SIMATIC Manager on a WinCC OS object via the context menu "Open Object > OS Project Editor" or the toolbar icon. It is the only tool that writes the OS.ed change-set into the project's STEP 7 database and therefore the only tool that the CFC compiler inspects to determine whether the OS has been "configured for this revision of the S7 program".

The OS Project Editor covers five configuration domains that are relevant to process tag generation. Each domain is a separate page in the editor's wizard view. Each page must be applied before the corresponding configuration is written to the STEP 7 database.

1. Operator area / hierarchy assignment — Maps S7 program folders (CFC chart folders) to OS areas and picture hierarchy nodes. The default action is "Operate and monitor", which means the charts in the folder are visible and operable from this OS. The alternatives are "Display only" (visible but not operable) or "Do not operate and monitor" (hidden from the OS). A folder that is set to "Do not operate and monitor" produces no process tags for the charts inside it, even if the charts contain OS-relevant block instances.
2. Message configuration — Defines message classes, message priorities, and acknowledgement behavior for the alarms generated from the block list. The default message classes are Alarm_High, Alarm_Low, Warning_High, Warning_Low, Tolerance, Process, Status, and Operator Request. The OS Project Editor maps each CFC block type to a message class based on the block's "Message class" attribute.
3. Tag groups — Bundles process tags into WinCC tag groups for archive and trend configuration. Tag groups are also the input to the WinCC user archive configuration. The OS Project Editor's tag group page is the page that actually populates the DTL by computing which block instances in each folder are OS-relevant and which signals of each block instance should become process tags.
4. Authorization levels — Maps operator authorizations (operator, supervisor, process operator, etc.) to picture and tag permissions. Authorization levels are configured globally in WinCC Explorer under "User Administrator" and assigned to individual OS areas in the OS Project Editor. Authorization levels do not affect tag generation but do affect which operator can write to which tag at runtime.
5. Picture hierarchy & faceplate layout — Specifies the OS picture tree and the default faceplate used for each block type. The picture tree is the directory structure that WinCC Explorer shows under "Graphics" and the structure that the operator sees when navigating the OS. The faceplate layout is the default set of widgets that the OS uses for each block type (PID controller, motor, valve, etc.).

When the user clicks "Apply" or "OK" at the bottom of the OS Project Editor, the configuration is written to the STEP 7 database as an OS.ed object. From that point onward, the CFC compiler treats the OS as configured and emits the DTL into the OS database on the next compile. The OS.ed object carries a modification timestamp that the compiler compares against the modification timestamp of the S7 program; if the S7 program is newer than OS.ed, the compiler produces the warning.

The Block List and the Process Tag

The block list in the warning text refers to the PCS 7 internal "S7 Block List" — a cross-reference between the S7 program (CFC charts, SFC charts, and the S7 symbols) and the WinCC tag namespace. It is the input to the WinCC tag generator. The block list is not a single file; it is a virtual view of the S7 program computed by the CFC/SFC compiler at the start of every OS compile, materialized as the Derived Tag List (DTLxxx.bin) inside the OS project folder.

Three classes of S7 data end up in the block list:

The DTL is regenerated by the CFC/SFC compiler at the start of every OS compile, but only for those block instances that the OS Project Editor has previously marked as "OS-relevant". When the OS Project Editor has never been run, the DTL is either empty or contains stale entries pointing to block instances that no longer exist in the S7 program. The tag set that WinCC then generates is therefore either empty (in the worst case) or a mix of correct and stale tags (in the case of a previous OS Project Editor run that has not been re-applied).

The DTL carries a version number that is incremented on every regeneration. WinCC compares the DTL version number against the OS database version number and refuses to apply a DTL that is older than the OS database. This is a safety mechanism that prevents a partially updated OS from being downloaded. The OS Project Editor warning is the upstream indicator that the DTL version number has not been incremented for this compile cycle.

Root Cause Analysis

The warning has one primary cause and several secondary triggers that produce the same effect. Each trigger is documented below with the diagnostic that confirms it.

Primary cause

The OS Project Editor was not run — or not applied — in the current engineering session. The compiler cannot fabricate the configuration of an OS that no one has told it to configure. This is the most common cause and accounts for the majority of the support cases for this warning.

Secondary triggers

• OS Project Editor was started, but the user closed it with the "Cancel" button. Cancel discards the configuration and does not write OS.ed. The diagnostic is to look at the modification timestamp of OS.ed: it will be older than the timestamp of the S7 program. Recovery is to re-open the OS Project Editor and click "Apply" or "OK".
• OS Project Editor ran, but the user changed the OS assignment of a CFC chart folder to "Do not operate and monitor". The compiler sees no OS-relevant objects in that branch and treats the OS as effectively unconfigured for that branch, which can produce the same warning at the project level. The diagnostic is to look at the "Operator area" page of the OS Project Editor and verify that every CFC chart folder is set to "Operate and monitor" or "Display only".
• The OS is detached from its master data library (MDL) or from the master recipes library (MRL) and the user disabled OS Project Editor propagation. The OS Project Editor refuses to run against a detached OS and the warning is produced on every compile. The diagnostic is to open the project properties in PCS 7 Plant View and verify that the OS is attached to a master data library.
• The PC station has been replaced or the SIMATIC PC station import has not been re-applied after a WinCC upgrade. The OS Project Editor refuses to write to an OS whose @Config PC station does not match. The diagnostic is to open the PC station configuration in NetPro and verify that the PC station name and the WinCC application name match the values in the OS object.
• An unauthorized editing of the OS database was performed directly in WinCC Explorer, then reverted. The OS.ed timestamp is now older than the WinCC database modification time and the compiler assumes the OS Project Editor has not been re-validated. The diagnostic is to compare the timestamps of OS.ed and the OS database file <OS name>.df.
• The S7 program was edited by a third-party tool that did not update the OS.ed timestamp. Some third-party tools (e.g. CFC chart importers) modify the S7 program directly without invoking the OS Project Editor. The diagnostic is to run the OS Project Editor manually after any third-party edit.

Compile Pipeline Diagram

The compile chain in PCS 7 can be visualized as a sequence of four tools, each of which must complete successfully before the next is started. The OS Project Editor sits at the front of the chain: it is the gate that decides whether the chain runs at all.

Reading the diagram left-to-right: the OS Project Editor must write a fresh OS.ed first; only then will the CFC/SFC compiler regenerate the DTL; the S7 program compile then embeds the DTL into the STEP 7 database; finally, the OS compile reads the embedded DTL and generates the WinCC tag set. If the OS Project Editor is skipped, the chain breaks at the first step and the warning is produced at the last step, even though every tool in the middle completes successfully.

Diagnostic Procedure

Use the following procedure to confirm that the OS Project Editor output is missing or stale before applying a fix. The procedure is read-only; it does not modify the project.

1. Open the SIMATIC Manager and navigate to the WinCC OS object inside the S7 program.
2. Right-click the OS object and choose "Object Properties". Inspect the "Last modified" timestamp of the embedded OS.ed entry. If the timestamp is older than the timestamp of the S7 program folder containing the CFC charts, the OS Project Editor output is stale.
3. Right-click the OS object and choose "Open Object > OS Project Editor". Note whether the dialog opens with the configured values from the last session, or whether it opens blank. A blank dialog confirms the OS Project Editor has never been applied.
4. Open the WinCC Explorer of the OS and look at the "Tag Management > AS / S7 Tags" tree. If the tree shows only the system tags (those starting with @) and no user-defined process tags, the DTL was not produced.
5. Open the OS compile log. The full path is <Project path>\wincproj\<OS name>\<OS name>.log. Search for OS.ed and for the DTL filename DTLxxx.bin. A missing DTLxxx.bin line confirms the DTL was not produced.
6. Capture the compile output line "*** Warning(s) ***" and the lines immediately preceding it. PCS 7 emits a per-OS warning block; reading the context reveals whether the warning belongs to a single OS in a multiproject or to every OS.
7. Open the OS project folder on disk and check the size of the file <OS name>.ed. A file size of 0 KB indicates the OS Project Editor was never applied. A file size of a few KB indicates it was applied at least once.

If step 4 shows that user tags do exist in WinCC Explorer, they were either created manually or carried over from a previous OS compile. The presence of tags is therefore not a reliable indicator that the OS Project Editor has been run; only the OS.ed timestamp and the file size are reliable.

Solution Path 1: Standard OS Project Editor Application

This is the canonical and recommended procedure. It is the only path that produces a consistent, reproducible DTL across a multiproject. The procedure is described in the SIMATIC PCS 7 OS Project Editor help shipped with the engineering software; the steps below are an engineering-focused workflow based on that help.

Prerequisites

• Log in to the engineering station with a Windows account that is a member of the local SIMATIC HMI group.
• All S7 programs in the multiproject must have completed a successful compile (CFC + SFC) before the OS compile is started.
• No WinCC Runtime is running on the engineering station. A running OS locks the OS database and the OS Project Editor refuses to write.
• The OS object must be assigned to a PC station in PCS 7 Plant View. The PC station must be configured in NetPro and the WinCC application must be assigned to the OS object.

Step-by-step

1. In SIMATIC Manager, select the WinCC OS object.
2. Right-click and choose "Open Object > OS Project Editor".
3. If the editor opens with a wizard view, click "Next" to reach the configuration pages. The first page is typically the Operator area / hierarchy page.
4. On the Operator area page, verify that every CFC chart folder that should be operated and monitored is assigned to an OS area. The default action is "Operate and monitor".
5. On the Message configuration page, accept the default message classes (Alarm_High, Alarm_Low, Warning_High, Warning_Low, Tolerance, Process, Status) or assign the project-specific message classes.
6. On the Tag groups page, click "Apply" to allow the OS Project Editor to compute the proposed tag group layout. This computation is the step that actually populates the DTL.
7. On the Authorization page, assign operator authorizations to the operator areas.
8. On the Picture hierarchy page, accept the default picture tree.
9. Click "Apply" at the bottom of any page to apply only the current page, or click "OK" to apply all pages and close the editor.
10. Wait for the OS Project Editor to finish writing OS.ed to the STEP 7 database. A progress dialog displays the percentage complete.
11. Re-run the OS compile via "OS > Compile" in SIMATIC Manager.

Solution Path 2: Manual Configuration Without the OS Project Editor

The OS Project Editor is the recommended path, but it is not strictly required to compile an OS. The compiler accepts a hand-built OS configuration if and only if the DTL has been written by some other means. The most common alternative configurations are described below.

2A. Import a DTL from a reference OS

If the project is a clone of a working reference project, the engineer can copy the DTL files from the reference OS into the new OS before the first compile. The DTL files live in <Project path>\wincproj\<OS name>\<OS name>\GraCS as DTL_*.bin. The compiler adopts the imported DTL and skips the warning. This approach is documented in the SIMATIC PCS 7 Engineering Manual as a recommended procedure for cloning reference projects.

2B. Build the OS entirely in WinCC Explorer

For a small stand-alone WinCC V7 project, the engineer can bypass the OS Project Editor entirely by creating the WinCC tags and alarms directly in WinCC Explorer, with absolute addressing in the Tag Management. The S7 program must then use WinCC-readable shared DBs and the tags must be added with Hand-Added checked in the Tag Management. The OS Project Editor warning still appears in the log, but the resulting WinCC tag set is correct because it does not depend on the DTL.

2C. Use the WinCC Tag Simulator

The WinCC Tag Simulator (WinCC Tag Simulator.exe) is sometimes proposed as a workaround, but it is a runtime test utility, not a configuration tool. It cannot be used to suppress the compile warning. Mentioned here only to head off the recurring question.

Solution Path 3: Suppressing the Warning Without a Configuration

Two mechanisms are sometimes proposed to silence the warning. Both are documented here for completeness, but neither is recommended.

• Disable the OS Project Editor warning in the compile log filter. The compile log filter is configured under "Options > Settings > Compile/Check" in SIMATIC Manager. Disabling the filter hides the warning but does not create the missing DTL. The runtime behavior is identical to a project that has never been configured.
• Replace the OS with an empty OS object. An empty OS produces no process tags and no warning. This is a workaround for projects that do not yet have any CFC charts; it is not applicable to a fully configured project.

Full Recompile Workflow

Use the following workflow to clear the warning and produce a consistent, downloadable OS. The workflow is the standard PCS 7 recompile procedure and is documented in the SIMATIC PCS 7 Operator Station manual.

1. Close every WinCC application on the engineering station: WinCC Explorer, WinCC Runtime, Graphics Designer, Alarm Logging, Tag Logging, User Administrator, and the OS Project Editor itself.
2. Open the S7 program in SIMATIC Manager and run "Charts > Compile". Wait for the CFC / SFC compiler to finish.
3. Right-click each WinCC OS in the multiproject and run "Open Object > OS Project Editor". Apply all five pages as described in Solution Path 1.
4. Re-run the S7 program compile to embed the OS Project Editor output into the STEP 7 database.
5. Right-click the OS and choose "OS > Compile". In the compile dialog, select "Entire OS with memory reset". This is the same option referenced as "entire compile with memory reset" in the standard remedy.
6. Wait for the compile to finish. The compile log closes with a "*** End of Compile ***" marker.
7. Open the compile log and confirm that the line "*** Warning(s) ***" is absent or contains only warnings that are not related to the OS Project Editor.
8. Repeat for every OS in the multiproject.

Compile options reference

Verification and Validation

After the recompile, perform the following checks to confirm that the OS configuration is consistent. Each check is independent and verifies a different aspect of the configuration.

1. Open the OS in WinCC Explorer. Expand "Tag Management > AS / S7 Tags" and confirm that the number of tags in the tree is in the expected order of magnitude for the project. A project with 50 CFC charts and 3 process tags per chart should have roughly 150 process tags.
2. Open "Alarm Logging" and confirm that the number of messages is non-zero and matches the number of message-capable signal references in the CFC charts.
3. Open the OS project folder on disk and confirm that the file <OS name>.ed exists and that its modification timestamp is newer than the modification timestamp of the S7 program folder.
4. Open the CFC charts in the S7 program and confirm that every chart marked "OS-relevant" appears in the OS project tree under the correct area.
5. Start the OS in simulation mode ("Start > Simulation" in WinCC Explorer) and confirm that the faceplates open with live values, not 0xFFFF placeholders.
6. Open the compile log and search for the substring "OS.ed". A successful compile produces exactly one OS.ed write line per OS, immediately followed by a DTL generation line.

Related Warnings and Errors

The OS Project Editor warning is one of several compile warnings in the same family. The table below lists the warnings that share the same code path and provides the recommended response for each. All warnings are documented in the SIMATIC PCS 7 help system; see the SIMATIC PCS 7 documentation portal for the full list.

Troubleshooting Matrix

The matrix below is a quick-reference for the most common engineering scenarios that produce the warning, with the corrective action for each.

Platform-Specific Notes

PCS 7 V9.x with WinCC V7.5

The OS Project Editor is functionally identical to PCS 7 V8.x but adds a "Bulk Engineering" view that allows the engineer to apply the same configuration to multiple OS objects in a single pass. The warning is still produced if any of the selected OS objects has not been applied. The "Bulk Engineering" view is documented in the SIMATIC PCS 7 V9.0 help under "OS Project Editor > Bulk Engineering".

PCS 7 V8.x with WinCC V7.4 SP1

PCS 7 V8.x is the most common platform that produces the warning in field installations. The fix procedure is identical to the procedure described in Solution Path 1; the only platform-specific note is that the wizard view in V8.x uses different page labels than V9.x.

WinCC V7.x stand-alone

Stand-alone WinCC V7.x projects that are not part of a STEP 7 coupling do not produce the warning, because the OS Project Editor is not part of the stand-alone toolchain. The warning is specific to projects that are opened inside SIMATIC Manager. Engineers who encounter the warning in a stand-alone WinCC project have typically opened a PCS 7-generated project file in stand-alone WinCC; the fix is to open the project in SIMATIC Manager and run the OS Project Editor there.

TIA Portal WinCC Professional / Comfort / Advanced

TIA Portal uses the integrated "Compile" workflow. The OS Project Editor does not exist in TIA Portal and the warning is never produced. The equivalent in TIA Portal is the "Compile > Software (rebuild all)" step, which performs the same role of generating the HMI tags from the S7 program. TIA Portal also offers an "HMI tag table" view that is the equivalent of the WinCC Tag Management tree.

WinCC Unified (TIA Portal)

WinCC Unified uses a different compile path. The OS Project Editor is not part of WinCC Unified. The warning is therefore not applicable to WinCC Unified projects. WinCC Unified uses a GraphQL-based tag subscription model that does not require a static DTL.

Performance Considerations

The OS Project Editor's DTL computation can be slow on large projects. The following rules of thumb apply on a typical engineering station (Intel Xeon E3-1270 v6, 16 GB RAM, SATA SSD):

On very large projects, the OS Project Editor can be split into multiple passes by running it on individual OS areas. The Bulk Engineering view in PCS 7 V9.x parallelizes the computation across multiple CPU cores and reduces the runtime on a 4-core engineering station by a factor of 2-3.

Preventive Measures

Three procedural measures prevent the warning from reappearing after the first fix.

1. Add the OS Project Editor to the project's check-in procedure. Any change to the S7 program that adds, removes, or renames a CFC chart should be followed by a mandatory OS Project Editor pass before the OS compile. The check-in procedure should include a step "Run OS Project Editor and confirm '0 warnings' in compile log".
2. Enable the "Check OS Project Editor timestamp" check in the project settings. The check is in "Options > Settings > Compile/Check" in SIMATIC Manager. When enabled, the compiler refuses to start the OS compile if the OS Project Editor is stale, and it produces a hard error instead of a soft warning. This converts the warning into a hard error and prevents the OS from being downloaded in a stale state.
3. Use the "Standard project" template. The standard project template supplied with PCS 7 includes a fully configured OS Project Editor, so a project created from the template will not produce the warning on first compile. Custom project templates should follow the same pattern.

FAQ