Siemens S7 PLC SF Fault LED: What It Means and How to Troubleshoot It

Key Takeaways: The SF LED on a Siemens S7 PLC (S7-300, S7-400, and the equivalent ERROR LED on S7-1200/1500) signals a system fault: the CPU detected a hardware or program error. The single most useful step is reading the diagnostic buffer in TIA Portal or STEP 7, which records exactly what tripped the fault and when. Most SF conditions trace to a failed or missing I/O module, a broken PROFIBUS or PROFINET connection, a program error such as accessing a non-existent address, or a dead backup battery on older CPUs.

What the SF LED actually signals

SF stands for system fault (Sammelfehler). It is a collective indicator: the CPU aggregates hardware faults and program faults into this one LED, so the LED alone never tells you the cause. On S7-300/400 the red SF LED sits on the CPU and can also appear on individual I/O modules; on S7-1200/1500 the equivalent is the red ERROR LED.

The first distinction to make: is the CPU still in RUN, or has it dropped to STOP? A CPU that stays in RUN with SF lit usually has a tolerated hardware fault (a diagnostic interrupt was handled). A CPU in STOP means the fault was severe enough to halt the program, often an unhandled program error.

Step 1: read the diagnostic buffer, always

Connect with TIA Portal (or STEP 7 Classic on legacy systems), go online, and open the CPU's diagnostic buffer. It lists time-stamped entries for every fault event: which module, which rack and slot, which OB was involved, and the error class. This turns guessing into reading. If the plant has recurring SF events, export or photograph the buffer before clearing anything.

Most common causes

• I/O module failure or absence. A module that died, lost backplane contact, or was removed while configured. The buffer names the rack and slot.
• Fieldbus faults. A PROFIBUS slave dropped off, a PROFINET device lost link, or a cable or terminating resistor failed. Bus faults often light BF alongside SF.
• Program errors. Accessing a non-existent I/O address, array out of range, or a missing organization block: if the matching error OB (such as OB121 or OB122) is not loaded, the CPU goes to STOP.
• Dead backup battery or memory fault on older S7-300/400 stations, especially after a power outage.
• Power dips on an I/O rack. A sagging 24V supply can drop modules momentarily and log hardware faults.

Clearing it safely

• 1. Read and save the diagnostic buffer before anything else.
• 2. Fix the named cause: reseat or replace the module, repair the bus connection, correct the program and load the error OBs.
• 3. If the configuration changed on purpose (a module genuinely removed), update the hardware configuration so reality and project match.
• 4. Restart per your site's change and safety procedures. Never bypass a fault you have not explained.

From one-off fix to pattern

An SF event is downtime with a cause attached, which makes it valuable maintenance data if it gets recorded. Log each event, its buffer entry, and the fix in your CMMS, and review repeat offenders in your downtime analysis. Recurring bus faults on one segment or repeated module failures in one cabinet point at heat, vibration, or power quality problems worth a root cause analysis. Fabrico closes this loop automatically: computer-vision-verified OEE captures the stop the moment the line halts, and the connected CMMS ties it to the work order and the fix, feeding honest MTBF and MTTR numbers.

FAQ

The SF LED is on but the machine still runs. Can I ignore it?
No. A tolerated fault today (one failed input channel, one lost slave) is often the early warning of a full stop later. Read the buffer and schedule the fix.

SF and BF are both lit. Which do I chase first?
Chase the bus fault first. A failed PROFIBUS or PROFINET connection commonly raises both, and restoring the bus clears the pair.

Does replacing the module clear the SF LED?
Once the CPU sees the configured hardware healthy again, the fault condition clears. The buffer entry remains as history, which is exactly what you want.

What loads should the error OBs have?
Even empty OB121/OB122 (and the hardware-fault OBs) keep the CPU in RUN through recoverable faults instead of stopping production. Add logging logic where useful.

To see how automatic stop detection and closed-loop work orders turn PLC faults into a maintainable history, book a demo.