Troubleshooting S7-300 CPU 317-2DP HW Config Compile Error After

David Krause17 min read
S7-300SiemensTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Troubleshooting S7-300 CPU 317-2DP HW Config Compile Error After Upload

When an S7-300 station has been in service for years and the engineering team finally needs to upload, modify, or migrate the program, one of the most common failure points is the HW Config compile step. The upload from the CPU appears to complete cleanly, the blocks arrive in the offline project, but as soon as the engineer opens HW Config and triggers Save and Compile, the dialog returns the generic fault "Error in Config" with no actionable text. This article dissects every credible root cause for that symptom on the CPU 317-2DP (and the closely related CPU 315-2DP slave configuration that frequently appears with it), and provides the verification procedure that proves the fix is good before power is restored on the plant floor.

Read before continuing. The S7-300 platform has been announced for end-of-service by Siemens. Maintenance and firmware updates are no longer being issued, so when HW Config corruption cannot be reversed by the procedures below the field-proven answer is often to recreate the station from the original configuration backup. Always take a working copy of the project before applying any of the corrective actions described in this document.

1. Problem Definition

The fault presents as follows:

  • Operator or maintenance engineer uploads the S7 program from a CPU 317-2DP using STEP 7 V5.x (typically V5.3, V5.4, V5.5 or V5.6).
  • Upload reports no errors, all blocks (OB, FB, FC, DB, SFB, SFC, SDB) appear under the S7 Program folder.
  • Engineer opens HW Config, makes any change (or sometimes no change at all) and selects Station > Save and Compile.
  • The compile dialog returns: "Error in Config" (German: Fehler in der Konfiguration), often with no accompanying entry in the diagnostic buffer.
  • The station may continue to run in production while this offline error remains, because the running CPU is unaffected by a corrupt offline configuration.

The error is strictly an offline engineering problem: the production CPU is still executing the last downloaded configuration correctly. The risk appears only when the engineer tries to download an edited configuration and the offline SDBS are not coherent with what the CPU expects.

2. Affected Systems and Firmware Scope

Component Catalog Number (typical) Minimum FW Maximum FW
CPU 317-2DP 6ES7317-2AK14-0AB0 V2.0 V3.3
CPU 317-2DP 6ES7317-2AJ10-0AB0 V1.0 V2.7
CPU 315-2DP (slave) 6ES7315-2AH14-0AB0 V2.0 V3.4
CPU 315-2DP (slave) 6ES7315-2AG10-0AB0 V1.0 V2.7
STEP 7 (SIMATIC Manager) 6ES7810-4CC10-0YA5 V5.3 V5.6 HF8

All CPU 31x-2DP variants that expose a PROFIBUS-DP master or slave interface and all STEP 7 V5.x releases that include the classic HW Config editor can exhibit the symptom. The issue is independent of firmware version; it is caused by inconsistencies between the offline project tree and the System Data Blocks generated by HW Config and NetPro.

3. Root Cause Analysis

The "Error in Config" message from HW Config is a generic exception, not a specific diagnostic code. Each of the following conditions has been observed to produce the same dialog text on real S7-300 stations. Engineers should treat them as a checklist and eliminate them in the order presented.

3.1 System Data Block Corruption

STEP 7 stores the rack layout, module parameters, DP topology and NetPro connection data inside SDB containers (SDB0, SDB1, SDB2, SDB1000+). When the project is uploaded from a CPU that has been edited by a different STEP 7 version, or by a different project structure (for example a multi-project), the offline SDBs may refer to objects that no longer exist in the offline tree. HW Config detects the orphan references and refuses to compile.

3.2 Missing Hardware Configuration in the Upload

Upload via PLC > Upload Station to PG retrieves only the program blocks by default unless the user explicitly selects Upload Station with Hardware Configuration. The result is an offline project that contains the S7 program but no HW Config object. When the engineer opens HW Config, STEP 7 attempts to reconstruct the configuration from the SDBs alone and fails.

3.3 Process Image Boundary Violation on DP Slaves

On the CPU 315-2DP used as a DP slave, input and output modules inside the slave must reside entirely inside the process image (PII/PIQ) or entirely outside of it. STEP 7 V5.3 introduced a stricter consistency check that older versions did not enforce; a station that was originally commissioned under V5.1 or V5.2 may compile cleanly at the time but fail to recompile after upload under V5.4 or V5.5 because one or more I/O modules now straddle the OB1 process image boundary.

3.4 Multi-Project Split

The classic fault described in the original field report involved a master CPU and a slave CPU residing in a STEP 7 multi-project. When the engineer uploads the master CPU only, the slave objects remain as references. HW Config cannot resolve the slave reference and the compile fails. The slave must be uploaded separately and then merged into the multi-project using Options > Multi-Project > Align / Synchronize.

3.5 Version Mismatch Between Master and Slave CPUs

When the DP master is an S7-400 CPU (for example a CPU 414-2DP or CPU 416-2DP) and the slave is an S7-300 CPU 315-2DP, the GSD file referenced by the master must match the slave's module set. STEP 7 V5.3 was the first release to ship the modular slave GSD import that the S7-400 master requires. Earlier GSD files imported under V5.4 or V5.5 can leave unresolved slot references that surface only at compile time.

3.6 Symbolic Name Database Drift

If the offline symbol table contains absolute addresses that point to modules removed since the last compile, HW Config raises the dialog. This is less common but worth verifying before performing destructive actions on the project tree.

4. Diagnostic Procedure

Before applying any fix, capture the following diagnostic data so that the corrective step is reversible.

  1. Archive the project. In SIMATIC Manager, select File > Archive and store the .zip or .ard file on a network share. Never edit the only copy of a working project.
  2. Capture the SDB inventory. In the S7 Program folder, list all SDB blocks. Record their numbers, attributes (SDB0 always present, SDB1 for MPI addresses, SDB2 for module parameters, SDB1000+ for DP slaves) and any visible timestamps.
  3. Enable the STEP 7 diagnostic buffer dump. Connect to the CPU online and select PLC > Diagnostics/Settings > Diagnostic Buffer. Save the buffer to a text file. Look for entries containing SF, OB85, or IO access error; these confirm where the mismatch lives.
  4. Compare the offline and online configuration. Open HW Config with the project online and select Station > Compare Offline/Online. The dialog will highlight modules present in only one of the two trees.
  5. Check the process image boundaries. In HW Config, right-click each module in the DP slave and select Object Properties. On the Addresses tab, verify that the start address plus length either lies entirely inside the configured process image range or entirely outside of it.
  6. Verify the multi-project membership. If the project contains more than one S7 station, open the multi-project container in SIMATIC Manager and confirm that every CPU is present in the tree and is aligned with the master.

5. Solution 1: Regenerate the System Data Blocks

SDB regeneration is the safest first action because it rebuilds the offline System Data Blocks from the current HW Config tree without touching the user program.

  1. Make a working copy of the archived project and open the copy in SIMATIC Manager.
  2. Right-click the SIMATIC 300 Station object and select Open HW Config.
  3. If HW Config opens without complaint, select Station > Save and Compile immediately. The freshly generated SDBs will overwrite any corrupted ones.
  4. If HW Config itself refuses to open, delete the existing SDBs from the S7 Program folder manually. In SIMATIC Manager switch to the Offline view, expand S7 Program > Blocks, select all blocks whose names begin with SDB, right-click and choose Delete. Confirm that the system blocks SFB, SFC, SDB are listed under System Data separately from the user blocks.
  5. Re-open HW Config and run Station > Save and Compile. New SDBs are created automatically and stored back under System Data.
  6. If NetPro is also in use, run Network > Save and Compile as well. NetPro generates its own set of SDBs (typically SDB5, SDB7, SDB8, SDB9 for S7 connections) that HW Config cannot regenerate alone.
Warning. Deleting SDBs in an active multi-project will break references held by other stations. Always perform SDB regeneration locally inside one station at a time, then re-align the multi-project.

6. Solution 2: Reorganisation of the STEP 7 Project

When SDB regeneration does not resolve the error, the project tree itself is usually the source of the corruption. STEP 7 ships a Reorganisation function that rebuilds the offline database files.

  1. Close HW Config and any open online windows.
  2. In SIMATIC Manager, select the project root.
  3. Choose File > Reorganisation.
  4. STEP 7 will rebuild the offline database while the project remains open. This may take several minutes on large projects.
  5. After reorganisation completes, repeat the HW Config save-and-compile cycle.

Reorganisation does not delete blocks; it only rebuilds the underlying STEP 7 database. If the dialog still raises the error after reorganisation, proceed to Solution 3.

7. Solution 3: Correct Process Image Boundary Violations

This solution applies when the diagnostic step in section 4 identified an I/O module that straddles the process image boundary, particularly inside a CPU 315-2DP configured as a DP slave.

  1. Open HW Config and select the DP slave CPU.
  2. Right-click the I/O module that is misaligned and open Object Properties.
  3. On the Addresses tab, uncheck Automatic address assignment.
  4. Adjust the start address so that the entire module range lies either within the configured process image (default 0 to 127 for inputs and 0 to 127 for outputs on the S7-300) or fully outside of it. The CPU object properties dialog allows the process image range to be widened up to 2048 bytes if required.
  5. If the module is an analog module and the application does not require cyclic process image updates, move it outside the process image and access it through PZD read/write system calls (SFC14 / SFC15 for DP, SFC30 for direct access).
  6. Save and compile HW Config.

The same procedure applies to modules mounted in ET 200M or ET 200S DP slaves that are addressed from the CPU 317-2DP master. The strict check was introduced in STEP 7 V5.3 and is also active in V5.4, V5.5 and V5.6. Older projects that compiled cleanly under V5.1 or V5.2 will trip the new check the first time they are edited.

8. Solution 4: Rebuild the Multi-Project DP Master-Slave Binding

For multi-project configurations with an S7-300 DP slave hanging off an S7-400 master, the binding object must be re-created after the slave has been uploaded.

  1. Upload the slave CPU 315-2DP into a separate STEP 7 project using PLC > Upload Station to PG with the option to include hardware configuration enabled.
  2. In the original master project, open Options > Multi-Project > Insert Station and add the uploaded slave project as a new member of the multi-project.
  3. Open HW Config on the master CPU and drag the slave station from the hardware catalog (under PROFIBUS-DP > Configured Stations > S7-300 Stations) onto the DP master system.
  4. Assign the slave to the master interface and confirm the slot mapping matches the physical configuration of the slave CPU.
  5. Save and compile both HW Config and NetPro.
  6. Run Options > Multi-Project > Align to synchronize the global libraries and cross-references.
Reference. The official Siemens application example "DP link between CPU 315-2DP (slave) and S7-400 (master) with STEP 7 V5.3" describes the GSD-based modular slave binding that is required for this configuration. See the Siemens Industry Online Support entry 16665640 for the canonical wiring example.

9. Solution 5: STEP 7 Version Compatibility Check

Mixing STEP 7 versions on the same project is the single most common source of corruption that survives SDB regeneration and reorganisation.

  1. Determine the STEP 7 version used to create the original project. This information is stored in the project *.s7p file header and is also visible in Help > About within SIMATIC Manager.
  2. Open the project only with a STEP 7 version equal to or newer than the creating version. Down-opening a project created under V5.5 in a V5.3 install is not supported and will silently corrupt the offline database.
  3. If a newer version is required, perform an explicit File > Save As from within SIMATIC Manager of the newer install. This rewrites the project headers in a format compatible with the new version.
  4. After the version migration, perform a fresh SDB regeneration (Solution 1) followed by a project reorganisation (Solution 2).
Created under Read by Compile behaviour
STEP 7 V5.3 V5.3 SP3 OK
STEP 7 V5.3 V5.5 SP3 OK with implicit migration
STEP 7 V5.5 V5.3 SP3 FAIL - down-version not supported
STEP 7 V5.6 HF8 V5.5 SP3 FAIL unless saved as V5.5 explicitly
STEP 7 V5.4 TIA Portal V13 Migration required, use STEP 7 V5.5 as bridge

10. Solution 6: Symbolic Name and Cross-Reference Repair

If HW Config still reports the error after SDB regeneration, reorganisation and process image correction, the symbol table may hold absolute addresses that no longer match the rebuilt SDBs.

  1. Open Options > Symbol Table in SIMATIC Manager.
  2. Sort the symbol table by address and look for entries flagged red. These are the orphans.
  3. For each orphan, decide whether to remap the symbol to the new address (preferred) or delete the symbol if the underlying I/O has been removed.
  4. After editing the symbol table, run Options > Cross References and rebuild the cross-reference data. This regenerates the XREF subfolder that HW Config consults during compile.
  5. Save the project and repeat the HW Config compile cycle.

11. Verification Procedure

Once the offline compile completes without the dialog, the fix must be validated against the live CPU before the engineer signs off.

  1. Establish an online connection to the CPU via MPI or PROFIBUS.
  2. In SIMATIC Manager, select PLC > Compare Offline/Online. The result must show Identical for both blocks and SDBs.
  3. Open the CPU diagnostic buffer and confirm that no new SF entries were created during the offline compile.
  4. Read the module status of every DP slave. The Module Status dialog must show OK for every slot.
  5. Perform a controlled download of the modified configuration while the plant is in a safe state. The CPU will go through a STOP > RUN cycle; verify that the SF LED does not light and that all outputs return to their last commanded state (if so configured) or to their configured substitute values.
  6. If the configuration includes safety modules (F-CPU in F-config), perform the additional safety acceptance test according to the F-runtime license documentation.

12. Troubleshooting Matrix

Symptom Likely Root Cause First Action Fallback Action
Error in Config dialog, no specific code Corrupt SDB Solution 1 - SDB regeneration Solution 2 - Reorganisation
HW Config shows empty rack Upload without HW Config Re-upload with HW Config option enabled Recreate from original CAx data
Compile fails on specific module Process image boundary violation Solution 3 - Adjust process image Move module outside process image, use SFC14/15
Compile fails after upload of multi-project Missing slave binding Solution 4 - Re-bind slave in master Re-create multi-project from scratch
Compile succeeds on V5.3 but fails on V5.5 Version drift Solution 5 - Save As under newer version Re-create on dedicated V5.5 PC
Compile fails on every iteration Symbol table corruption Solution 6 - Repair symbols Re-create symbol table from printout
Compile fails only after re-archive Incomplete archive Re-archive with all referenced blocks Use external backup of project
Diagnostic buffer shows OB85 I/O access error Check process image mapping Re-seat physical module

13. Preventive Measures

  • Always archive before upload. Use File > Archive with the option to include the SDBs enabled. An archive that omits SDBs cannot be used to restore HW Config.
  • Pin STEP 7 versions. Maintain a baseline STEP 7 installation (typically V5.5 SP3 with HF7 or later) on a dedicated engineering workstation. Never upgrade the production engineering laptop without coordinating with the maintenance team.
  • Use a multi-project from the start. For systems with a DP master and a DP slave, build the multi-project structure on day one. Single-project configurations cannot be migrated cleanly later.
  • Document process image ranges. Record the configured process image ranges for every CPU in the plant in a controlled document. Process image drift is invisible until a future compile fails.
  • Schedule a yearly recompile. Even if no change is made, open HW Config, run Save and Compile, save the project to a network share. A yearly compile cycle catches drift before it becomes an emergency.
  • Export the symbol table as PDF. Print the symbol table to PDF once per year and store it in the plant documentation system. The PDF is the only reliable recovery source if the symbol table itself becomes corrupt.

14. Migration to TIA Portal

If the S7-300 station is being migrated to TIA Portal as part of a plant modernization, the same "Error in Config" symptom can reappear during the import step. TIA Portal uses a different SDB format and regenerates the system data on first save.

  1. Open the STEP 7 V5.5 project and run Save As to ensure the latest known-good header.
  2. In TIA Portal, create a new project and select Project > Migrate STEP 7 V5.x project.
  3. During migration, allow TIA Portal to regenerate all SDBs. Do not attempt to copy any SDBs across manually.
  4. After migration, recompile HW Config and download to a test CPU before attempting the live CPU.
Siemens official reference. The migration rules for STEP 7 V5.x to TIA Portal are documented in the entry "Migrating STEP 7 V5.x projects to TIA Portal" on the Siemens Industry Online Support portal. Always read the supported firmware matrix before initiating a migration; some older CPU 31x firmware versions are explicitly excluded.

15. Field-Commissioning Checklist

When the offline error has been resolved and the engineer is about to download to the live CPU, walk through this checklist on-site:

  1. Verify the CPU selector switch is in STOP (or that the password-protected remote STOP is acknowledged by operations).
  2. Perform a memory card pull-and-replace dry run if the project is to be loaded via MMC.
  3. Disconnect the load power to non-essential outputs if the substitute value strategy has not been validated.
  4. Download the blocks, then download the HW Config, in that order. Reverse order is unsupported.
  5. Cold restart the CPU and observe the SF/BF LEDs for at least 30 seconds.
  6. Run the user program through one full OB1 cycle in single-step mode (CRTL+F8 in the variable table) before releasing the station to automatic mode.

16. FAQ

What does the dialog "Error in Config" actually mean when STEP 7 HW Config refuses to compile?

It is a generic exception raised by the HW Config compiler when the offline configuration tree cannot be resolved against the SDB inventory or the symbol table. It does not carry an error code; the underlying fault must be diagnosed by elimination. Start with SDB regeneration, then project reorganisation, then process image boundary inspection.

Why does my CPU 315-2DP slave compile cleanly in STEP 7 V5.1 but fail in V5.5 after upload?

STEP 7 V5.3 introduced a strict process image boundary check for DP slaves. Inputs and outputs must lie either entirely inside the configured process image or entirely outside of it. Older projects that were commissioned before V5.3 may have modules that straddle the boundary. Either move the affected module to a process-image-free range or widen the process image in the CPU object properties.

I uploaded only the S7 program and not the hardware configuration. Can I rebuild HW Config from the uploaded blocks alone?

No. The SDBs that the upload retrieves are produced by the running CPU and contain parameter data but not the slot layout. To rebuild HW Config you must either re-upload using "Upload Station with Hardware Configuration" or recreate the station from the original CAx data (circuit diagram, module list, GSD files).

Is it safe to delete the SDBs manually under the S7 Program folder?

Yes, in an offline context. SDBs are regenerated by HW Config and NetPro on the next save-and-compile. Do not delete SDBs while online, and never delete them from a project that has not been archived. In multi-project configurations, perform SDB regeneration one station at a time and re-align the multi-project afterwards.

How do I bind a CPU 315-2DP as a slave to an S7-400 master after the original binding is lost?

Upload the slave CPU into a separate STEP 7 project with HW Config enabled, add that project as a member of the original multi-project, then drag the slave from the hardware catalog (PROFIBUS-DP > Configured Stations > S7-300 Stations) onto the master DP system. Save and compile both HW Config and NetPro, then run Options > Multi-Project > Align.

Can I open a STEP 7 V5.5 project in STEP 7 V5.3?

No. Down-opening a project created in a newer STEP 7 release is not supported and silently corrupts the offline database. If you must work on an older version, perform File > Save As from the newer install to explicitly downgrade the project format, or use a dedicated engineering workstation per STEP 7 version.

Back to blog