WinCC V7 OS Project Editor: Resolving Start-up Page Conflicts

Overview

Siemens WinCC V7 includes the OS Project Editor, a configuration tool that auto-generates a complete suite of runtime graphics when an S7 station is imported into a WinCC project. The tool is intended to remove repetitive manual setup work: it writes standardized header, footer, alarm line, and keyset pictures, populates the picture tree, creates the area hierarchy, and assigns button sets. The trade-off is that the editor takes ownership of those generated files (all prefixed with the @ character) and re-writes them every time the configuration is regenerated. Engineers who try to set the start-up picture through the conventional Computer Properties > Graphics Runtime > Start Picture path discover that any local PDL they pick is overridden, and any manual edits made to the header or footer pictures are silently discarded on the next regeneration.

This reference explains exactly which files the OS Project Editor controls, why the conventional start-up picture dialog stops working once the editor has been run, and the supported options for either working with the generated templates or abandoning the editor in favor of manual configuration. A short comparison with the WinCC Unified V20 start-screen workflow is included for engineers migrating newer projects.

How the OS Project Editor Structures Runtime Graphics

The OS Project Editor writes a fixed set of files into the project's GraCS folder. The most relevant for start-up behavior are:

The complete list of files transferred to GraCS on each regeneration is also written to WinCCProject\SSM\ProjectEditor.txt. Open this text file after every OS Project Editor run to verify which pictures the tool considers its own. The convention is: any picture whose name begins with @ belongs to the editor, and the runtime window-manager treats those pictures as the project standard. Selecting a non-@ picture as the start picture does not remove the generated templates; it only changes which picture loads first, and on the next regeneration the editor will not add the new picture into the start position.

Problem Details

Symptom 1 — Start picture dialog appears to be ignored. The engineer opens Computer Properties > Graphics Runtime > Start Picture, browses to a custom PDL, confirms with OK, and the change is written to the registry key HKLM\SOFTWARE\WOW6432Node\Siemens\Automation\WinCC\RT\[ComputerName]\StartPicture. The change persists in the project database. However, on the next OS Project Editor run (often triggered by a PLC re-import, an AS-OS compile, or a manual OS > Project Editor invocation), the editor writes its own @Main.pdl reference into the runtime start-up sequence and the engineer's selection is functionally bypassed.

Symptom 2 — Header and footer customization disappears. Custom buttons, company logos, additional alarm widgets, or status indicators added to @Header.pdl or @Footer.pdl survive until the next regeneration cycle, at which point the editor overwrites the file. The original engineering changes are not backed up by the tool; the previous version is moved aside only if the engineer created a manual copy in GraCS beforehand.

Symptom 3 — OS Project Editor inactive but templates remain. Even after the engineer decides to stop using the OS Project Editor, the previously generated @*.pdl files remain in GraCS. Any future change to the start picture through Computer Properties is honored at runtime, but the header and footer visible on the new start screen are still the editor-generated versions, which can look out of place if the engineer also added new user-defined pictures with a different visual theme.

Root Cause Analysis

The conflict is by design. The OS Project Editor implements a declarative project model: when the engineer supplies S7 area, hierarchy, and unit data, the editor compiles a closed set of templates that are guaranteed to match the imported AS structure. To keep that guarantee, the editor enforces three rules internally:

1. Ownership of @-prefixed files. The editor treats every @*.pdl in GraCS as its own buffer space. Any non-editor file is left alone, but every editor-controlled file is rebuilt from the source templates on each run.
2. Single source of truth for the start sequence. The runtime Welcome > Login > Process sequence is hard-coded to start at @Welcome.pdl, transition to @Main.pdl after login, and inherit @Header.pdl and @Footer.pdl as templates attached to every screen. The Start Picture field in Computer Properties is honored only if the project has not been touched by the editor since the last project close.
3. Regeneration is idempotent but destructive. Running the editor a second time with the same input produces a byte-identical output except for any user edits made to the generated files between runs; those edits are lost.

Consequence: a custom start picture can coexist with the editor only if the picture is also a template-managed file, which means the engineer must rebuild the customizations as editor-compliant modifications, not as one-off .pdl files dropped into GraCS.

Affected Versions and Project Layout

The behavior described applies to WinCC V7.0 through V7.5 SP2, including the PCS 7 V8.x and V9.x OS stations built on top of WinCC V7. Newer Unified RT projects follow a different model, summarized in the comparison section below.

The relevant on-disk layout for a single-server OS project is:

<ProjectPath>
├── GraCS\                 <-- runtime graphics folder (PDL, EMF, BMP)
│   ├── @Welcome.pdl
│   ├── @Main.pdl
│   ├── @Header.pdl
│   ├── @Footer.pdl
│   ├── @Buttons11.pdl
│   ├── @AlarmLine.pdl
│   └── <user pictures>.pdl
├── SSM\                   <-- OS Project Editor working folder
│   └── ProjectEditor.txt  <-- list of generated files
├── Library\               <-- shared WinCC library
└── <ProjectName>.mcp      <-- multi-project coordinator file

Solution: Three Valid Paths

There is no patch that lets a custom start picture survive an OS Project Editor regeneration. Pick one of the three supported paths before commissioning the OS station.

Path A — Replace the editor-generated start picture by editing @Main.pdl

Use this path if the project is already configured through the OS Project Editor and you want to keep the area hierarchy, picture tree, and keyset logic intact, but want a different first process screen.

1. Close WinCC Explorer on the engineering station.
2. Make a manual backup of the current @Main.pdl file (e.g., @Main.pdl.bak) inside GraCS.
3. Open @Main.pdl in the Graphics Designer. Edit it as a normal picture: add your custom widgets, change the start position, attach your process picture objects.
4. Save and close. Do not invoke OS > Project Editor > Generate again until you have verified the runtime behavior; the regeneration will overwrite this file.
5. Start WinCC Runtime and confirm the picture loads as expected. Document the regeneration lockout in the project change log.

Path B — Customize the header and footer, then lock them

Use this path if your problem is specifically the disappearance of custom buttons in the footer or status fields in the header.

1. Make a working copy of @Header.pdl and @Footer.pdl outside the project tree (e.g., C:\Engineering\Templates\).
2. Edit the copies in Graphics Designer to add the required buttons, alarm widgets, company logo, or status indicators.
3. Copy the modified files back into GraCS and remove the .bak copies.
4. Set the file-system attributes: attrib +R @Header.pdl @Footer.pdl.
5. Run the OS Project Editor once more and confirm the editor reports the file as locked. The editor writes a warning to SSM\ProjectEditor.txt listing the read-only files it skipped.
6. Lock the engineering workstation's ACL so production users cannot remove the read-only attribute.

Path C — Disable the OS Project Editor and use manual configuration

Use this path for greenfield projects where the editor's automation is not needed. The start picture dialog will then behave normally.

1. Open WinCC Explorer and navigate to OS > Project Editor.
2. Open the editor once and clear every checkbox on every page (Hierarchy, Area, Units, Pictures, Keysets, Alarm Line, Message Configuration).
3. Click Generate with all checkboxes cleared. This produces an empty regeneration pass; the existing @*.pdl files remain but are no longer considered "editor-managed" by the regeneration engine.
4. Delete the editor-generated @*.pdl files you do not need, and back up the rest under a different prefix (e.g., [email protected]) so they are visually identifiable as "kept but no longer regenerated."
5. Open Computer Properties > Graphics Runtime and set the desired start picture. The change is now persistent across WinCC restarts.
6. Build header and footer templates as fresh .pdl files (no @ prefix) and reference them from Computer Properties > Templates.

Customizing Header and Footer Templates Safely

Whether you are on Path A, B, or C, the header/footer behavior is the same: they are loaded as templates into every picture window that does not override Own Template in its properties. The template property is read on picture-open, so template changes propagate without rebuilding the calling picture. This is also why a regeneration that overwrites @Header.pdl instantly changes every screen.

Field-proven header customizations that survive a regeneration cycle only if implemented through the editor's supported field set:

For custom widgets or third-party ActiveX controls in the header or footer, set the calling picture's Own Template = Yes and select a manually maintained PDL. This localizes the customization to that picture and prevents a regeneration from dragging the new widget into other screens.

Comparing WinCC V7 to WinCC Unified V20

Engineers moving from PCS 7 / WinCC V7 to the WinCC Unified line will notice that the start-screen model is different. In WinCC Unified V20, the start screen is set through the device's runtime settings rather than through computer properties. The official Siemens documentation describes the procedure as follows:

Click on the Runtime settings of the device in the project tree. Select the start screen under General > Screen. Click Define as start screen.

For the full TIA Portal V20 procedure, see the Defining the start screen (RT Unified) reference page in the Siemens documentation portal. The Unified model is fundamentally different:

Engineers maintaining both V7 and Unified fleets should keep the start-screen configuration paths in their handover documentation — the V7 path through Computer Properties is not the Unified path, and vice versa.

Verification Steps

After applying any of the three solution paths, run the following checks before handing the OS station over to operations:

1. Start-up picture check. Launch WinCC Runtime in simulation mode (Start > WinCC Runtime). Verify that the configured picture loads first, and that header and footer are visible.
2. Login transition check. Confirm that after successful login the runtime transitions to @Main.pdl (V7) or the configured main screen (Unified), and that all area-selection buttons in the header are populated.
3. Regeneration dry-run. If you took Path A or B, re-open the OS Project Editor and click Generate once more. Open SSM\ProjectEditor.txt and confirm that the customized @Main.pdl / @Header.pdl / @Footer.pdl files are listed as either skipped (read-only) or accepted for overwrite. Acceptable outcomes: skipped. Unacceptable: silently overwritten with the default template.
4. File-system snapshot. Compare the byte size and CRC32 of each customized @*.pdl against the snapshot taken in step 1 of the solution path. The values must match.
5. Registry / configuration dump. On the OS station, export HKLM\SOFTWARE\WOW6432Node\Siemens\Automation\WinCC\RT\[ComputerName] and verify the StartPicture value matches the intended file. This is the value the runtime reads on boot.
6. Operator sign-off. Have the operator log in twice (once on the engineering station, once on the OS runtime station) and confirm both reach the same start picture.

Troubleshooting Matrix

Field-Proven Caveats

• The SSM\ProjectEditor.txt log is overwritten on each editor pass. If you need an audit trail, copy it to SSM\Archive\ with a timestamp before every regeneration.
• Manual edits to @*.pdl files are preserved across WinCC Explorer close/reopen, but only if the editor is not invoked in between. Train operators to never open the OS Project Editor dialog from a production station.
• If the project includes redundant OS servers, the editor runs on the master project server. Verify which server is the master before troubleshooting regeneration behavior on a redundant pair.
• Do not rename a @*.pdl file to remove the @ prefix. The runtime window-manager uses the prefix to identify editor-managed templates, and a renamed file will not be loaded as a template, breaking every screen that depends on it.
• The OS Project Editor does not validate that the start picture you set in Computer Properties actually exists. A typo silently fails at runtime; the previous picture continues to load. Always verify the file name in GraCS matches the registry value exactly, including case.

FAQ