Sinumerik 840D NCU Not Booting: Seven-Segment Diagnostic Recovery

Problem Overview

A Sinumerik 840D NCU (Numerical Control Unit) refuses to complete its boot sequence. The seven-segment display on the NCU cycles upward through its diagnostic states, briefly settles, and then collapses to a single cyclic dot indicating an unresolved error. The operator panel (PCU/HMI) cannot establish communication with the PLC, and Step 7 connection attempts time out. The PCU cannot get a signal from the PLC. The fault is intermittent on first observation: a cold reset may bring the controller back, but there is no diagnostic confirmation that the underlying condition has been removed.

This pattern - rapid counting through 0..8, dwell at 5, transient 6, cyclic dot, POK/PR green, Step 7 timeout - is one of the most common "dead Sinumerik" symptoms reported in service tickets on 840D and 840D sl lines (NCU 561.x / 571.x / 710.x / 720.x / 730.x). Because the machine often controls a high-value, long-cycle machining operation (parts with weeks or months of lead time, tight diameter tolerances), a fault classified as "unexplainable" is unacceptable to operations. The procedure below is engineered to convert a non-deterministic boot fault into a deterministic, documented recovery that operators can execute before calling field service.

Reference: Siemens Industry Online Support, SINUMERIK product portal.

NCU Front-Panel Indicators (POK, PR, SF, BF)

Before interpreting the seven-segment code, capture the LED state. The LEDs provide a coarser signal that is needed to separate power-supply faults from PLC faults from drive-commissioning faults.

Decoding the Seven-Segment Status Code

The seven-segment display on a Sinumerik 840D NCU (and the NCU 7x0 of 840D sl) is the primary diagnostic channel for the NCK/PLC boot state. Each digit corresponds to a defined phase. Operators should observe at least three full cycles and note the last stable digit before the display collapses to the cyclic dot.

The reported symptom - "cycles up to 8, then back to 5 for some time, then to 6 for a second, then disappears to dot" - maps to the following state trajectory:

1. NCU powers up; firmware loads; NCK reaches phase 8 (cold restart complete).
2. PLC comes up, attempts RUN, drops back to STOP - dwell at phase 5.
3. PLC recovers briefly, reaches RUN - phase 6 visible for ~1 second.
4. Drive-ready handshake fails OR the PLC drops to STOP again - controller collapses to cyclic-error dot.

State Machine (Boot Path With Fault Injection)

PLC Timeout in Step 7 - Interpretation

Step 7 (or TIA Portal with the 840D sl add-in) times out when the PLC side of the NCU does not respond to MPI/PROFIBUS/TCP "online" requests. The most common causes:

• PLC in STOP with no cyclic communication running.
• PLC firmware corrupted - OB100 cannot complete.
• PLC and NCK handshake stalled (PLC RUN requested but not acknowledged).
• MPI/DP address mismatch between the PC station and the NCU (default PLC MPI address on 840D is 2, baudrate 187.5 kbps or 1.5 Mbps depending on NCU generation).
• Defective PROFIBUS cable / connector on the X2 (MPI/DP) port of the NCU.
• NCU in extended reset with bus interfaces disabled.

Because POK and PR are both lit, the PLC is electrically alive and has reached a "ready" state at least once during boot. The Step 7 timeout is therefore almost always a software-side condition (PLC in STOP with cyclic blocked, or address conflict), not a physical-layer fault.

Root Cause Categories

Reduce the symptom to one of five buckets before deciding on a recovery action:

Primary Recovery: NC/PLC Clearing Procedure

NC/PLC clearing is a controlled reset that wipes the volatile NCK and PLC working memory, forces a re-read of the project files from persistent storage (CFast card or hard disk), and re-runs the cold-restart sequence. It is non-destructive to the backed-up project files. It is the correct first action whenever the seven-segment shows the 5 -> 6 -> . pattern with PR green and SF off.

Procedure for 840D Classic (NCU 561.x / 571.x) with MMC 100/103

1. Switch the controller to a safe state - program end / reset, axis standstill, door closed.
2. On the MMC front panel, turn the keyswitch to position 0 (or remove the key from RUN).
3. Set the NCK rotary switch (S4 on the NCU module, position visible through a small window) to position 1 - this is the "NCK general reset" position.
4. Power-cycle the NCU (24 V off, count to 10, 24 V on).
5. Watch the seven-segment: it should count 0 -> 1 -> ... -> 7 with no collapse to dot.
6. When the HMI shows "PLC stop / Reset" and the seven-segment sits at 5, set the S4 switch back to position 0.
7. From the HMI, trigger a PLC general reset (Start-up -> PLC -> PLC general reset).
8. Reload the PLC project from backup (Start-up -> PLC -> Load from PG/PC or Load from archive).

Procedure for 840D sl (NCU 710.x / 720.x / 730.x) with TCU/PCU

1. Place the machine in a safe state - reset, axes stopped.
2. From Sinumerik Operate, navigate to Start-up -> HMI -> Reset / Clear.
3. Select "NCK reset" first; confirm with "OK". The controller reboots.
4. After NCK returns to operational state, navigate to Start-up -> PLC -> "Clear PLC".
5. Confirm. The PLC performs an OB100 cold start; project files are reloaded from /card/user/system/.
6. If the seven-segment again collapses to dot, escalate to "NCK general reset (clear CF)" which wipes volatile machine data and forces a full reload from the system image. WARNING: this clears compensation data, machine dates, tool lists, and requires a full re-commissioning - do NOT run this on a production machine without an intact backup.

Reference: SINUMERIK 840D sl Commissioning Manual (TCU / NCU).

Secondary Recovery: Backup Restore

If clearing alone does not return the controller to a stable 7, the next step is a project restore. Sinumerik supports several backup formats:

For the symptom in question, load the .arc archive first; if that fails or returns the same fault, fall back to the PLC .zap/.zap15 and the NCK .dsf separately. A partial restore that touches only the PLC is sufficient when the seven-segment is collapsing because of an OB121 programming error.

Hardware Verification: NCU Module and NCU Box

When clearing does not bring the seven-segment to a stable 7, escalate to hardware verification. The procedure below is the minimum cost-effective set; it assumes that POK is lit (24 V supply verified externally) and that the NCK and PLC firmware are known to be intact on persistent storage.

1. Remove all PROFIBUS / PROFINET connectors from the NCU (X2, X126, X127, etc.) and power-cycle. If the controller reaches phase 7 with the bus disconnected, a slave or cable is dragging the bus. Re-connect one segment at a time.
2. Check the fan on the NCU module. NCU 720 / 730 have temperature sensors; if the fan has seized, the NCK will throttle and may drop to a fault state with no clear error code.
3. Inspect the CFast card seating. Power off, remove the CFast card, reseat firmly. A partially-seated card can boot past phases 1-3 and then stall when the runtime image is partially readable.
4. Measure the 24 V supply at the NCU terminal block. Tolerance: 20.4 V to 28.8 V. Voltages above 28.8 V cause the NCU to throttle; voltages below 20.4 V cause the NCK to crash with no diagnostic buffer entry.
5. Check the NCU-to-PCU link (Ethernet on X120, or the backplane on integrated panels). A damaged patch cable mimics a software fault.
6. If all of the above are clean and the fault persists, the NCU module itself is suspect. Swap with a known-good NCU of the same firmware version. NCU 561.4 and 571.4 are not interchangeable - check the MLFB article number before any swap.

Risk Classification for Unattended Recovery

Long-cycle, single-piece machines (weeks or months of work, tight tolerances, no mid-cycle recovery) cannot accept a cold reset as a routine recovery action. The table below defines risk classes and the sign-off required before returning the machine to production.

The user case is class C: clearing is acceptable, but the machine should not be returned to unattended production without monitoring the PLC diagnostic buffer (Step 7 online -> PLC -> Diagnostic buffer) for at least one full warming-up cycle.

Verification After Recovery

1. Confirm POK, PR green; SF, BF off.
2. Open Step 7 / TIA Portal and connect to the PLC. Verify the diagnostic buffer is empty or contains only the expected cold-restart entries.
3. From Sinumerik Operate, navigate to Diagnosis -> NC/PLC -> Version. Verify the NCK software version and PLC firmware version match the commissioning record.
4. Run the axes in JOG through the full travel range; verify no following-error alarms.
5. Run one full MDI block that exercises all tool-change logic.
6. Run one full AUTO program on a sacrificial workpiece (if class B or C). Inspect the surface for chatter marks that would indicate the controller skipped an interpolation block.
7. For class C machines, leave the controller under continuous monitoring for 24 hours with the PLC diagnostic buffer uploaded every 4 hours to a network share. If any OB121 or OB85 entry appears, escalate to engineering.

Preventive Hardening

• Replace the NCU backup battery (CR2032 or equivalent, depending on NCU generation) on the maintenance schedule. A flat battery can corrupt the PLC retentive data and produces exactly the 5 -> 6 -> . pattern on the next cold start.
• Keep two independent backups of the NCK + PLC project: one on the CFast card (automatic) and one on a server share (manual, weekly). The user case was saved because a backup existed.
• Enable the PLC diagnostic buffer upload to a remote syslog or to a SIMATIC log server. A PLC in STOP that does not produce an alarm is the most common root cause of unexplained boot loops.
• Schedule a controlled NCK reset every 6 to 12 months on machines that are otherwise never power-cycled. Long uptime with no reset accumulates PLC diagnostic events that can stall a cold start.
• Apply Siemens firmware updates only after testing on a non-production machine of the same NCU type. The 840D sl firmware versions are not interchangeable across NCU 710 / 720 / 730.

Field Notes

A "machine bad day" classification is a process gap, not a diagnosis. The minimum standard for a class C machine is to capture the PLC diagnostic buffer on every such event and to add the event to a maintenance log. Three unexplained events in twelve months on the same machine is no longer unexplained - it is a latent fault that will eventually coincide with a high-value tool cycle. Treat the first event as a data point and the third as an action item.

Reference documentation for the procedures above: Siemens Industry Online Support portal, Function Manual "SINUMERIK 840D sl Basic Functions", Sinumerik Operate Commissioning Manual, and the SIMATIC S7-300 / S7-1500 diagnostic buffer reference. Operators should also have local access to the SINUMERIK 840D sl Diagnostics Manual for the seven-segment code table specific to the NCU variant installed on the machine.

FAQ