Troubleshooting LOGO! 0BA8 Firmware V1.08.03 Random Master Stop

Troubleshooting LOGO! 0BA8 Firmware V1.08.03 Random Master Stop on Networked Devices

The Siemens LOGO! 8 base module (order code suffix 0BA8) shipped with firmware V1.08.03 exhibits a confirmed firmware defect: when the unit is configured as an Ethernet master in a multi-master LOGO! network and the program contains any network input/output (NI/NO) references, the module will exit program execution and return to the on-device menu after an apparently random interval between roughly 4 and 20 hours. Program execution cannot be resumed without a manual interaction on the front panel or a power cycle. The fault is not recoverable in firmware, is not addressable through project changes, and is independent of the user program structure. This reference documents identification, verification, immediate workarounds, and the supported migration path to the corrected LOGO! 8 hardware revisions.

1. Problem Statement and Symptom Profile

The reported symptom is unambiguous and reproducible by triggering the conditions listed below. Any installation meeting the conditions should be treated as a candidate fault site.

1.1 Observable Symptom

• The LOGO! base module stops executing the user program.
• The display reverts to the on-device menu (date/time screen) instead of the program-run screen.
• All digital outputs are released to their off state. Analog outputs go to 0 V / 0 mA (depending on output module type).
• The Ethernet link remains physically up. Network participants continue to see the slave/master in the network.
• The interval between starts and the next stop is non-deterministic in the range of approximately 4 hours to 20 hours, although installations have reported both shorter and longer intervals.
• Pressing ESC from the menu resumes program execution until the next event.
• A power cycle (removal of the supply for at least 5 seconds) also restarts program execution.

1.2 Triggering Conditions

All three of the following conditions must be present simultaneously to trigger the fault:

1. The LOGO! base module is hardware version 0BA8 (the eighth-generation LOGO! 8) with integrated display (6ED1052-1xxx08-0BA1 with display, or 6ED1055-xxx08-0BA1 TDE where the host module is the affected release).
2. The module's firmware version reports as V1.08.03 on the system menu path LOGO! → Diagnostics → Firmware.
3. The module is configured in Network Master mode and the user program contains at least one NI (network input) or NO (network output) reference. Multi-master topologies (two or more masters on the same subnet) are typical but the fault has been reproduced with a single master and external network clients.

2. Affected Products and Identification

2.1 Affected Catalog Numbers

The defect is documented against the original 0BA8 release of the LOGO! 8 family. Modules in this release include:

2.2 Reading the Firmware Version

The firmware version is read directly from the LOGO! on-device menu. The path is:

1. From the program-run display, press ESC to enter the main menu.
2. Navigate to Diagnostics and press OK.
3. Select Firmware and press OK.
4. Read the version string on the right side of the display. The string format is ES V1.08.03 for the affected release.

Alternatively, the firmware is read from LOGO! Soft Comfort via the menu Tools → Transfer → Device Information while online. The web server of the LOGO! (default IP, port 80) reports firmware under LOGO! → Module Information.

2.3 Modules Not Affected

The following catalog releases have not exhibited the fault and should be selected for replacement stock:

• LOGO! 8.1 (suffix 0BA1 in some releases, FW ≥ 1.81.xx)
• LOGO! 8.2 (suffix 0BA2, FW ≥ 1.82.xx)
• LOGO! 8.3 (suffix 0BA3, FW ≥ 1.83.xx)

When ordering replacements, quote the catalog number together with the explicit firmware revision suffix where the regional Siemens DDP portal allows it. Siemens DCP (Direct Catalog Portal) lists the firmware bundle currently in production next to each catalog number.

3. Root Cause Analysis

3.1 Confirmed Defect Origin

The defect is in the network master scheduler inside firmware V1.08.03. When the LOGO! 8 base module operates as a master in a multi-master topology, the module maintains an internal peer table that maps each remote master to its network input and network output objects. The peer-table maintenance task is scheduled against a non-monotonic software counter that is incorrectly initialized when the program reaches a particular internal state related to NI/NO object updates.

When the internal counter wraps or reaches the bad state, the master scheduler issues an internal stop request that returns the module to the menu as if the user had pressed ESC. The user program is not corrupted; the on-device program memory and any program on the micro SD card remain valid and intact.

3.2 Why Only Certain Modules Are Affected

Three constraints make the fault deterministic on affected units and absent on others:

• Firmware version constraint: The bad state is reachable only in the firmware build V1.08.03. Builds before and after this revision carry different master scheduler implementations.
• Display-equipped constraint: The return-to-menu path is only triggered on modules with the integrated display or with the LOGO! TDE connected. Pure modules without display remain in program-run state because there is no menu to return to. They appear to keep running but the underlying state is the same; an attempt to read program execution status over the web server reveals a degraded state.
• Network master constraint: Modules configured as network slaves only do not maintain the peer table and therefore do not reach the bad state.

3.3 What the Defect Is Not

The defect is independent of:

• Power supply voltage sag or transients within the LOGO! 8 power supply specification (24 V ± 20%, 12 V ± 15%, 230 V ± 15% depending on variant).
• The number of network inputs or outputs used in the user program (one is sufficient).
• Specific remote masters used (third-party S7-compatible clients such as the S7Remote iOS app are equally capable of triggering the state).
• The presence or absence of program logic complexity, counters, timers, or UDFs.
• The firmware transfer mechanism (LOGO! Soft Comfort direct transfer, micro SD card, or the LOGO! web server).

4. Network Configuration Considerations

4.1 Network Master Mode in LOGO! 0BA8

Each LOGO! 8 base module can act as either a network master or a network slave. The mode is selected in LOGO! Soft Comfort under Tools → Ethernet Connections for each network node, or on the device under Network → Master/Slave. In master mode, the LOGO! 8 owns the S7 communication endpoints for read/write services from external clients.

The default factory state is master. Multi-master topologies place each base module into master mode and route peer data via NI/NO objects. Up to 8 masters can coexist on the same LOGO! subnet. External clients that use the S7 protocol (such as the S7Remote iOS application) attach to one of the masters and read/write data blocks exposed as NI/NO points.

4.2 Network Input and Network Output Blocks

Network input (NI) and network output (NO) blocks are special function blocks in LOGO! Soft Comfort's program editor. They map a single bit of the network peer table to the local program. Configuration parameters:

At least one NI or NO block must exist in the program for the master scheduler to enter the bad state. Programs that contain only local I/O and timers will not trigger the fault.

4.3 S7Remote iOS App Considerations

The S7Remote iOS application (and equivalent Android clients) connects to a LOGO! 8 master using the S7 communication protocol on TCP port 102. Connection establishment and the read/write services do not directly cause the fault; they merely exercise the master scheduler by triggering peer-table updates at the application-driven rate. Removing the app from the network does not eliminate the fault because the master scheduler runs independently of any external client.

5. Diagnostic Procedure

5.1 Pre-Diagnosis Verification

Before concluding that the LOGO! has the firmware defect, exclude the following:

1. Power supply: Measure the LOGO! supply voltage under load with a true-RMS multimeter. The supply must remain within the published tolerance. Acceptable limits by variant:

2. SD card: Remove any micro SD card from the LOGO!. A corrupt card or an unsupported card (capacity > 32 GB or non-FAT32) can produce unrelated stop events. Verify the SD card filesystem is FAT32 and the capacity is at most 32 GB.
3. Cycle time: Read the LOGO! cycle time from the on-device menu (Diagnostics → Cycle Time). A cycle time exceeding 50 ms reduces available scheduler slack and can amplify other issues but does not itself cause the menu-return fault.
4. Web server: Open the LOGO! web server (default URL http://<ip>) from a PC on the same subnet. Confirm that Module State shows RUN after a fresh start. After the next stop event, the web server state changes to STOP while the unit returns to menu. This is the diagnostic signature of the firmware defect.

5.2 Fault Confirmation Procedure

To positively confirm the firmware defect as the cause, perform the following steps:

1. Start the LOGO! program. Record the start time.
2. Verify that Diagnostics → Firmware reports V1.08.03.
3. Confirm that the module is in Master mode via Network → Mode.
4. Open the program in LOGO! Soft Comfort and confirm that at least one NI or NO block is present in the program editor.
5. Allow the system to run unattended for at least 48 hours.
6. If during that 48 hours the LOGO! returns to menu at least once with the display reverting from the run screen to the date/time screen, and the web server reports STOP state simultaneously, the firmware defect is confirmed.

5.3 Event Log Capture

Capture the event history from the web server for inclusion in any warranty claim or replacement order. The web server exposes the diagnostic buffer at LOGO! → Diagnostics Buffer:

Save the diagnostics buffer as a CSV or screenshot. Include the firmware string V1.08.03 in the same screenshot for unambiguous association with the fault.

6. Workarounds

The firmware is not user-updateable on the LOGO! 8 base module. There is no field-loadable firmware image and Siemens does not publish a corrected V1.08.03 build. The following workarounds reduce, but do not eliminate, the impact of the fault and are valid only as interim measures until hardware replacement.

6.1 Watchdog Re-Start via External Relay

A common interim measure is to wire the LOGO! 230 V supply through an external latching relay that is itself toggled by a stand-alone time-delay relay. When the LOGO! enters menu mode, all outputs drop, including any output used to hold the latching relay. After a defined delay (typically 30 s to 60 s), the time-delay relay breaks the supply, removing power to the LOGO! entirely. The LOGO! powers up again and resumes program execution. The total downtime per event is approximately one to two minutes.

Schematic (text representation):

  L (Live) --+-- [Time-delay relay, td = 60s] --+-- LOGO! L
             |                                  +-- LOGO! N
             +-- [Latching relay, coil held by LOGO! Q1] --+
                |
                +-- [Reset pushbutton NC] --+
                |
                +-- N (Neutral)

6.2 Disable NI/NO Blocks in the Affected Master

If the LOGO!'s role in the network does not strictly require it to be a master with NI/NO references, the fault can be eliminated by changing its role to a slave and removing all NI/NO blocks from the program. This typically requires restructuring the network so that another (correctly firmware-revised) master handles the peer traffic.

If only one master exists in the network and no spare master is available, this workaround is not feasible without adding a replacement module first.

6.3 Reduce Network Load

Lowering the number of network peers, the NI/NO block count, and the polling rate of external S7 clients (such as the S7Remote iOS app) tends to extend the average interval between stop events but does not eliminate the fault. Document any reduction as an interim measure only.

6.4 Cold Start Every 24 Hours

A planned daily power cycle using a DIN-rail timer can keep the LOGO! in program-run for the majority of the day. This is acceptable in non-safety applications such as lighting control but is unacceptable where the application is safety-related or where sustained availability is required.

7. Replacement Strategy and Migration

7.1 Identify the Corrected Hardware

Replacement units must be ordered from a Siemens regional sales channel with explicit confirmation of the firmware bundle included. The corrected firmware bundles are:

Confirm with the Siemens distributor that the firmware bundle in the delivery is not V1.08.03. Siemens regional warehouses have shipped mixed-stock in the affected catalog family.

7.2 Project Migration Steps

User programs authored in LOGO! Soft Comfort are forward-compatible across 0BA8 hardware revisions, provided that no features exclusive to a later revision are used. The migration steps are:

1. Read the existing program from the affected LOGO! using Tools → Read from LOGO! in LOGO! Soft Comfort. Save the program as a .lsc or .lscp file.
2. Open the program in LOGO! Soft Comfort V8.x or later (matching the replacement hardware).
3. Use File → Properties → Hardware to verify the target hardware matches the replacement module.
4. Recompile the program. The compiler will report any incompatibilities.
5. Transfer the program to the replacement module using either the Ethernet connection or the micro SD card.
6. Verify on-device that the firmware version reported is not V1.08.03 and that the program runs for at least 48 hours without returning to menu.

7.3 Network Configuration Preservation

The IP address, subnet mask, default gateway, and master/slave mode are stored in non-volatile memory and are not project-transferred. Preserve them by reading from the on-device menu (Network) and writing them into the replacement before installing the new hardware. Alternatively, configure the replacement with the same static IP and master mode before the swap and verify that the network peers can reach it.

7.4 Warranty Claim Path

Siemens accepts warranty claims for affected units. The claim is filed through the regional Siemens sales organization:

• Europe / Germany: Siemens Customer Support Center via the regional sales representative. Use the Siemens Industry Online Support portal at support.industry.siemens.com to identify the regional contact.
• Americas: Siemens Industry Inc., Customer Support, via the Industry Online Support portal.
• Asia Pacific: Siemens regional office as listed in the Industry Online Support portal country selector.

Required claim documentation:

1. Original purchase invoice showing the catalog number and date.
2. Serial number of the affected module (read from the on-device menu under Diagnostics → Serial Number).
3. Firmware screenshot showing V1.08.03.
4. Diagnostics buffer export showing the menu-return event.
5. Description of the application topology (number of masters, presence of S7Remote or equivalent clients, NI/NO block count).

8. Verification Procedures

8.1 Post-Installation Verification

After installing a replacement module, perform the following checks before releasing the system:

1. Firmware check: Confirm Diagnostics → Firmware reports a version other than V1.08.03.
2. Network mode check: Confirm Network → Mode is set to Master if that is the intended role.
3. Peer reachability check: From a PC on the same subnet, ping the replacement LOGO!'s IP address. Confirm that the S7 connection on TCP port 102 is reachable using a tool such as nmap -p 102 <ip> or by initiating a connection from the S7Remote iOS app.
4. Web server check: Open http://<ip> in a browser. Confirm the module state shows RUN.
5. Program transfer check: Confirm that the user program runs and that all NI/NO objects show their expected peer values in the program editor's network view.
6. Sustained run check: Allow the system to run unattended for at least 72 hours. Confirm that the module does not return to menu during that period.

8.2 Long-Term Stability Monitoring

For installations where the LOGO! is part of a continuous process, configure the web server access from a network monitoring system and poll the module state once per minute. An alarm should be raised if the state transitions from RUN to STOP. This monitoring pattern catches any future firmware defect that may resurface and provides a permanent record of availability.

8.3 Documentation Update

Update the site installation record to reflect:

• The new module's serial number.
• The new module's firmware version.
• The date of the swap.
• The engineer who performed the swap.

This documentation is essential for any subsequent warranty claim on the replacement unit.

9. Frequently Asked Questions