Resolving Orphaned DP Master Systems in SIMATIC Manager Hardware

Problem Description

Orphaned DP master systems in SIMATIC Manager (STEP 7 Classic) hardware configuration present a stubborn configuration-management problem that is reported across STEP 7 V5.4, V5.5, V5.6, and PCS7 V8.x/V9.x projects. The orphan manifests as a top-level PROFIBUS-DP > DP Master System entry in the project tree that has no parent SIMATIC station and no associated CPU. Engineers encounter the same three symptoms regardless of STEP 7 service pack:

• Right-click on the orphaned DP master shows the Delete option disabled or grayed out. Sometimes a context menu appears but selecting Delete produces no event in the application log and no change in the project tree.
• Selecting an individual slave on the orphan (a DP/PA coupler, a DP/PA link, an ET200PA station, or a single PA transmitter such as a pressure or level device) and right-clicking yields a fully disabled context menu. The Delete option is not only grayed out — it is absent.
• Attempting to Export the hardware configuration aborts with the message: "Your Configuration contains orphaned DP master and/or Profinet IO systems that cannot be exported." The project may use only PROFIBUS, no PROFINET IO, and still fail because the export check is conservative about both bus families.
• Running File > Save As > With Reorganization (slow) can drive the SIMATIC Manager process (S7Proj.exe) into a Not Responding state for an extended period, particularly on PCS7 multi-projects with multiple AS (Automation Station) members.

The typical underlying network in these reports is a Profibus PA segment tied to a DP master that no longer references any station. Pressure and level transmitters (PA profile 3.0, 3.01, 3.02 devices from vendors such as Endress+Hauser, Siemens, Yokogawa, ABB, Rosemount, and Honeywell) are frequent inhabitants of the orphan because they are often configured downstream of a DP/PA coupler or DP/PA link that has been removed during a plant reconfiguration. The PA slaves remain in the project database while the upstream master loses its parent station, leaving the master and all its downstream PA devices stranded.

Root Cause Analysis

Orphaned DP master systems are almost always caused by an incomplete transaction against the S7 project database. STEP 7 Classic persists the hardware configuration in System Data Blocks (SDBs) inside each station's S7HWCONF folder and tracks DP master relationships through a separate project-tree node. If the station deletion, paste, or project merge is interrupted — by a power loss, a forced process termination, a STEP 7 crash, or an operator clicking through a confirm dialog too quickly — the tree pointer is severed but the SDB references linger.

The SDB structure for a PROFIBUS DP master is a self-contained block. SDB 1000 through SDB 1099 typically hold the DP master system definitions, while SDB 2000 through SDB 2099 are reserved for PROFIBUS PA data. When a station is deleted, STEP 7 is supposed to remove the corresponding SDBs; the orphan is the failure mode where the SDBs are retained but the parent station pointer in the project tree is gone. The export utility performs a tree consistency check before writing the .cfg file; an unreferenced master system fails the check and aborts the export with the message above.

Pre-Cleanup Verification

Before attempting any cleanup, capture the current state so that a recovery path exists if the database becomes further corrupted. The cleanup procedures below are reversible only up to the point of the first reorganization pass; after that, the original on-disk state is overwritten.

1. Close SIMATIC Manager completely. Confirm the process is gone via Task Manager. The process names vary by version: CCWin.exe for older managers, S7Proj.exe for STEP 7 V5.5 and later, PCS7.exe for PCS7 engineering.
2. Make a full file-system copy of the project directory. For multi-projects, copy the entire .S7F container including all .S7P members. Place the copy on a separate physical drive if possible.
3. Record the STEP 7 version: Help > About. The fix path varies between V5.4, V5.5, V5.6, and V5.7. PCS7 V8.x and V9.x projects add the multi-project layer and require the multi-project reorganization path in addition to the single-project one.
4. Note the orphaned master's PROFIBUS address and the slave count. Open HW Config > right-click on the orphan > Object Properties to read the master's FDL address, the configured bus parameters (baud rate, Tslot, min TSDR, max TSDR, TTRT, TQUI, TSET, GAP factor), and the list of configured PA slaves.
5. Check Options > PG/PC Interface and confirm the assigned access point. Disconnect any online interface to prevent accidental online SDB overwrites. Setting the access point to None blocks all online traffic.
6. For PCS7: confirm the multi-project is opened from the .S7F file, not from an individual .S7P. Multi-project-level operations are only available from the container.

Solution Path 1: Project Reorganization (Slow)

The canonical SIMATIC Manager recovery function rebuilds the entire project database, normalizing all internal references. This is the first procedure to try on a copy of the project. It is invoked from the File menu and is distinct from the regular Save operation, which only persists incremental changes.

1. Open the working copy in SIMATIC Manager.
2. From the menu, select File > Save As….
3. Enter a new project name and target directory. The default save location should be a local SSD with at least 2 GB free. Avoid network drives; reorganization is single-threaded and any network latency will be amplified across the project.
4. Check the With reorganization (slow) checkbox. This triggers the underlying routine (implemented in s7wbaprx.dll and the database engine in S7DBE.DLL) to walk every database record, validate foreign keys, and rewrite the SDB references.
5. Click OK. The dialog disappears and the SIMATIC Manager window may show a blank state for an extended period — this is normal. Do not click anywhere on the SIMATIC Manager UI; the routine must run to completion without contention.

If the process is genuinely hung, terminate the process, restore the working copy from the archive, and apply the targeted fixes below before attempting another reorganization. Killing the process mid-reorganization leaves the project database in a partially rewritten state that is more difficult to recover from than the original orphan.

After the reorganization completes, open the resulting project, then open HW Config and perform Station > Save and Compile on every station to regenerate the SDBs. Verify the orphan is gone by performing the verification checks at the end of this article.

Solution Path 2: Targeted SDB and Database Cleaning

When reorganization is impractical — because the project is too large, the routine is genuinely hanging, or a specific cleanup is required for a regulated change-control process — surgical removal of the orphan is possible by working with the S7 project database directly. This is the approach that has been field-proven on a PCS7 multi-project with two AS stations where the orphan was attached to the secondary AS.

2.1 Project Structure Reference

Navigate to the project root on disk. A STEP 7 V5.x project has the following layout:

ProjectName.S7P
├── Global
│   ├── 3S_Lang\_Langs.dat
│   ├── Language\_Langs.dat
│   ├── Symbols
│   │   └── S7SymTab.sdf
│   ├── S7gtopx
│   │   ├── S7GTopx.sav
│   │   └── S7GTopx.bak
│   └── S7HCom\_hcom.sav
├── SIMATIC 400(1)
│   ├── CPU 410-ER
│   │   └── S7 Program
│   │       ├── Blocks
│   │       └── Sources
│   └── Hardware
│       └── S7HWCONF
│           ├── SDB 1000.sdb
│           ├── SDB 1001.sdb
│           └── SDB 2000.sdb
├── SIMATIC 400(2)
│   └── ...
└── (orphaned DP master reference, if registered at the project root)

The orphaned DP master's SDBs may live under one of the SIMATIC x00 station folders (typically the AS that previously hosted the DP/PA link or coupler), or they may sit in the root project tree as a free-standing entry that has lost its parent. Search the entire project tree for SDBs whose PROFIBUS master address matches the orphan's FDL address. Use HW Config > DP Master System > Object Properties to read the master FDL address; cross-reference the SDB list against this address using a hexadecimal search in the binary SDB files if the parent cannot be located visually.

2.2 Manual SDB Disassociation

1. Close SIMATIC Manager completely.
2. Make a second file-system backup of the working copy. The first backup is the untouched archive; this is the pre-manipulation backup of the working copy.
3. Open the station's S7HWCONF folder in Windows Explorer. Rename SDBs that reference the orphan to SDB_OLD_<number>.sdb. The format is proprietary — do not edit the file content with a text editor. The SDB file is a binary record with internal length fields; modifying the content will produce a parse error and HW Config will refuse to load the project.
4. Open the project in SIMATIC Manager. The HW Config editor will report a missing SDB and prompt to recompile the station. Accept the recompile.
5. Open HW Config, perform Station > Save and Compile. The compile operation regenerates SDBs based on the in-memory configuration. If the orphan is no longer represented in memory, it is dropped.
6. Close HW Config, then File > Save As > With Reorganization (slow) on a fresh copy to normalize the database and write the cleaned SDB set.

2.3 Identification by Symbolic Name

If the project uses symbolic names for the PA transmitters (typical in PCS7 with the APL — Advanced Process Library), the orphan's slaves are referenced by symbolic name. Open the global symbol table (S7SymTab.sdf in the Global\Symbols folder) and search for the symbolic names of the pressure and level transmitters reported in the orphan. The presence of symbols pointing to an address range that is not assigned to any active AS is a strong indicator of a residual orphan link.

Solution Path 3: PCS7 Multi-Project Recovery

PCS7 multi-projects coordinate individual AS projects through an .S7F container. Orphaned DP masters in PCS7 most often appear at the multi-project container level, not inside any individual AS project. The container holds a Global folder with the multi-project's master symbol table and a Library folder for shared PCS7 libraries. Orphaned references can persist in any of these locations.

1. Open the multi-project in SIMATIC Manager by double-clicking the .S7F file. Do not open an individual .S7P — multi-project operations are only available from the container.
2. Identify which AS project contains the orphan. The orphan's slaves (DP/PA link, ET200PA, individual PA devices) reveal the parent AS by their PROFIBUS address range. Open each AS project's HW Config and compare the bus topology against the orphan's reported master address.
3. Apply the targeted SDB cleanup (Path 2) to the offending AS project, then close the multi-project.
4. Reorganize the multi-project container: File > Multi-Project > Save As with Reorganization. This is distinct from the single-project reorganization; the multi-project operation rebuilds the .S7F cross-references and the global symbol table consistency.
5. Reopen the multi-project and verify by attempting the original export: HW Config > Options > Export. The export error should no longer appear.
6. Run Options > Check Project Consistency on the multi-project. Resolve every reported warning; the orphan will surface here if it is still present in any AS.

Solution Path 4: Cross-Project Migration

When all cleanup paths fail, the nuclear option is to migrate the project into a freshly created S7 project. The new project starts with an empty database; only stations and programs you actively transfer are populated, so orphans cannot be carried over. This procedure is the most reliable fix for projects that have undergone multiple STEP 7 upgrades, partial TIA Portal conversions, or PCS7 version transitions.

1. Create a new STEP 7 project: File > New > Project. Match the target AS count if the source is PCS7. For a PCS7 multi-project, create a new .S7F container first, then add the same number of .S7P AS projects.
2. Open the source project side-by-side in a second SIMATIC Manager instance.
3. For each SIMATIC station: select the station in the source project, Edit > Copy, then in the destination project select the appropriate AS container and Edit > Paste. The station's hardware configuration, S7 program, and connections are transferred.
4. For each S7 program: copy the S7 Program container, including blocks, symbols, and source files. Use Options > Cross-References on every program in the destination to confirm all references resolve.
5. Open the destination project's HW Config, perform Station > Save and Compile for each station.
6. Save the new project, then Save As with Reorganization (slow) to finalize the database.
7. For PCS7: open the new multi-project, run Options > Check Project Consistency, and resolve every warning before declaring the migration complete.

Cross-project migration is the most reliable fix for projects that have undergone multiple upgrades, partial TIA Portal conversions, or PCS7 version transitions. The cost is time: 2 to 6 hours for a typical PCS7 multi-project with two AS and 30,000 tags. The benefit is a clean database with no residual references.

Why "Save As With Reorganization (Slow)" Hangs on Large Projects

Three contributing factors stack to make reorganization slow to a degree that resembles a hang. The user reports in the field report are consistent with these factors, particularly on multi-AS PCS7 projects.

Verification

After cleanup, perform the following checks to confirm the orphan is gone and that the rest of the project remains intact. The verification sequence is ordered from the cheapest check (tree walk) to the most expensive (full project consistency check on a PCS7 multi-project).

1. Tree check: In the project tree, confirm the orphaned DP master system entry is absent. The tree should show only DP master systems that have a parent SIMATIC station.
2. Export check: HW Config > Options > Export. The export must complete without the orphaned-system error. Save the export as a .cfg file for the project archive. The .cfg file is a plain-text representation of the configuration and is human-readable for diffing against historical exports.
3. Compile check: Open each station's HW Config and perform Station > Save and Compile. No warnings about missing SDBs or inconsistent master systems should appear. SDBs are written to S7HWCONF and overwrite the on-disk copy.
4. Consistency check (PCS7): Options > Check Project Consistency. Resolve every reported warning; the orphan will surface here if it is still present. The consistency check walks the multi-project cross-references, the global symbol table, and the SDB ownership graph.
5. Cross-reference check: Options > Cross-References on every S7 program. Any reference to the orphan's address range is a residual link that needs manual purging. Cross-references are computed from the symbol table and the block interfaces; a stale symbol entry will surface here.
6. Offline / Online diff: If a CPU is available, bring the project online, perform PLC > Compile and Download Objects in dry-run mode, and compare the offline SDB set against the CPU's online SDB set. A clean project shows zero differences in the DP master configuration.

Troubleshooting Matrix

Preventive Best Practices

• Always "Save As with Reorganization" after every project merge, station delete, or library import. Treat the reorganization as a commit operation in a version-control workflow. The reorganization pass normalizes the database and surfaces inconsistencies before they become orphans.
• Use versioned backups (incremental or differential) before any HW Config change. PCS7 project files do not have an internal undo history; the on-disk SDBs are the only persistent state. A reliable backup lets you roll back to a known-good project state in minutes rather than days.
• Keep STEP 7 patched. V5.5 SP4 and later include database integrity checks that prevent many orphan conditions. V5.6 added explicit support for orphan cleanup in HW Config for some scenarios. The PCS7 V9.0 SP2 update specifically addressed orphan DP master scenarios in multi-project containers.
• Assign a single PROFIBUS master per AS. Dual-master configurations on a single AS (master + standby) can produce ambiguity that the database sometimes resolves into an orphan. If redundant masters are required, use the S7-400H or AS 410H redundant configuration, which has explicit ownership semantics.
• Document DP master FDL addresses in a project README. When an orphan appears, the address helps identify which station lost ownership and accelerates diagnosis.
• Never interrupt a reorganization. Once the routine is running, do not interact with the SIMATIC Manager UI. Wait for the dialog to close on its own. Clicking the UI forces a re-paint that competes with the single-threaded reorganization routine and can produce a hang.
• Run on a local SSD. Network shares and external USB drives introduce latency that is amplified across the reorganization's thousands of file operations. A local SATA or NVMe SSD with at least 2 GB free is the minimum recommended target.
• Disable AV and indexer on the project directory. Add the project root, the %TEMP%\S7TMP directory, and the SIMATIC Manager installation directory to the antivirus exclusion list. Disable Windows Search Indexer on the project drive letter.
• Use the same STEP 7 version across the team. Mixed-version projects (one engineer on V5.5, another on V5.6) can produce schema mismatches that surface as orphans after a save from the higher-version PG.
• Close all SIMATIC Manager instances before file manipulation. A second instance holding an open handle on the project database will block any direct file-system operation and can corrupt the database if the operation proceeds.

Platform and Version Notes

The procedures above apply to the following Siemens platforms, with the version-specific notes indicated.

PROFIBUS DP master systems configured as DPV0 or DPV1 behave identically with respect to the orphan condition; the issue is at the project database layer, not the protocol layer. DP/PA couplers (passive, non-intelligent) and DP/PA links (active, intelligent, with their own GSD file) both participate in the orphan condition if the upstream master is lost. ET200PA stations are typically connected to a DP/PA link and inherit the orphan from the link's upstream master.

FAQ