TDC CPU551: Committing Online CFC Parameter Changes Permanently

Problem Overview

On a Siemens TDC (Technology and Drives Controller) rack fitted with a CPU551 processor module, an engineer edits the constant input of a CFC (Continuous Function Chart) function block while the controller is in TEST / Online mode. The value updates immediately in the running system, the write-protection dialog no longer appears once the card's mechanical switch is toggled, and a power-cycle of the rack preserves the new value only while the rack remains energised. As soon as the rack is de-energised and brought back up, the parameter reverts to the value that was compiled and downloaded into the project — even though the online tool reported the new value as committed at runtime.

This symptom is characteristic of an MC5xx memory-card write strategy mismatch: the change is written to one memory region (typically the additional EEPROM area) but not transferred to the other (the main flash region) from which the CPU reloads its image on a cold start. It can also be triggered by an incorrect write-protection state at the moment the controller initialises from the card.

Affected Hardware and Software

Root Cause Analysis

Two interacting mechanisms cause the value to revert. Either one alone is sufficient; in field cases both tend to be present.

1. Two-region memory model of MC5xx flash cards

The MC5xx card carries a main memory (flash) and an additional memory (EEPROM-style overlay). The compiled program image and the constants baked into the project are stored in main memory. Online/test changes you make through the CFC editor are normally written to the additional memory area so that the running CPU loop continues with the new value without immediately reprogramming flash. On a cold start, however, the CPU reloads its initial image from main memory; the additional-memory contents only take effect if a save/merge operation has been performed or if the toolset explicitly persists the delta into main.

The user's symptom — change visible while energised, gone after restart — is the exact signature of an online delta that lives in additional memory but was never transferred to main flash. The CFC editor reports the value as live, but the persistent image is unchanged.

2. Write-protection state at boot

On original Siemens MC5xx cards the write-protect switch is hidden under a plastic cover and is normally not user-accessible; on some card variants the switch is accessible at the front. If the card boots with write protection enabled, the firmware will refuse to update the image during the start-up merge step. Even if the user toggles the switch off in operation and re-enables it before power-down, the boot-time commit attempt on the next power-up can be denied. The correct sequence is therefore: write-protect disabled at the moment of the online change, kept disabled across the reboot that verifies the change, and re-enabled only after the change has been verified.

3. Non-Siemens card

If the fitted card is not an original Siemens MC5xx, the additional-memory area may not be addressed correctly by the CPU. The change is silently dropped or written to a region the firmware does not consult on cold start. The mitigation is to replace the card with an original Siemens MC5xx of the matching capacity.

Diagnostic Procedure

1. Confirm the card is original Siemens. Read the part number on the card label and verify it is an MC5xx (e.g., MC510, MC521, MC525/MC526 family depending on rack generation). Reject any third-party card.
2. Confirm the firmware build of CPU551. Note the firmware version reported by the engineering tool when going online; record it against the case file. While the source case does not quote a firmware version, future cases should record it because TDC online-merge behaviour has differed between firmware revisions.
3. Verify write-protect state at the card. On original cards, remove the plastic cover (or access the front slider) and confirm the switch is in the unprotected position before going online.
4. Recompile and re-download the project. A Recompile + Download in offline mode ensures the CFC chart in the engineering database matches what is loaded on the CPU. This step is mandatory before the online change is attempted; otherwise the runtime will eventually flag an offline/online inconsistency on the next cold start.
5. Make the online change with write protection disabled.
6. Power-cycle with write protection still disabled to confirm the change persists.
7. Re-enable write protection only after persistence is verified.

Solution Procedure (Step-by-Step)

1. Disconnect any process-affecting outputs. A constant change inside a CFC FB is usually safe, but downstream logic can react. Put the affected process area in a safe state.
2. Open the project for the CPU551 in the TDC engineering tool. Verify the offline project name matches the project loaded on the rack; an off-by-one mismatch produces the same offline/online different dialog the user reported.
3. Save the project, then perform a clean compile. Use the menu path that triggers Compile → Charts (or the equivalent CFC rebuild). Resolve any warnings.
4. Download the program to the CPU551 in STOP or test-prep state, depending on site procedure. Confirm a clean download with no diagnostic buffer entries referencing CRC or consistency errors.
5. Put the CPU in RUN / Online. Open the CFC page, double-click the constant input, and observe the dialog. If the dialog reports Flash card is write protected, the switch is enabled — disable it on the card and retry.
6. Edit the constant. Type the new value, confirm. The online value should change from the old value to the new one (e.g., from 5.0e-3 / 0.00499999 shown in yellow tooltip to 2.0e-3 / 0.002000000).
7. Trigger an explicit persist / commit. In the CFC online toolset, use the menu item that saves the online change to the load image — often labelled Download → Save to card, Write to flash, or invoked automatically by a RAM ↔ Flash button. Do not rely on implicit commit.
8. Do not re-enable write protection yet. With the rack still energised, leave the switch in the unprotected position.
9. Power down the TDC rack, wait at least 10 seconds, re-energise. Cold start reloads the image from the main flash area.
10. Go back online and verify the new constant is present. Hover the parameter in test mode: the value should now read the new one (e.g., 0.002000000) with no offline/online mismatch dialog.
11. Re-enable write protection on the MC5xx card only after this verification step succeeds.

Verification

Troubleshooting Matrix

Field-Proven Caveats

• Yellow tooltip values are not exact. The source case shows 5.0e-3 as offline and 0.00499999 as online. This is single-precision floating-point rounding, not a fault. Trust the value reported by the parameter property dialog, not the hover tooltip, when comparing.
• Switch position visibility varies by card variant. On some original Siemens MC5xx cards, the write-protect switch sits behind a plastic cover that must be lifted (or the card removed from its slot) to access. The CFC editor cannot see the switch state until it tries to write and gets a write-protect error. A visible front-panel switch is more common on non-original or older variants.
• TCP/IP behaves the same as DUST1. The connection medium is not the variable. The same code path inside the CPU services online changes regardless of the physical layer.
• Implicit commit is not guaranteed. Do not assume that an online edit becomes a permanent save. The engineering tool's behaviour in this regard has varied across TDC firmware revisions, and the safest assumption is that an explicit "Save to card" / "Download to flash" action is required.
• Card replacement changes capacity layout. Swapping an MC5xx of one capacity for another can require the project to be re-mapped. Verify that the offline project's card-size setting matches the fitted card before repeating the change procedure.

Related Considerations

The TDC platform stores its online-change overlay in additional memory exactly so that engineers can iterate during commissioning without burning flash cycles on every tweak. This is the correct workflow, but it relies on a final, deliberate commit step before the rack is handed back to operations. A common site practice is to leave the MC5xx card write-protected at all times during production and to lift the protection only inside a controlled change window — a window in which the engineer also has authority to perform the explicit save-to-flash action and the subsequent power-cycle verification.

For sites with multiple engineers making simultaneous online changes to different CFC charts on the same CPU, the explicit commit step should be coordinated. Each engineer's edit lives in the same additional-memory area; a cold start will discard all of them if no commit has occurred. Document the change on a controlled modification sheet that records the CPU, the firmware build, the card part number, the write-protect state, the time of edit, the time of commit, and the time of verification reboot.

FAQ