Troubleshooting S7-300 CPU 315-2 DP Continuously Lit SF LED

1. Problem Overview

The CPU 315-2 DP is a mid-range controller in the SIMATIC S7-300 family used in machines with distributed I/O on PROFIBUS DP. A common field failure mode is a continuously red SF LED (System Fault) with the BF LED off (no bus fault at the DP master port), paired with sporadic output dropouts that look like a 15-minute recurring alarm. The BF staying dark is misleading: it only signals a hard PROFIBUS master failure, not a transient slave or backplane fault on a remote station.

This article documents a recurring case where the SF LED lit continuously on the CPU, the diagnostic buffer listed input I 1030.0 (a door-contact / E-stop channel on a remote DP slave) and the PLC dropped all outputs every ~15 minutes as if a stop command had been issued. The actual root cause was a 1 ms loss of communication on the PROFIBUS DP backplane bus module of the remote I/O station. The PLC could not log the reason because the failure window was shorter than the diagnostic event processing time.

The hardware fix in this case was replacement of the communication bus module on the remote DP station (e.g., an IM 153-x for ET 200M or IM 151/x for ET 200S). The fault did not reappear after the swap.

2. SF LED Meaning and CPU 315-2 DP Status Indicators

Before chasing ghost faults, map the LED pattern to a specific failure class. The CPU 315-2 DP front panel exposes six indicators whose combinations uniquely identify the fault class. The table below is the working reference for the diagnostic decision tree in Section 4.

For CPU 315-2 DP (typical catalog 6ES7315-2AH14-0AB0 with firmware V3.3, or 6ES7315-2AJ13-0AB0 with firmware V3.3), the SF LED is driven by the diagnostic interrupt logic, not by the DP master state. The diagnostic buffer in STEP 7 (or TIA Portal online > diagnostics) is the only authoritative source. Trust the buffer; do not trust the BF LED alone to rule out a network-side issue.

3. Root Cause: Intermittent PROFIBUS DP Communication Loss

The recurring 15-minute output dropout is the signature of a transient DP slave communication loss rather than a hard failure. The CPU is told (via diagnostic interrupt) that input I 1030.0 has changed state because the slave could not respond for a single DP cycle. The CPU applies the configured substitute/freeze behavior and the input is read as 0. The next cycle the slave is back, the input reads 1, and the diagnostic interrupt toggles again.

The end result on the application is an apparent door-open alarm that re-arms and re-trips every 15 minutes. The diagnostic buffer captures the event, but the underlying cause (a 1 ms backplane glitch on the remote station's bus module) is below the resolution of the diagnostic event timestamping on the CPU 315-2 DP. This is why the buffer "has nothing" about the SF cause: the event comes in, gets serviced, and rolls off the buffer faster than the engineer can read it.

3.1 Most common physical causes

1. Failing IM 153 / IM 151 bus module on the remote DP slave. Cold solder joints, aged electrolytic capacitors, or failed RS-485 drivers cause intermittent loss of PROFIBUS frames. This is the most common cause when SF stays on continuously while BF stays off.
2. PROFIBUS connector with degraded termination (resistor failure or broken switch on the D-sub).
3. Shield discontinuity on the PROFIBUS cable between the CPU and the remote station, producing common-mode noise during VFD switching or contactor operations.
4. Power supply sag on the remote station (PS 307 5 A or 10 A) during inrush, dropping the IM 153 below its reset threshold for sub-cycle durations.
5. MMC failure or write-cycle exhaustion on the CPU. A worn MMC will report a diagnostic event that lights SF, but it does not typically toggle input 1030.0 in the buffer.
6. Wiring fault on the input itself (broken conductor producing intermittent contact). Captured here for completeness; usually visible in the buffer as channel diagnostics on a specific slot.

4. Reading the Diagnostic Buffer in STEP 7 / TIA Portal

Open the project for the CPU, go online, and open PLC > Diagnostic Buffer (STEP 7 V5.x) or Online & Diagnostics > Diagnostics > Diagnostic buffer (TIA Portal). Sort by date/time descending. Capture a screenshot and a CSV export before clearing the buffer so the event is not lost.

Key event IDs to look for on the CPU 315-2 DP:

If the buffer only shows incoming/outgoing diagnostic interrupts on a single remote module with no channel-level error code, the issue is at the bus module level, not the I/O card level. That single fact shifts the troubleshooting path away from rewiring the input and toward the IM 153 / IM 151 itself.

5. OB82 Diagnostic Interrupt Handling

OB82 is the diagnostic interrupt OB. The CPU calls OB82 on every incoming or outgoing diagnostic interrupt, and the OB's local temporary variables carry the exact module address, channel, and error type. If OB82 is missing from the program, the CPU goes to STOP on the first diagnostic interrupt; this is a common commissioning mistake. Confirm OB82 is in the program blocks before doing anything else.

OB82 local variables (S7-300/400, 20 bytes of standard temp data):

Practical OB82 capture pattern. Create a global DB (e.g., DB820, 32 bytes) and write a short block at the top of OB82 to copy the temp variables into the DB on every call. Use a counter that increments on incoming and decrements on outgoing; the magnitude of the count over a shift tells you how often the diagnostic interrupt fires. The diagram below shows the data flow.

5.1 OB82 capture template (SCL, copy into OB82)

// OB82 - Diagnostic Interrupt (S7-300/400)
// Captures every incoming/outgoing diagnostic event to a global DB

IF OB82_EV_CLASS = B#16#39 THEN           // incoming
    DB820.IncomingCount := DB820.IncomingCount + 1;
    DB820.LastMdlAddr   := OB82_MDL_ADDR;
    DB820.LastIOFlag    := OB82_IO_FLAG;
    DB820.LastFaultType := OB82_FAULT_TYP;
    DB820.LastNZ_KZ     := OB82_NZ_KZ;
    DB820.LastEv1       := OB82_ERR_EV1;
    DB820.LastEv2       := OB82_ERR_EV2;
    DB820.LastDT        := OB82_DATE_TIME;
ELSE                                       // outgoing
    DB820.OutgoingCount := DB820.OutgoingCount + 1;
END_IF;

6. Output Dropout and the 15-Minute Alarm Pattern

The 15-minute periodicity is almost always a derived signal. The PLC is not running a 15-minute timer; it is reacting to the diagnostic interrupt toggling the input back and forth. The illusion of a 15-minute cadence comes from:

1. The PROFIBUS DP cycle time (typically 5 to 50 ms depending on the configured baud rate and number of slaves).
2. The DP watchdog timer configured on the slave (default 10 s, often raised to 30 s in field installations).
3. Application-side debounce on the door/E-stop input (often 1 to 5 s, sometimes 15 minutes for "alarm acknowledge" logic).

When the bus module glitches, the DP slave drops the input slot's value to 0 (substitute value), the CPU sees a rising/falling edge on I 1030.0, and the user program arms a 15-minute alarm-latch block. After 15 minutes the latch is reset by a different code path, and the next glitch re-arms it. The root cause is not the alarm logic; the alarm logic is doing exactly what it was told to do.

7. Step-by-Step Resolution Procedure

1. Capture the LED state and diagnostic buffer. Photograph the front panel of the CPU 315-2 DP. Open STEP 7 / TIA Portal online, save the diagnostic buffer to CSV, save the OB82 local-data DB to a backup, then clear the buffer. This becomes the baseline.
2. Confirm OB82 is loaded. In STEP 7: Blocks > check OB82 is present. If not, add it and reload the program. A missing OB82 will manifest as a CPU STOP on the first diagnostic interrupt, which is a different failure mode than the one described here.
3. Verify the input address against hardware. In HW Config, expand the DP slave that owns logical address 1030 and identify the slot and module. Confirm the I 1030.0 channel is on the slot indicated by the buffer. A wrong hardware configuration can produce an SF with no channel error.
4. Check PROFIBUS physical layer. Inspect the PROFIBUS connector on the CPU and on the affected remote station. Open the terminating resistor switch on all devices except the two end nodes. Measure A-B line resistance: it should be ~220 Ω at the two ends, ~110 Ω at the middle of the segment.
5. Check slave power supply. With the system running, watch the DC OK LED on the PS 307 of the remote station. A sagging PS will produce exactly the symptoms in this case. Log the 24 V rail with a scope during machine start-up cycles.
6. Hot-swap the bus module. Power down the remote station, swap the IM 153 / IM 151 with a known-good spare of the same catalog number, power up, and run the machine for 24 hours with the OB82 capture DB active.
7. Validate the fix. If the SF LED clears and the OB82 capture DB shows zero new incoming events for the production cycle, the bus module was the failure. Roll the swap into a permanent repair and update the machine's spare-parts list.
8. If the SF persists after a bus-module swap, proceed in this order: replace the MMC, then the PROFIBUS cable, then the I/O card on the slot, then the CPU as a last resort. The CPU 315-2 DP has no user-serviceable parts inside the housing.

8. Hardware Reference and Catalog Numbers

The following part numbers are the field-replacement candidates for this fault class. Match firmware versions and hardware revisions exactly where possible; an IM 153-1 (6ES7153-1AA03-0XB0) cannot always be replaced one-for-one with an IM 153-2 (6ES7153-2BA02-0XB0) without re-commissioning the slave.

9. Verification and Commissioning

After the suspected component is replaced, run the following verification cycle before returning the machine to production:

1. Buffer baseline. Clear the diagnostic buffer. Note the time.
2. 24-hour soak. Run the machine through a full production cycle. The OB82 capture DB should show no new incoming diagnostic interrupts. The DB820.IncomingCount must remain 0.
3. LED check. SF off, BF off, RUN solid green, DC5V solid green, FRCE off, STOP off. Photograph the front panel.
4. Worst-case disturbance. Force an E-stop. Open and close the safety fence several times in quick succession. The system must NOT trip the 15-minute alarm pattern if the root cause is fixed. If it does, a second fault is present (usually a second aging IM on another slave).
5. PROFIBUS diagnostics. Open the DP master diagnostic view in STEP 7 / TIA Portal. All slaves should report OK with no Station failure or Diagnostic flags.

10. Preventive Measures and Field-Proven Caveats

• Always load OB82. It is the single most common cause of an SF-induced STOP on machines that run for years without problems. Add a comment in the program header to force the question at every code review.
• Capture OB82 temp into a DB and expose it to the HMI. Operators see the latest error timestamp and the module address on a screen, eliminating the 2-day forensic chase described in the original case.
• Schedule MMC replacement. MMC write-cycle endurance is finite. On machines that restart frequently, replace the MMC on a 5-year cycle to avoid mid-life MMC failures that produce the same SF pattern.
• Spare a matched IM 153 / IM 151. Keep one of the same catalog number on the shelf. Substituting a newer firmware revision of the same IM is normally safe, but mixing a 153-1 and a 153-2 will break the configuration.
• Validate PROFIBUS shielding on installation. Shield continuity from the CPU to the last slave, with the shield bonded at one point only, eliminates a large class of intermittent faults that masquerade as IM failures.
• Watch for the 1 ms glitch. The 1 ms loss referenced in the original case is shorter than a single PROFIBUS DP cycle at 1.5 Mbaud. A scope on the PROFIBUS A-B lines (differential, AC coupled) will not always show it. An oscilloscope on the remote-station 24 V rail during the disturbance is more revealing.
• Document the firmware version of the CPU and the IM. The CPU 315-2 DP and the IM 153 must run compatible firmware families; mixing V2.x and V3.x masters and slaves is a common cause of cryptic diagnostic events that look like hardware faults.

11. Quick Decision Matrix

12. FAQ