Diagnosing S7-300 SF LED Faults via Diagnostic Buffer 16#39C4

Overview: SF LED on the S7-300 CPU 315-2 DP

The SF (System Fault) LED on a Siemens SIMATIC S7-300 front panel indicates a non-fatal diagnostic event the CPU has detected in the central rack, distributed I/O, or its own firmware. On a 6ES7 315-2AG10-0AB0 (CPU 315-2 DP, firmware V2.x/V3.x), the SF LED is driven by the diagnostic buffer and the OB 80 / OB 82 / OB 85 / OB 86 / OB 87 / OB 121 / OB 122 error-handling organization blocks. The BF (Bus Fault) LED on the DP master port (X2) is a separate indicator dedicated to Profibus DP physical-layer problems.

An SF event does not stop OB 1 by itself; the CPU enters STOP only if the corresponding error OB is not loaded, the error is fatal, or a configured monitoring time (cycle, communication) is exceeded. That is why field engineers routinely see the line halt with the SF LED on, OB 1 suspended, and a diagnostic buffer full of repeating 16#39C4 (DP station failure) and 16#38C4 (DP station return) entries, often capped by a 16#3501 cycle-time overflow event calling OB 80.

Hardware Identification and Front-Panel LED Map

The CPU in the source case is a 6ES7 315-2AG10-0AB0. The two most diagnostic-relevant LEDs on this front panel are:

When SF is lit alone (BF off), the fault is not a Profibus physical-layer break; the diagnostic buffer will usually show a rack/IO/cycle/program error, not a DP station failure. When both SF and BF are lit, the Profibus DP side is suspect and the buffer will contain DP master diagnostic frames such as 16#39C4 (station failure) or 16#38C4 (station return).

Accessing the Diagnostic Buffer in STEP 7

STEP 7 (SIMATIC Manager or TIA Portal) exposes the buffer as a chronological list. To open it:

1. Connect the PG/PC to the MPI/DP port of the CPU (default MPI address 2, 187.5 kbit/s for CPU 315-2 DP).
2. In SIMATIC Manager: PLC → Diagnostic/Setting → Diagnostic Buffer.
3. In TIA Portal: Online → Diagnostics → Diagnostic buffer.
4. Sort by time (most recent on top). The newest entry is the current fault, not the root cause.
5. Click each entry to expand its detail pane: Event ID, OB requested, priority class, logical base address, and module/slave diagnostic data.

The buffer holds 100 entries on the S7-300; the oldest entry is overwritten when full. On a 315-2 DP with a charged backup battery, the buffer survives power cycle. Always export the buffer (Save As... in SIMATIC Manager) before clearing it, otherwise you lose the trend of recurring 16#39C4 / 16#38C4 pairs that pinpoints an intermittent Profibus problem.

Event-ID Decoding Table (S7-300 / CPU 31x)

Event IDs are 16-bit hexadecimal codes the CPU pushes to the buffer. The most relevant for the source case are listed below. Reference: S7-300 CPU 31xC and CPU 31x: Operating Instructions (Siemens entry ID 12996906) and the System and Standard Functions for S7-300/400 reference manual (Siemens entry ID 1214574).

Each 16#39C4 entry in the source buffer is "incoming" (Errore esterno, Evento entrante); each 16#38C4 is "outgoing" (Evento uscente). Counting those pairs over a 24 h window is the first diagnostic to perform — a single 39C4/38C4 pair per shift is acceptable noise on a noisy plant segment, but ten pairs per hour on the same slave number is a hard Profibus or slave-power problem.

Reading the Source Buffer: Slave 26 / Yaskawa Drive

The decoded entries in the original diagnostic buffer are reproduced below, translated from Italian, with the engineering-relevant fields exposed:

OB 86 is called by the operating system whenever a DP station, a Profibus line, or a configured-but-not-yet-failed slave drops out of the master's scan. The logical base address 1011 corresponds to the I-input area assigned in HW Config to slave 26; in the STEP 7 hardware catalog this typically maps to a Yaskawa Sigma-II or Sigma-V servo drive on a Profibus option card (e.g. SI-P1). The 11 ms average OB 1 scan time vs. the 150 ms cycle limit indicates that something is delaying OB 1 by ~140 ms when the slave is misbehaving — almost certainly OB 86's body (if loaded) is reading SFC 13 DPNRM_DG on the slave to log the diagnostic telegram, plus a SFC 12 D_ACT_DP deactivation/activation if a recovery strategy is implemented.

Why the SF LED Stops the Line: OB 80 + OB 86 Interaction

On a 315-2 DP, OB 80 is invoked when the configured maximum cycle time is exceeded. The default 150 ms is set under HW Config → CPU 315-2 DP → Properties → Cycle/Clock Memory. The 150 ms event in the source buffer states: "Execution time of the last cycle (ms): 150", with OB 1 itself as the cause. Three engineering consequences flow from that:

1. OB 80 is loaded — otherwise the CPU would have gone to STOP, not just lit SF.
2. OB 1 is the lagging OB — the Profibus OB 86 handler in the project is consuming so much time per call that OB 1 misses its 150 ms deadline each time the drive drops and re-attaches.
3. The probable chain is: Yaskawa drive transient → DP master sees 39C4 → OB 86 executes → user logic inside OB 86 calls heavy SFCs (DPNRM_DG, possibly BSEND/BRCV) → OB 1 is delayed → 16#3501 → OB 80 executes → SF LED lit → operator sees the line halt.

OB 86 is a high-priority class 25 OB and is allowed to interrupt OB 1. Its execution time, combined with any user logic inside it, is counted against OB 1's cycle budget. Field-proven practice is to keep OB 86 bodies to a minimum: set a flag, increment a counter, and let OB 1 poll the flag and perform the heavy recovery (SFC 12 D_ACT_DP, SFC 13 DPNRM_DG) on its next cycle.

Slave-Side Diagnostics: SFC 13 and the Yaskawa Option Card

The buffer's DPNRM_DG SFC 13 reads the diagnostic telegram of a DP slave. Pseudocode suitable for the OB 86 body in Structured Text (ST):

// SFC 13 - Read DP Slave Diagnostic (max 32 bytes)
"DPNRM_DG_DB"(REQ := TRUE,
             LADDR := 1011,        // logical base address from buffer
             RET_VAL := #iRetVal,  // return value, 0 = OK, 80A1h = timeout
             BUSY   := #bBusy,
             RECORD := P#DB100.DBX0.0 BYTE 32);
// if RET_VAL = W#16#80A1, slave is in failure - SFC does not return data

For a Yaskawa Sigma-II/III/V drive on a SI-P1 / SI-P3 Profibus option card, the diagnostic telegram contains the drive status word bits. When a 16#39C4 appears, the telegram cannot be read; the cause must be inferred from the master-side behavior. Use the Yaskawa SigmaWin+ tool (or the drive's keypad) to inspect Un001 (motor speed) and the alarm history at the moment of the dropout. Common field-proven root causes on Yaskawa DP nodes in a wet/washdown plant are:

• Resolver cable shield break → drive drops Profibus on a resolver fault.
• 24 V control power to the SI-P1 option card sagging on a washdown rinse (the 110 V/24 V miswire case in the source is a textbook version of this).
• Profibus cable shield broken at a flexed conduit in a wash zone → 39C4s correlate with the wash cycle.

Profibus Cable and Physical-Layer Diagnostics

When the 16#39C4 / 16#38C4 pair recurs, the physical layer must be measured. The dedicated tools listed by Siemens are:

Acceptance criteria for a healthy Profibus DP segment at 1.5 Mbaud (the default for a CPU 315-2 DP master when most slaves are Yaskawa drives):

• Idle voltage between A and B: 1.0 V ± 0.1 V when no traffic.
• Signal amplitude: 5.0 V ± 0.5 V (bus driver output).
• Edge rise time (10 % to 90 %): less than 1 µs at 1.5 Mbaud; segment length is the dominant variable.
• Terminating resistors: 220 Ω across A-B with 390 Ω pull-up to +5 V and 390 Ω pull-down to GND on both ends, only on the two physical ends of the segment.

Reference: PROFIBUS Installation Guideline from PI (PROFIBUS & PROFINET International) at profinet.com, and Siemens application note Profibus DP installation in the field (entry ID 6738400 on support.industry.siemens.com).

Cycle-Time Tuning: Lower the Pressure on OB 1

If the buffer shows 16#3501 alongside the 39C4/38C4 pairs, the OB 1 budget is the proximate cause of the visible stop. Two levers exist:

1. Raise the max cycle time: in HW Config, increase from 150 ms to 300 ms or 500 ms. This only hides the problem; do it as a temporary measure to confirm the diagnosis.
2. Reduce OB 1 work: move heavy diagnostics and Profibus recovery logic out of OB 86 and OB 1 into OB 35 (cyclic interrupt at 100 ms) or OB 100 (warm restart). Set a flag in OB 86; service the flag in OB 35.

Monitor the cycle time after the change with OB 1 variables (e.g. OB1_PREV_CYCLE in S7-300) or via STEP 7 online PLC → Monitor/Modify. The S7-300 also exposes SFC 64 TIME_TCK for microsecond-granularity readouts if you need to time-stamp a specific scan.

Field-Commissioning Procedure for a Recurring SF LED on CPU 315-2 DP

1. Read and export the diagnostic buffer (STEP 7 → PLC → Diagnostic buffer → Save As).
2. Count 16#39C4 / 16#38C4 pairs by slave number. If one slave dominates, that slave or its spur is the suspect.
3. Open HW Config: confirm the slave's diagnostic interrupt and slot are enabled. Uncheck "DP slave diagnostics" only as a last resort and only if OB 82 / OB 86 are intentionally suppressed.
4. Check OB 86 / OB 80 presence in the online Blocks view. If OB 86 is missing, the CPU goes to STOP on every DP drop. If OB 80 is missing, it goes to STOP on every 16#3501.
5. Measure the segment with ProfiTrace 2: idle voltage, signal amplitude per slave, reflections at terminators, shield continuity.
6. Inspect connectors: PG-type Profibus connectors (e.g. 6ES7 972-0BA12-0XA0) have a switchable terminating resistor; both ends only.
7. Walk the cable path alongside the production line. In a washdown plant, a single conduit dip or a junction box flooded with detergent replicates the exact 39C4/38C4 toggle seen in the source buffer.
8. Replace or add a Profibus Diagnostic Repeater on the segment feeding the suspect slave to electrically isolate the rest of the bus.
9. Verify the fix: monitor the diagnostic buffer for 72 h. The SF LED should remain off, no 16#39C4 should appear, and OB 1's OB1_PREV_CYCLE should be at most 30 % of the configured maximum.

Troubleshooting Matrix

Safety and Project-Handling Notes

FAQ