Siemens CU320-2 PN: CF Card MLFBs, Boot Rules, and Data Storage

1. Overview of the CU320-2 PN Control Unit

The CU320-2 PN is the central control unit of the SINAMICS S120 modular drive family and is also used in the higher-power SINAMICS S150, G130, and G150 cabinet-platform drives. It performs closed-loop control of the Line Module and Motor Modules, manages the DRIVE-CLiQ topology, hosts the PROFINET interfaces, and stores the project-level parameter set that defines the entire drive line-up. Two variants are offered:

• CU320-2 PN – 6SL3040-1MA01-0AA0 / -0CA0 series, with internal PROFINET IRT (X150 P1/P2) and one PROFINET service interface.
• CU320-2 DP – 6SL3040-1MA00-0AA0 / -0CA0 series, with PROFIBUS DP on X126.

Both variants are mechanically identical and use the same CompactFlash (CF) card slot on the front of the unit. The hardware/firmware behaviour described in this article applies to both PN and DP variants; the only difference is the fieldbus interface. Detailed functional descriptions, slot assignments, and LED states are documented in the SINAMICS S120 Control Units and Additional System Components Manual (06/2020 edition) and the SINAMICS S120 Control Units Manual GH1.

2. CF Card Mandate: Boot, Runtime, and Retentive Storage

The CU320-2 is fundamentally a memory-card-driven controller. Unlike the lower-tier SINAMICS G120 Control Units such as the CU240B-2 or CU240E-2 – which retain their parameter set in internal non-volatile RAM and treat the SD card as an optional backup medium – the CU320-2 cannot complete its boot sequence without a populated, valid CF card.

Three functions depend on the CF card:

1. Firmware image – the SINAMICS firmware (currently V5.x, V5.2 SP3, V5.3 and later) is unpacked from the CF card into the CU's work memory at every boot.
2. Parameter retentivity – the active parameter set (drive topology, motor data, encoder data, BICO wiring, technology functions) is written back to the CF card on a "Copy RAM to ROM" command (p0977 = 1 or via STARTER / Startdrive).
3. Licenses – paid firmware options (Safety Integrated Extended, Extended Brake Control, etc.) are stored as licence keys on the CF card. The CU validates these at boot.

3. Supported CF Card Variants and MLFB Numbers

Siemens ships CF cards pre-loaded with a specific firmware version. The card is therefore a firmware-bearing spare part, not a generic storage device. The Basic Card family most commonly seen in the field is shown in the table below.

Three capacity classes are typically offered:

• Basic Card (empty / blank) – used when the project is created and saved to the card from STARTER/Startdrive.
• Basic Card (pre-loaded) – Siemens ships these with a specific firmware; useful for spare-parts and series commissioning.
• Licence-Enabled Card – card with permanent licence keys pre-installed for a specific drive line-up (typically factory-fitted for S150/G150 cabinet units).

4. Memory Layout: Firmware, Parameters, Retentive Data, and Licences

The CF card holds four logical partitions. Understanding them is essential when troubleshooting a "no boot" or "licence missing" condition.

The card uses a FAT16/FAT32 file system that can be read on a Windows PC with a CF reader. This is the standard procedure for offline parameter back-up and for transferring the project to a new CU when performing a unit replacement.

2. Boot Sequence With and Without CF

The CU320-2 executes the following boot phases. The CF card is checked at every step from phase 2 onward.

1. Power-on self-test – hardware test, FPGA init, DDR memory check. The RDY LED is steady red.
2. Bootloader – reads the firmware header from the CF card. Failure to read the card halts boot here. The RDY LED blinks red at 2 Hz.
3. Firmware unpack – the *.S image is decompressed into the work RAM. RDY LED blinks red/green.
4. Topology scan – DRIVE-CLiQ components are detected and matched to the topology recorded in the parameter set.
5. Parameter set load – drive parameters and BICO wiring are loaded from \USER\ on the CF card.
6. Licence validation – licences are matched to the drive line-up. Missing licences produce alarm A13000 (refer to the licensing manual for the full table).
7. Run-up enable – RDY LED turns steady green; the drive accepts set-points and ON commands.

Typical boot time with a healthy CF card is 25–45 s depending on firmware size, topology depth, and number of connected DRIVE-CLiQ nodes. A "no CF card" or "unreadable CF card" symptom should always be cleared before chasing drive-level faults.

6. Hot-Swap and In-Runtime Removal Risks

Once the CU has completed boot and the drive is in RUN, the CF card is logically removable in the sense that the work memory retains the firmware and active parameter set. In practice this is strongly discouraged:

• The card is mechanically latched but not electrically hot-plug-safe. Insertion or removal under power can corrupt the FAT file system, the licence log, or the active parameter set being written by a background save.
• A subsequent power cycle (or warm restart p0972 = 1) requires the card to be present; if it has been removed, the CU will not boot.
• Some background tasks (trace, DCC chart upload, firmware update in progress) write to the card during normal operation. Removing the card during these tasks can produce a corrupt file system that STARTER will report as "Card not formatted".

7. Commissioning Workflow via CF (Serial Commissioning)

The CF card enables an offline, PC-free commissioning procedure that is widely used in series machine building. The typical workflow is:

1. On a reference bench, the engineer uses STARTER (≤ V5.x) or TIA Portal Startdrive (V15.1 and later) to commission a single reference drive line-up.
2. Once the drive runs correctly, the engineer selects Target system → Copy RAM to ROM (or sets p0977 = 1). The active parameter set is written to the CF card.
3. The CU is powered down, the CF card is removed, and a card label is generated (right-click drive in STARTER → "Create card label").
4. On the series machine, a blank CF card is inserted, the project is loaded from STARTER ("Load to target device" with "Including CF card"), or the parameter set is loaded into the card file system manually.
5. The card is inserted into the new CU320-2. On first power-up the drive runs with the cloned parameter set.

This procedure is the only documented method for cloning a drive line-up without re-running the full commissioning wizard. It is also the supported way to restore a CU after a hardware replacement.

8. Application-Specific Notes: S120, S150, G130, and G150

The memory-card rule is uniform across all four platforms. The only platform-specific difference is whether the card ships from the factory with licences pre-installed (S150/G150 cabinet units) or blank and populated during commissioning (S120 booksize/chassis, G130 chassis).

9. Field Diagnostics and Fault Codes

When a CU320-2 fails to come up, the first check is always the CF card. The following table maps the typical RDY LED pattern to the most common root cause.

Drive-level fault codes that frequently point back to a CF card root cause include those in the F01000/F01005 and F085xx families, but the exact number is firmware-version dependent and must be verified against the active parameter list. Always export the fault buffer (r0945/r0947) to a trace file before clearing.

10. Replacement, Migration, and Best-Practice Procedure

1. Before swapping a CU320-2, perform Target system → Copy RAM to ROM in STARTER. Verify the file /USER/SINAMICS.S (or project-specific name) is dated correctly on the card by reading the card on a PC.
2. Power down the drive line-up. Remove the CF card and store it with the unit – the card is part of the asset.
3. On the new CU, insert the original card, apply 24 V, and wait for the RDY LED to turn steady green. Do not re-flash the card before this step; the original card is the source of truth.
4. If the new CU is running a higher firmware than the card, STARTER will offer a firmware update on the card. Decline unless the change is intentional, then perform the upgrade in a controlled maintenance window.
5. Verify the licence status. On the S150/G150 platforms the licence key is hardware-bound to the original CF card; transferring the card to a new CU is sufficient.
6. Perform a reduced commissioning check: enable ON command, run a low-speed jog (p2300 / p1155), verify encoder feedback, verify safe stop (if Safety Integrated is licensed).

11. CU320-2 vs CU240 – Why the Memory-Card Rule Differs

A common field question is why a G120 with CU240B-2/CU240E-2 can run without an SD card, while a S120 with CU320-2 cannot. The architectural reason is the persistence strategy:

• CU240B-2 / CU240E-2 (SINAMICS G120): parameter set is held in internal non-volatile RAM (NVRAM). The SD card is a backup / cloning medium only. Removing it does not affect operation.
• CU320-2 (SINAMICS S120/S150/G130/G150): the work RAM is volatile (DDR). The CF card is the only non-volatile storage, and is also the firmware source. Removing the card invalidates the platform.

This difference reflects the platform scale: the CU320-2 typically manages multi-axis topologies with firmware payloads in the tens of MB, which is why external storage is mandatory rather than internal.

12. Summary of Hard Rules

FAQ