LOGO! 8 FS03 Network Stop Crash: Root Cause and FS04 Firmware Fix

David Krause13 min read
PLC HardwareSiemensTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Problem Overview

Siemens LOGO! 8 (0BA8) controllers shipped between spring 2016 and the release of firmware FS:04 in late 2016 can exhibit an irregular, unrecoverable transition into STOP mode once a network is attached. The defect is independent of the user program: it reproduces with stock demo programs and persists after a complete program rewrite. In the field, the symptom appears as a base module that has been running for minutes, hours, or days, then spontaneously drops to STOP. All networked expansion modules and the TDE lose communication simultaneously, and the process controlled by the LOGO! halts without a diagnostic entry that points clearly at the cause.

Field reports concentrate on three configurations:

  • LOGO! 12/24 RCE or 230 RCE base module with firmware V1.08.03 (factory state FS03)
  • At least one LOGO! TDE text display connected over Ethernet
  • One or more networked slaves — either another LOGO! base module acting as a slave, a LOGO! DM16/DM8 expansion, or both

Removing the TDE, removing the slaves, or both, suppresses the failure mode. Reintroducing either brings the random STOP behavior back within hours to weeks. The defect does not require user-side networking traffic; the link being present is sufficient.

Affected Hardware and Typical System Topology

The failing systems share a recognizable architecture:

  • Master: LOGO! 12/24 RCE (order number 6ED1052-1MD08-0BA0) or LOGO! 230 RCE (6ED1052-1FB08-0BA0)
  • Local digital I/O on the master: One or two LOGO! DM16 24R (6ED1055-1MB10-0BA0) or LOGO! DM8 24R
  • Analog output: LOGO! AM2 AQ (6ED1055-1MM00-0BA0) for 0–10 V or 4–20 mA loops
  • Networked slave base: A second LOGO! 12/24 RCE or LOGO! 12/24 (6ED1052-1MD08-0BA0 / 6ED1052-1CC08-0BA0) acting as an Ethernet slave, carrying its own LOGO! DM16/24R
  • HMI: LOGO! TDE (6ED1055-4MH08-0BA0) text display
  • Ethernet infrastructure: SCALANCE XB008 unmanaged switch (6GK5008-0BA00-1AB2) or direct crossover cabling

This is a textbook LOGO! 8 maximum configuration: the master supports up to eight LOGO! expansion modules on its local bus, plus up to 16 network stations on Ethernet (a mix of slaves and TDEs). The firmware defect is triggered when the master must service both the Ethernet connection to the TDE and the Ethernet peer connection to a slave base module simultaneously.

Configuration note: On the local bus, digital expansion modules (DM8/DM16) must be the leftmost addresses; analog modules (AM2/AM2 AQ) and the bus terminator are positioned to the right of any digital modules per the LOGO! 8 wiring guide. The network defect discussed here is unrelated to local bus layout, but verify physical addressing when migrating a program between a master-only configuration and a networked configuration.

Root Cause: FS03 Ethernet Subsystem Defect

The defect is in the LOGO! 8 base module firmware V1.08.03, which Siemens ships with the FS:03 (Function State 03) product variant. When the firmware services the internal Ethernet stack concurrently for:

  1. LOGO!-to-LOGO! slave messaging on UDP port 10005 (variable exchange)
  2. LOGO!-to-TDE messaging on UDP port 10004 (display update and key events)

an internal state-machine error can corrupt the Ethernet task and force the controller into the safe STOP state. The transition is not user-recoverable from the operator panel; power cycling the base module restores operation until the next occurrence.

Key engineering characteristics of the defect:

  • Random timing. Mean time between failures ranges from hours to weeks. The longer the system runs, the higher the cumulative probability that it has entered STOP.
  • Display + network requirement. Either a TDE on Ethernet or a slave base module on Ethernet alone is not sufficient to trigger the crash in every observed installation; the combination raises the probability sharply. A standalone master with no Ethernet peers does not exhibit the failure.
  • Program independence. The defect reproduces with empty programs, stock weekly timer examples, and complex production programs. The weekly timer function block (function block B13 in LOGO!Soft Comfort) is a red herring: it was added coincidentally in programs that were also edited and re-downloaded, but the STOP event is not caused by timer logic.
  • No diagnostic buffer entry. The LOGO! diagnostic buffer does not always contain a deterministic entry before the STOP. Operators typically see only the last state change. This makes the fault appear to be a power dip or an unreported operator action until enough cycles confirm a pattern.

Firmware Version Identification (FS State)

Siemens uses a Function State (FS) numbering scheme on LOGO! 8 hardware that advances in lockstep with hardware revisions and firmware bug-fix releases. The defect addressed here is FS:03, corrected in FS:04.

FS State Firmware Version on Base Module Status
FS:01 V1.00.xx Initial release, EOL 2015
FS:02 V1.04.xx EOL mid 2016
FS:03 V1.08.03 DEFECT — random STOP when networked with TDE and/or slave base module
FS:04 V1.08.04 FIX RELEASED — recommended baseline for all FS03 retrofits

To identify the FS state of a base module in the field:

  1. From the LOGO! front panel, navigate: ESC > Diagnostics > FW Version. The screen displays firmware version and build date.
  2. Compare against the table above. V1.08.03 on a 0BA8 standard base module is FS:03 and is the candidate for this defect.
  3. Cross-check via LOGO!Soft Comfort: connect to the base module over Ethernet, right-click the device, and read Properties > Firmware Version. Soft Comfort will also display the FS suffix when the module is in FS:04 or later.

Siemens Service Bulletin Timeline

Siemens engineering reportedly became aware of the failure mode in August 2016. Internal qualification of the corrected firmware on FS:04 hardware was completed in the same quarter. The first customer-facing communication (a service bulletin distributed through Siemens regional support) was issued in October 2016, coincident with the production transition from FS:03 to FS:04 base modules.

Systems purchased in spring 2016 are at the highest probability of being FS:03 stock. Systems purchased in late 2016 and onward are predominantly FS:04. Because LOGO! 8 base modules ship with firmware pre-installed and are not user-flashable through any field-portable procedure, the field resolution is hardware replacement under warranty — not a firmware push.

Permanent Fix: Replace the FS03 Base Module with FS04

The corrective action is hardware replacement. The FS:04 base module is functionally identical to FS:03 from a programming and I/O perspective; existing LOGO!Soft Comfort V8.x projects load without modification.

  1. Confirm FS:03 on the master. Verify via the front panel and via Soft Comfort as described above. If the slave base module is also V1.08.03, replace it as well, even if the master is the primary stopper — symmetric configuration reduces support risk.
  2. Open a warranty or spare-parts claim. Reference the FS:03 network STOP defect and the October 2016 service bulletin. Provide the serial number, firmware version, and the date code printed on the side of the module. Siemens spare-parts channels typically cross-ship an FS:04 replacement within 24–72 hours for warranty cases.
  3. Transfer the program. Connect the new FS:04 module, transfer the project from LOGO!Soft Comfort, and verify that the program runs in RUN mode.
  4. Re-attach the network. Power up the TDE and the slave base module in any order; the LOGO! network discovery restarts automatically.
  5. Burn the program to non-volatile memory. From Soft Comfort, transfer the program with the option "Save permanently in LOGO!" enabled, otherwise a power cycle of more than a few minutes can lose volatile configuration.
Critical: The user's program is stored in volatile RAM on the LOGO! 8 base module and is shadowed to onboard flash on every "Save permanently" transfer or "Save permanently via TDE" action. After an unexpected STOP event, do not power-cycle until the current program has been saved to flash; otherwise the rewrite effort will be repeated. If the STOP happens under power, retrieve the program via Soft Comfort's PC ↔ LOGO! transfer dialog before issuing any reset.

Workarounds When FS04 Hardware Is Not Yet Available

If a warranty replacement cannot be sourced within the production-critical window, the following mitigations reduce — but do not eliminate — the failure probability. None of these is a substitute for FS:04 hardware, but each has been observed to extend mean time between STOP events.

  • Disconnect the TDE. Removing the LOGO! TDE from Ethernet is the single most effective mitigation. The system continues to run with the local base module display only.
  • Reduce to a single Ethernet peer. If the slave base module is optional or non-critical, remove it and replicate its logic on the master. The master supports eight local digital expansion modules and four analog modules; many small sites can absorb the slave I/O on the master itself.
  • Remove the unmanaged switch. Direct-connect the master and the TDE (and slave, if used) with crossover cabling. SCALANCE XB008 is unmanaged and has been reported to forward broadcast storms to the LOGO! stack under certain fault conditions; direct connection eliminates that path.
  • Disable unused Ethernet services. In LOGO!Soft Comfort, project tree → Tools > Ethernet Connections: remove the slave and TDE connection blocks for any peer that is not strictly required. Reducing active UDP sockets reduces the surface area for the FS:03 race.
  • Schedule a manual restart. A daily power cycle at a non-production interval resets the internal state machine and clears accumulated corruption. Acceptable for non-continuous processes; unacceptable for 24/7 operations.

Diagnostic Procedure: Confirming the Defect Is the Cause

Before requesting warranty hardware, perform this field procedure to rule out program, wiring, and environmental causes.

  1. Capture the program from the base module using LOGO!Soft Comfort (Tools → PC ↔ LOGO! → Receive). Save the file with a timestamp.
  2. Verify firmware via the front-panel path ESC → Diagnostics → FW Version. Confirm V1.08.03 on a 0BA8 standard module.
  3. Note the network topology: which slave base modules, which TDE, which switches, cable lengths, and any other Ethernet devices sharing the segment.
  4. Reduce the program to a stock "two weekly timers + one input + one output" example. If the random STOP behavior persists, the program is exonerated.
  5. Remove the TDE from the network and run for 48 hours. If the system stops, proceed to step 6.
  6. Remove the slave base module (if used) and run for 48 hours. If the system stops, the defect is unlikely to be the cause; investigate power, EMC, and grounding.
  7. If the system stabilizes after removing the TDE or slave, document the change and request FS:04 hardware. The defect is the most likely root cause.

Programming Migration Notes: V8.0 → V8.1

A common field scenario is a system commissioned under LOGO!Soft Comfort V8.0 that is later edited under V8.1. The weekly timer change mentioned in the field report is not the cause of the STOP event, but the migration is a useful boundary to document:

  • LOGO!Soft Comfort V8.1 introduces additional function blocks (astronomical clock, stopwatch, analog comparator variants) and a revised Ethernet connection editor.
  • Projects written in V8.0 open in V8.1 without conversion loss. The reverse is not true; once a project is saved in V8.1, it cannot be edited in V8.0.
  • The Ethernet connection table in V8.0 uses one dialog; V8.1 adds per-connection diagnostics including last successful poll and error counters. Use the V8.1 diagnostics surface after upgrade to verify that the FS:04 hardware maintains steady communication with the slave and TDE.

After the FS:04 replacement, load the V8.0 project into V8.1, save it under a new project name, perform a transfer to the new base module, and let the system run under observation for at least 72 hours before sign-off.

Related Failure Modes Worth Excluding

Several conditions present as a LOGO! 8 that "stops" without diagnostic context. Confirm each is excluded before declaring the FS:03 defect to be the cause:

Condition Distinguishing Symptom Verification
Power dip / brownout All devices on the same circuit restart; not just the LOGO! Install a power-quality logger; check for voltage excursions below 20.4 V on 24 V systems or below 195 V on 230 V systems
Overload on digital output Specific output channel locks out; other outputs continue Measure output current; LOGO! 8 RCE digital outputs are rated 8 A resistive / 3 A inductive per relay
Loss of network peer NI (Network Input) flags go false but base module continues running Inspect Soft Comfort online monitor for NI/NQ flags and Ethernet status LEDs
SD card removal during write Base module reads "Card" or "Program" error on display Check SD card seating; reformat as FAT32 if necessary
EMC-induced reset Coincides with VFD switching or welding operations Verify shielding, ground bonding, and segregation from VFD power cables per the LOGO! manual
FS:03 STOP defect (this article) Base module drops to STOP, network disappears, no diagnostic buffer entry, recovers on power cycle Firmware V1.08.03, TDE and/or slave present on Ethernet

Verification Checklist After FS04 Replacement

Use this checklist before releasing the system to production after a hardware swap.

  • Firmware version on the new base module reads V1.08.04 or later, and FS:04 is reported by Soft Comfort.
  • Front panel shows RUN (not STOP) immediately after power-up and program transfer.
  • LOGO! TDE shows the configured start message and acknowledges all configured keys.
  • Slave base module reports its inputs and outputs correctly on the Soft Comfort online monitor.
  • LOGO!Soft Comfort diagnostic counters for Ethernet connections show zero timeouts over a 24-hour observation window.
  • The program is saved permanently (Tools → Transfer → PC → LOGO!, with "Save permanently" enabled).
  • A backup of the project file (.lsc) is archived with a date and revision tag.
  • The Ethernet network has been re-cabled; switches are powered from a clean 24 V supply; cable runs are within the 100 m copper limit.

Long-Term Recommendations

For installations with multiple LOGO! 8 base modules commissioned between 2016 and the FS:04 transition, audit the installed base:

  1. Inventory every LOGO! 8 base module on site.
  2. Capture firmware version and FS state for each.
  3. Flag any module at FS:03.
  4. For each flagged module, decide whether the network configuration (TDE + slave) is present — these are the highest-risk installations.
  5. Replace flagged modules under warranty or budget for spare-parts replacement on the next scheduled shutdown.

For new installations, specify FS:04 or later explicitly in purchase orders. Siemens continues to advance the FS state; check the current product matrix on the official LOGO! 8 product page before ordering.

Frequently Asked Questions

How do I confirm my LOGO! 8 base module is FS:03?

From the base module front panel navigate ESC → Diagnostics → FW Version. An FS:03 module reports firmware V1.08.03. In LOGO!Soft Comfort, right-click the connected device and open Properties; the FS state is shown alongside the firmware version.

Can I upgrade FS:03 to FS:04 with a firmware push?

No. The LOGO! 8 base module firmware is not field-flashable. The corrective action is hardware replacement with an FS:04 base module, which is electrically and functionally interchangeable with FS:03.

Will removing the LOGO! TDE stop the random STOP events?

Removing the TDE sharply reduces the probability of a STOP event, because the FS:03 firmware defect is triggered by the combination of Ethernet slave messaging and TDE messaging. It is not a permanent fix — the base module can still stop if a networked slave is present — and Siemens recommends hardware replacement.

Is the weekly timer function block (B13) the cause of the STOP events?

No. The weekly timer is unrelated to the defect. Systems with empty programs and no weekly timers have been observed to enter STOP under the same FS:03 firmware when the network configuration is present. The timer change is a coincident program edit, not a cause.

Do I need to rewrite my LOGO!Soft Comfort project when migrating from V8.0 to V8.1?

No. Projects authored in V8.0 open in V8.1 without conversion. Once saved in V8.1 they cannot be reopened in V8.0, so save under a new name if you need to retain the V8.0 master copy. Existing function blocks, Ethernet connections, and I/O configurations transfer unchanged.

What should I do before power-cycling an FS:03 base module after an unexpected STOP?

Transfer the running program off the base module using LOGO!Soft Comfort (PC ↔ LOGO! → Receive) before cycling power, and save the project to disk with a timestamp. After power-up, transfer the project back to the base module with "Save permanently" enabled so that the program survives the next power loss.

Back to blog