SINAMICS Safety Integrated: Changing Safety Parameters Safely

Overview: Why Safety Parameter Changes Are Different

Safety Integrated parameters on SINAMICS drives (S120, G120, G130, G150, S150) and SIMOTION/SIMATIC F-CPU controlled axes are protected by a checksummed, two-stage commit process. Unlike standard drive parameters, a write to a safety parameter does not take effect immediately. The drive raises a fault, the new values sit in volatile RAM, and a deliberate Copy/Activate handshake is required before the safety CRC is recomputed and the safety functions resume.

If you change the wrong value, skip the copy step, or download with a stale offline project, the drive traps itself in F01650 (data changed, acknowledge required) or F01670 (inconsistent / invalid safety configuration). The machine that has run for years will refuse to enable. This article documents the engineer-to-engineer procedure to make a deliberate, traceable, acceptance-test-friendly safety parameter change on a SINAMICS drive using either STARTER, Startdrive (TIA Portal), or the SINAMICS expert list.

Prerequisites

1. Tooling: STARTER (≤ V5.4 SP1) or Startdrive in TIA Portal V16 or later. The TIA Portal path is mandatory if you are also editing the F-CPU's safety program and want the drive and PLC safety configuration to remain consistent. Refer to the F-parameter configuration guide in the TIA Portal F-CM AS-i Safety ST documentation.
2. Drive firmware: SINAMICS S120 firmware ≥ V4.4 for current Safety Integrated Extended functions. Older firmware branches (V4.3, V4.5) accept the procedure below but may add supplementary alarms (A01666, F01669) for SI Motion monitoring channel consistency.
3. Online access: PROFIBUS, PROFINET, or Ethernet/PG channel that can reach the drive object (DO) and the Control Unit. Access level for safety parameters must be at least Service (p7764) or, for forced check timer p9659 and acceptance test date, Expert.
4. Project archive: An Upload from target to PG snapshot stored in a versioned folder before any change. The drive's safety CRC (r9780, r9790) and the F-CPU's safety signature (F-CPU CRC1/CRC2) must be recorded for the safety acceptance log.
5. Rest state: Drive must be in no fault / no alarm state, all safety inputs in a defined state, and STO/SS1/SLS not active. The user must have authority to bypass and restart the affected zone per the site's lockout/tagout procedure.

The Safety Parameter Storage Model

SINAMICS safety parameters are split into two physical stores on the drive:

The commit sequence is always RAM edit → p9700 = 1 (Copy RAM to ROM) → p9701 = 1 (Acknowledge data change) → power-on / warm restart. The drive will not use the new safety values until the sequence is complete. The same model applies to SI Motion parameters (p93xx / p95xx) and to SINAMICS Integrated safety (e.g. p9601, p9610, p9650, p9659, p9761, p9771).

Key Safety Parameters You Will Touch

After a parameter change, compare the offline value to the online value in STARTER/Startdrive. If p9515 differs between the project on the PG and the device, the drive refuses the download of the safety configuration with F01650. Always upload the device's current values to the PG before you begin a parameter change, so the offline baseline matches the on-line reality.

Standard Workflow: Change a Safety Parameter End-to-End

1. Capture the baseline. In STARTER/Startdrive, click Online → Upload (target → PG). Confirm the upload covers the drive object. Record r9780[0] (SI Motion actual checksum) and r9790[0] (SI common checksum) from the expert list.
2. Go offline. Disconnect. Save the project under a new revision (e.g. Project_S120_Line1_v23_SI_SLS_change_2024-05-08).
3. Open the Safety Integrated configuration dialog for the drive object. The dialog is reachable by double-clicking Functions → Safety Integrated in the navigation tree. Edit only the parameters explicitly required. Do not uncheck functions that are not in scope; the CRC will drift and the acceptance test scope grows.
4. Tick "Copy parameters after download" in the first Safety Integrated dialog. This flag causes the engineering tool to issue p9700/p9701 automatically after the configuration download, removing a manual expert-list step that is easy to forget.
5. Download to target. Right-click the drive object → Download to target device. Choose Download and copy RAM to ROM when prompted. The drive raises F01650 (1000) — this is expected.
6. Activate settings. With F01650 active, open the Safety Integrated configuration dialog. Click Activate settings. The tool writes p9700 = 1, waits for completion, then p9701 = 1. F01650 clears. The drive is in Safety commissioning mode until the next power-on.
7. Power cycle the Control Unit (or issue a warm restart through p0972 where supported) so the new safety values become the active boot reference.
8. Run the acceptance test. Use STARTER's Acceptance test wizard (Startdrive has the equivalent under Safety → Acceptance test) to generate a PDF report. The report includes the before/after CRCs and must be archived with the machine's safety documentation.

Handling Fault F01650 — "Safety Parameters Changed, Acknowledgement Required"

F01650 is the drive's polite request to commit your pending change. It is the expected fault after any successful safety parameter download. The remedy sequence is mechanical:

1. Confirm the drive is in a safe state. The safety commissioning mode blocks setpoint enables.
2. In the Safety Integrated configuration dialog, click Change settings, make any additional required edits, then click Copy parameter (this triggers p9700 = 1) and Activate settings (this triggers p9701 = 1).
3. Alternatively from the expert list:
   p9700 = 1 → wait for completion bit r3996.0 to clear → p9701 = 1 → power cycle.
4. Verify the new checksum: r9780[0] (SI Motion) and r9790[0] (SI common) should differ from the values captured in step 1 of the workflow. The new values are the CRC you archive with the acceptance report.

If F01650 returns after the next power-on, the Safety ROM copy did not complete. Check the CF card health (p9920 in S120) and re-attempt p9700 = 1. A failing CF card cannot persist safety parameters and must be replaced before the machine is returned to service.

Handling Fault F01670 — "Inconsistent Safety Parameterisation"

F01670 is a different class of fault. It indicates that the safety parameters on the drive are not internally consistent or that a checksum mismatch was detected at power-on. Typical causes:

• Power loss between p9700 and p9701, leaving RAM and ROM out of sync.
• Download of a safety configuration whose CRC does not match the F-CPU's expected safety signature (relevant when the drive is controlled by an F-CPU running a PROFIsafe / PROFIsafe-on-PROFINET stack).
• Stale offline project: the project on the PG no longer matches the drive, and the download overwrote a working set of safety values with an old revision.

Recovery procedure:

1. Place the system in a safe state, ensure all personnel are clear, and that the zone can be entered under the site's safety protocol.
2. Upload (target → PG) the current drive data so the offline project reflects what is on the device. Do not skip this — overwriting a working safety configuration with a stale one is the most common cause of recurring F01670.
3. Inspect p9515, p9650, p9659, p9761 and p9771 in the expert list. Compare to the last known good values archived in the safety acceptance log.
4. Re-apply only the intended change. Click Copy parameters after download in the Safety Integrated configuration dialog. Download, click Activate settings, and power cycle.
5. If F01670 persists, restore the safety defaults by setting p9761 = 0 (factory password), p9700 = 1, then re-run the full safety commissioning including a fresh acceptance test. This is a last resort — it reverts every safety parameter to its as-shipped value, including the PROFIsafe address, and requires the safety configuration to be re-entered from scratch.

Runtime Changes from an F-CPU (TIA Portal)

When the safety functions on the SINAMICS drive are parameterised by an F-CPU via PROFIsafe, the F-CPU can change selected non-safety-critical configuration values at runtime using the F-block library's ChangeParameter function block. The Siemens KB attachment on F-parameter storage during runtime (TIA V18) specifies that the operator-issued change is validated by the fail-safe ChangeParameter FB; values outside the configured range are rejected and a diagnostic alarm is raised on the F-CPU.

This runtime path applies to F-CPU-side F-parameters, not to the drive's safety parameters on the SINAMICS side. Drive safety parameters still require the p9700/p9701 commit and a restart to take effect. Mixing the two paths is a common source of confusion: an F-block cannot write to p9650 or p9659 at runtime; the drive enforces the safety commit protocol regardless of the requester.

Online vs Offline Project Discipline

Three rules prevent the most common F01650/F01670 escalations:

1. Always upload before edit. The drive is the source of truth for safety parameters. The PG is a viewer/editor. If the offline project is older than the device, a download will overwrite working values.
2. One safety change at a time. Multiple unrelated edits in a single download produce one delta of CRCs and a wide acceptance test scope. The acceptance test wizard will require every affected function to be exercised.
3. Archive the safety log. Before the download, save the STARTER/Startdrive project, the safety acceptance report PDF, and a screenshot of r9780/r9790 in a folder named with the change ticket ID. This is the audit trail required by ISO 13849-1 PL e / SIL 3 applications.

Verification After a Safety Parameter Change

1. Power cycle the Control Unit. The drive boots into Safety commissioning mode with the new values active.
2. Read r9780[0] (SI Motion actual checksum) and r9790[0] (SI common checksum). Confirm they match the values stored after the p9701 commit.
3. For each safety function that was touched, force a trigger and verify the response:
   • STO: remove the safe input, confirm torque is removed within the configured time.
   • SS1: trigger SS1, monitor deceleration and STO transition.
   • SLS: command a velocity above the limit, confirm the configured stop response.
4. For SLP / SLA / SOS, verify position-window violations trigger the expected stop response.
5. Run the STARTER/Startdrive Acceptance test wizard. Sign and archive the resulting PDF.
6. Reset the forced checking timer p9659 if the acceptance test is your annual proof test. Otherwise leave the existing value and let the drive raise the next due warning at now + p9659 hours.

Troubleshooting Matrix

Field-Proven Caveats

• The "Copy parameters after download" checkbox in the Safety Integrated dialog is per-project, not per-DO. Check it once per project, not per download.
• p9761 (safety password) is not the same as the drive's standard password (p7764). Losing p9761 requires a Siemens service request to reset; back it up in the safety log.
• Do not change safety parameters via the expert list while the drive is being controlled by a running F-CPU PROFIsafe slot. The drive's safety communication expects stable safety CRCs; an in-flight change will be rejected with F01670 by the F-host.
• SINAMICS Integrated (CU320-2) and SINAMICS S120 Combi share the same safety commit protocol. The procedure above is identical for both.
• G120 drives with Safety Integrated Extended require CU firmware ≥ V4.7 SP3 for the modern p9700/p9701 handshake. On older firmware, the equivalent commit is p9602 = 1, p9700 = 1 in sequence.