Troubleshooting S7-400 Hardware Configuration Mismatch

A Siemens S7-400 can reject an online hardware comparison even when the visible rack and module parameters appear unchanged. Treat projects not identical as an identity mismatch, then use the displayed system-data status and an SDB-inclusive block comparison to separate a timestamp-only change from a real hardware-configuration difference.

Hardware and system-data mechanism

HW Config is the editable engineering representation of the rack, modules, addresses, and module or GSD parameters. The CPU does not execute that editor representation directly. STEP 7 compiles it into system data blocks, abbreviated SDB, which carry configuration data used by the automation system.

The term not identical here means that STEP 7 cannot establish exact equality between the offline and online objects. It does not, by itself, prove that a module was replaced or an address was changed. Opening a module configuration and accepting a save prompt can change the offline project date or regenerate project objects even when no intentional parameter edit was made.

The message System data not current is the stronger branch condition. It indicates that the system data associated with the compared configuration is not current relative to the engineering configuration. An extra, older SDB found online therefore requires a content comparison; its presence alone does not identify either its function or the configuration change that created it.

Check 1: Project and target selection

1. Confirm the offline object. Open the same S7-400 station and CPU that the online connection reaches. Expect the intended rack and module arrangement. If the wrong station, CPU, or archived project copy is open, select the correct object before comparing anything.
2. Open the online hardware view. Expect communication with the intended CPU and a readable online configuration. If online access fails, resolve the connection path first; a failed or misdirected connection cannot produce a valid comparison.
3. Record both messages separately. Expect either an identity warning alone or an identity warning accompanied by System data not current. Continue to Check 2 for an identity warning alone. When the system-data message appears, continue to Check 3 after checking whether the offline configuration has an unsaved or uncompiled state.

Check 2: Visible hardware parameters

Compare the engineering values that can change generated system data. A matching rack picture is insufficient because a module can retain its slot while its parameters differ.

If only the project date changed after opening an I/O configuration and saving on exit, the visible settings may still match. Do not download merely to remove the warning. Continue to a content-based comparison.

Check 3: SDB-inclusive block comparison

1. Select the block comparison that includes SDBs. Expect system data to appear in the comparison scope. A normal program-block comparison that omits SDBs can report matching logic while missing a hardware-configuration difference.
2. Compare offline and online content. Expect either identical SDB content, changed SDB content, or an SDB present on only one side. Identical content points toward project metadata or dates rather than an active parameter difference. Changed content sends the investigation back to the affected hardware or GSD parameters.
3. Classify an extra SDB. Expect the comparison to identify its presence and, where the engineering data permits, the associated hardware-configuration difference. An older online SDB that is absent offline is not proof that the CPU configuration is wrong; it may represent system data generated by an earlier configuration state.
4. Read detailed differences. Expect useful results such as differing GSD configuration parameters rather than only a generic project mismatch. Resolve each reported parameter against the approved machine configuration.

Do not edit, create, or delete an SDB as though it were an ordinary user block. Change the source configuration in HW Config, then let STEP 7 regenerate the corresponding system data.

Resolving branch procedure

1. Preserve the currently accessible offline project and record the online comparison results before changing configuration.
2. Decide which configuration is authoritative: the approved offline design or the operating CPU configuration. Base that decision on the machine documentation and the actual module, address, and network arrangement.
3. If the offline project is authoritative, correct every reported module, address, parameter, or GSD difference in HW Config.
4. Save the hardware configuration and compile it so the offline system data is regenerated from the current editor configuration.
5. Repeat the comparison with SDBs included. Expect the unexplained content differences to disappear before any transfer to the CPU.
6. Transfer the corrected configuration only under the site's controlled change procedure. Hardware-configuration transfers can affect I/O availability and communication, so establish the permitted operating state before proceeding.
7. If the online configuration is authoritative, reconstruct or recover that configuration into the engineering project through the available STEP 7 online workflow, then save and compile the resulting offline project. Do not overwrite a known-good operating configuration with an uncertain offline copy merely to make the projects identical.

Verification readings and recurring pitfalls

1. Check 1: system-data status. Expect System data not current to be absent after the authoritative hardware configuration has been saved and compiled.
2. Check 2: SDB comparison. Expect no unexplained changed or one-sided SDB entries when the same configuration is present offline and online.
3. Check 3: hardware parameters. Expect rack, slot, addresses, module parameters, and relevant GSD parameters to match the approved configuration.
4. Check 4: repeatability. Close and reopen HW Config, reconnect to the same CPU, and repeat the comparison. Expect the result to remain identical without another save prompt changing the offline object.

Three practices repeatedly produce false conclusions: comparing only program blocks, treating a date difference as proof of a functional change, and interpreting an extra SDB by age or name alone. The deciding reading is the SDB-inclusive content comparison tied back to the editable hardware parameters.

FAQ