1. Overview
A SIMATIC S7-1500 CPU that returns from an extended shutdown with SF steadily lit and BF-PN flashing while RUN remains green is exhibiting the canonical signature of a PROFINET IO station failure with an accompanying system diagnostic event. The CPU itself is still executing the user program (RUN is on, STOP is off, FORCE is off, ON is on, MT is off); the field devices downstream of the PROFINET interface are the most probable root cause.
This reference covers three engineering tasks that must be done together to recover the system:
- Decode the LED status into a fault class.
- Read the diagnostics buffer with or without the project password.
- Bring the PROFINET network back up by inspecting cabling, power, and station configuration.
The procedure applies to CPU firmware versions in the V2.x through V3.x generation of the S7-1500 family (6ES7516-3AN02-0AB0, 6ES7515-2AM02-0AB0, 6ES7513-2AL02-0AB0, 6ES7511-1AK02-0AB0) and the equivalent S7-1200 CPUs where behaviour overlaps. Always confirm against the manual for the specific order number (MLFB) in service.
2. LED Status Decoded
Every S7-1500 front panel reports the same nine indicators regardless of the CPU variant. The user's report shows the following combination:
| LED | User Report | Meaning per Siemens Manual |
|---|---|---|
| SF (red) | ON | System Fault: at least one diagnostic event is pending in the diagnostics buffer (CPU module fault, station failure, or hardware interrupt). |
| BF-PN (red) | FLASH | Bus Fault on PROFINET interface X1 or X2: physical link present, but PROFINET controller detected a station diagnostic, watchdog, or configuration mismatch. Steady ON = no link at all; flash = link with logical fault. |
| MT (yellow) | OFF | No maintenance demand pending (no forced check, no firmware update in progress). |
| ON (green) | ON | Power supply within tolerance on the 24 V backplane. |
| FORCE (yellow) | OFF | No permanent force job is currently active in the CPU. |
| RUN (green) | ON | CPU is in RUN: OB1, cyclic OBs, and the user program are executing. |
| STOP (yellow) | OFF | CPU is not in STOP. The user program is running despite the faults. |
The RUN-on / STOP-off combination is decisive. It tells you the CPU never halted because of the fault; it is still running, but downstream IO is either missing, mis-configured, or in diagnostic. The plant appears "dead" because the IO it depends on is dark. Treat the LED matrix as a fault-class discriminator, not as the fault itself.
3. Understanding BF-PN Flash Patterns
The BF-PN LED on the S7-1500 has three visible states:
| State | Interpretation |
|---|---|
| OFF | All configured PROFINET IO devices are in cyclic data exchange without error. |
| Flashing (2 Hz) | A physical link is up to one or more ports, but at least one configured device has a station diagnostic. The controller is alive but cannot complete cyclic IO. |
| Steady ON | No link to any port on the PROFINET interface; cable removed, switch powered down, or device-name assignment missing on a newly replaced station. |
The fact that BF-PN is flashing rather than steady is informative: the cabling is intact, the switches are powered, but a station has dropped out or is reporting a channel fault. This is the common signature of a single failed ET200SP / ET200MP station, a tripped power feed on a remote island, or a device whose Profinet name was cleared during a battery-backed RAM loss.
4. Diagnostics Buffer Fundamentals
The CPU maintains a non-volatile diagnostics buffer that contains one entry for every diagnostic event the CPU classifies, including station failure, module fault, time change, and warm restart. Each entry records:
- Timestamp (CPU local time, resolution 1 ms)
- Event ID (hexadecimal, e.g. 16#0203)
- Event class (Information / Warning / Error)
- Source of the event (CPU, PROFINET IO, module, OB call)
- Description and additional information (slot, station number, vendor ID)
The buffer is battery-backed where a battery is fitted (CPU 1515, 1516, 1517, 1518) and otherwise stored in retentive flash. It survives a power cycle and is the most reliable record of what happened during the outage. Per the official S7-1500 diagnostics documentation, the buffer is the primary tool to convert a flashing BF-PN into a specific station and slot.
Reference: System Diagnostics with S7-1500 and TIA Portal (Siemens Support, attachment 68011497).
5. Accessing the Diagnostics Buffer Without the Project Password
A common field question is whether the diagnostics buffer can be read without the TIA Portal project password. The answer depends on the access path.
| Access Path | Password Required? | Read Buffer? | Clear Buffer? | Notes |
|---|---|---|---|---|
| TIA Portal > Online > Diagnostics Buffer | Yes, if the project is protected | Yes (read-only) | No | Reading is permitted even without the password in some configurations; clearing is not. |
| Standard Web Server > Diagnostics Buffer page | No (with default user 'Anyone') | Yes | No | Read-only by default. Available on CPUs with firmware V2.0 and later. Reference: TIA Portal Cloud - Diagnostics Buffer standard web page. |
| S7-1500 Display > Diagnostics > Buffer | No | Yes (most recent 50 entries) | No | Use front-panel navigation: Settings > Diagnostics > Buffer. Best option when the password is lost. |
| SIMATIC Automation Tool | No (LAN scan) | Yes (export CSV) | No | Useful for field engineers without a TIA Portal license. |
To open the buffer from the front-panel display:
- Navigate
Main Menu > Diagnostics > Buffer. - Use the arrow keys to scroll entries; the most recent is on top.
- Press OK on an entry to see the timestamp, event ID, and slot information.
- Screenshot if needed; the display does not export text.
To read from the web server:
- Confirm the web server is enabled in the CPU properties > Web server > Activate.
- Open a browser to
http://<cpu-ip>. - Click Diagnostics Buffer under the Information area.
- Read top-down: the most recent entry is the start point.
6. Common Diagnostics Buffer Events for BF-PN Cases
The S7-1500 categorises PROFINET events using standardised event IDs. The following patterns recur in field reports of "BF-PN flashing after long downtime". Reference: Siemens S7-1500 System Diagnostics manual.
| Event Class | Typical Cause | Where to Look in the Buffer |
|---|---|---|
| Station failure | ET200 station powered off or removed from network | Look for PROFINET IO > Station Failure entries tied to a specific device name. |
| Station return | Station back online | Followed by Station Return event for the same device. |
| Module fault | A specific slot in an ET200 reports diagnostic | Module-specific event with slot number; check the channel diagnostics of that module. |
| Configuration error | Slot in the station has an actual vs configured mismatch (wrong module, missing module) | Buffer will explicitly state slot and expected vs actual order number. |
| Device name missing | A replacement station was not assigned a Profinet name | Look for "PROFINET device name does not exist" or "Device is not configured". |
| Time-of-day change after power-up | Retentive time lost; clock resynchronisation | An entry at power-up stating the time was reset; indicates the battery is dead. |
Confirm the device number (1, 2, 3, ...) and slot from the buffer entry; this pinpoints which physical cabinet on the plant floor needs investigation. Do not assume the BF-PN LED pattern alone tells you which station failed; the diagnostics buffer always identifies the specific source.
7. Hardware Field Checks Before Touching the Program
When BF-PN is flashing and the CPU is still in RUN, the program is not the most likely cause. Focus on the field layer first:
- Check the 24 V supply at every ET200 station. A UPS that discharged over the shutdown, a circuit breaker that tripped, or a power supply that failed in the first minutes after re-energisation is the most common single cause.
- Re-seat PROFINET cables and check connector latches. Look for green link LEDs on the S7-1500 ports X1P1/X1P2 and on the affected station. A port that has no link LED rules out cabling; a port with link LED but a flashing BF rules in a logical fault.
- Verify switches and managed network devices. A managed switch that lost its configuration file during a long power-down may have reverted to a default VLAN, isolating the station.
- Inspect the device name on every station. When a station is replaced (e.g. a failed ET200SP head module), the new device has no PROFINET name. Use the PRONETA or TIA Portal topology editor to assign the name.
- Check the battery or capacitor status. If the CPU lost its retentive data, IO device names configured via DCP may also need re-assignment. A yellow MAINT LED (MT) flags maintenance demand; in the user's case MT is off, so this is unlikely to be the issue.
8. PROFINET Network Recovery Procedure
- Open TIA Portal and go online with the CPU using the project file (or via PRONETA without the project).
- Right-click the CPU > Online & Diagnostics > Diagnostics Buffer. Sort by date descending.
- Identify the device name in the Station Failure entry. Note the IP address and PROFINET device number.
- Open Online & Diagnostics > PROFINET diagnostics; the topology view shows red for the failed device.
- Physically inspect the cabinet of that device. Confirm 24 V at the power module, link LEDs on the switch port and PROFINET port.
- If the station was replaced, assign the device name: Online & Diagnostics > Assign PROFINET device name.
- Once the station returns to cyclic exchange, BF-PN extinguishes and the corresponding Station return event appears in the diagnostics buffer.
- Clear the SF LED only after the buffer shows no remaining pending errors. The SF LED clears automatically on the next power cycle once the underlying diagnostic is resolved.
9. Long-Downtime Failure Patterns
After a planned maintenance shutdown of weeks or months, four hardware-related faults dominate S7-1500 reports:
| Pattern | Likely Cause | Diagnostic Clue |
|---|---|---|
| BF-PN flash + SF on after power-up, one station missing | ET200 power supply or breaker tripped | Buffer shows single Station Failure entry at power-up timestamp |
| BF-PN flash + SF on + multiple station failures | Managed switch or fibre ring interrupted | Buffer lists multiple Station Failures at the same timestamp |
| BF-PN flash + SF on + MT on | Battery exhausted; retentive PROFINET names lost | Buffer shows maintenance event and multiple "device name not assigned" entries |
| BF-PN steady + SF off | Cable physically removed | Buffer shows "Link down" events; no station failure |
If your buffer does not show station failures but only link events, the fault is the cable, not the station.
10. Can a Programmer Build a "Time Bomb" That Causes This?
Direct answer: it is theoretically possible for a programmer with project access to write OB calls, time-of-day comparisons, or forced variables that alter PLC behaviour on a specific date. However, the LED signature described in this case is not consistent with such a design:
- A user program that crashed the CPU would put the CPU in STOP, not RUN. The user's CPU shows RUN on and STOP off.
- A user program cannot directly toggle the BF-PN LED; BF-PN is driven by the PROFINET controller firmware, not by user code.
- A user program cannot cause the SF LED by itself; SF reflects hardware or station-level diagnostics that the CPU records in the buffer.
The legitimate engineering response is therefore: investigate the hardware first, read the diagnostics buffer second, and only consider the user program a candidate root cause if the buffer shows OB-related errors, time-stamped user-program faults, or programming errors with timestamps that line up with the failure. Engineering ethics aside, a sabotaged S7-1500 program would have to defeat the password protection, the know-how protection, and the operating system in a way that no documented API permits. Plant failures after long shutdowns are overwhelmingly field-side, not software-side.
11. Step-by-Step Recovery Procedure
- Lock out and tag out the affected machine per local safety procedure.
- Confirm the CPU LED state matches the matrix in Section 2.
- Read the diagnostics buffer (front display, web server, or TIA Portal).
- Identify the station number(s) and slot(s) reported.
- Walk to the cabinets of those stations and check 24 V supply and link LEDs.
- Restore power, re-seat connectors, assign PROFINET device names if the station was replaced.
- Watch the BF-PN LED extinguish. Verify a Station return entry appears in the buffer.
- Confirm SF clears. If SF remains, return to step 3 and address the next pending event.
- Document the fault, the station, the cause, and the timestamp in the maintenance log.
12. Verification and Commissioning
After recovery, verify the system is healthy:
- All PROFINET LEDs green on every station.
- BF-PN OFF on the CPU.
- SF OFF on the CPU.
- Diagnostics buffer shows the last entry as a normal operating event, not an error.
- Run a process-level test on the formerly failed I/O (e.g. toggle an output, read an input) and confirm the expected response.
- Update the PRONETA topology export for the maintenance record.
If SF returns immediately on power-cycle, escalate to Siemens Technical Support with the diagnostics buffer export attached.
13. Preventive Recommendations
- Replace the CPU backup battery before its expiry date; an exhausted battery is the leading cause of "looks like sabotage" after long shutdowns.
- Keep the PROFINET topology diagram and device-name table in the maintenance binder; a replacement station can be re-named in seconds when the names are documented.
- Export the diagnostics buffer to a CSV via TIA Portal or the SIMATIC Automation Tool at every major planned shutdown. The export becomes a baseline for the next start-up.
- Configure the standard web server with read-only access for maintenance staff so the diagnostics buffer is available without the project password.
- Document every planned PROFINET device name and IP assignment in the project. Avoid relying on DCP auto-assignment in production networks.
14. Frequently Asked Questions
Can I read the S7-1500 diagnostics buffer without the project password?
Yes. Use the S7-1500 front-panel display (Main Menu > Diagnostics > Buffer) or the standard web server page (no password required for the default 'Anyone' user). TIA Portal also allows reading the buffer even when the project is protected. Reference: TIA Portal Cloud - Diagnostics Buffer standard web page.
What does a flashing BF-PN LED with RUN solid on S7-1500 mean?
The CPU is running and the PROFINET link is physically present, but at least one configured IO device has a station diagnostic. The CPU records a Station Failure event in the diagnostics buffer identifying the device. Check 24 V power and cabling on the named station.
Can a programmer make the S7-1500 stop working on a specific date?
A user program cannot directly turn on BF-PN or SF LEDs; those are driven by the PROFINET controller and the diagnostic system. A user program that crashes the CPU would put the CPU in STOP, not RUN. If your CPU shows RUN with BF-PN flashing and SF on, the cause is hardware, not program logic.
How do I clear the SF LED on S7-1500?
SF clears automatically when the underlying diagnostic event is resolved and the CPU records a corresponding return event in the diagnostics buffer. A power cycle also clears SF if the cause no longer exists. There is no manual "clear SF" button.
Where do I find the meaning of a specific event ID in the diagnostics buffer?
Open the entry in TIA Portal and read the Description and Additional Information fields; for S7-1500 the event catalogue is published in the system diagnostics manual at Siemens Support entry 68011497. Cross-reference the ID against the module-specific manual for the affected station.
Why does BF-PN flash and not stay steady on when a station fails?
Steady BF-PN means no link to any port (cable or switch lost). Flashing BF-PN means at least one port has a link, but a configured device has a station diagnostic. The pattern is therefore diagnostic of cable intact + station faulty, the most common field condition.
Is the diagnostics buffer preserved across a memory reset?
Yes. The diagnostics buffer is stored in non-volatile memory and survives MRES. This is by design, so post-mortem analysis is always possible. Entries are retained until the buffer rolls over (typically the last 500 events).