Resolving LOGO! CMK2000 Red RUN LED Causing 0BA8 STOP Loop

Resolving LOGO! CMK2000 Red RUN LED Causing 0BA8 STOP Loop

A persistent STOP condition on a Siemens LOGO! 0BA8 base module, accompanied by a solid red RUN LED on an attached LOGO! CMK2000 communication module, is a known interaction bug between the LOGO! 0BA8 firmware branch later than V1.08.01 and the CMK2000 side-bus handshake. The fault is reproducible only in networked configurations and cannot be cleared by a firmware update because the LOGO! 0BA8 base module firmware is factory-locked. This reference describes the affected hardware, the diagnostic procedure, the available physical-layer mitigations, and the verification steps to clear the loop from the field installation.

1. System Overview and Reference Topology

The Siemens LOGO! 8 family (internal product code 0BA8) is a compact logic module deployed in small-scale automation. A base module such as the LOGO! 8 12/24 RCE (article 6ED1052-1CC08-0BA0) provides the user-program execution engine, the integrated digital and analog I/O, and one Ethernet interface for programming, HMI connection, and peer-to-peer S7 communication. The LOGO! CMK2000 communication module is mounted on the right-hand side bus of the base module and adds a second Ethernet interface, IP routing, an integrated Web server, and — on the cellular variant (CMR2020) — 4G fallback. The CMK2000 carries its own microcontroller, its own firmware, and a separate Web interface; it is not a transparent bridge.

A typical affected installation looks as follows:

1.1 Logical Role of Each Component

• LOGO! 0BA8 base module — runs the user program, scans I/O, and exposes the integrated Ethernet port. This is the device that drives the field I/O.
• LOGO! CMK2000 — adds a second physical Ethernet interface, IP routing/NAT, the integrated Web server, and (on the CMR2020 cellular variant) a 4G modem. The CMK2000 is connected to the base module only through the side bus.
• KTP 700 Basic PN — provides the operator interface, communicates with the LOGO! 0BA8 over PROFINET or S7 communication.
• Industrial LAN / Router — carries the LOGO!-to-LOGO! peer traffic, SCADA polling, and cloud uplink traffic.

2. Problem Description

In affected installations the following sequence is observed:

1. The system is commissioned and runs normally for a variable period of several days.
2. The RUN LED on the CMK2000 changes from solid green to solid red.
3. Within seconds, the LOGO! 0BA8 base module transitions to STOP mode. The message "STOP" appears in the LOGO! display status line.
4. All digital and analog outputs drop to their fail-safe state: relay outputs de-energize, transistor outputs go low. The base module continues to communicate on the side bus (so the CMK2000 still has power) but no longer executes the user program.
5. The CMK2000 is unreachable over Ethernet. Its Web server is offline. The integrated Ethernet port on the base module also stops passing application traffic because the program is no longer running.
6. Power cycling the LOGO! 0BA8 — or pressing the ESC + OK restart combination on the device — clears the condition temporarily. The program restarts in RUN, the CMK2000 RUN LED returns to green, and the network is restored.
7. After a further multi-day interval — typically within a few days of the first occurrence — the loop returns. The cycle continues until the affected module is replaced or the network topology is changed.

2.1 LED Pattern at the Moment of Failure

The fault is non-deterministic in its first appearance (consistently days, not hours and not weeks) but deterministic in its recurrence: once a stack has entered the red RUN state once, the loop continues at the same multi-day cadence until hardware is replaced or the network topology is changed.

3. Affected Hardware and Firmware

3.1 Hardware Article Numbers

The CMK2000 and CMR2020 share the same mechanical housing and side-bus interface; the distinction is the integrated cellular modem on the CMR variant. Both have been observed to trigger the red RUN state on a networked LOGO! 0BA8 base module running firmware later than V1.08.01.

3.2 Firmware Branches

3.3 Verification of the Firmware Branch

To read the firmware version on a running LOGO! 0BA8:

1. On the LOGO! display, navigate to Setup → Module FW (or Setup → FW-Version depending on the device language).
2. The base module firmware is reported as Vxx.yy.zz (for example, V1.08.04).
3. If the reported version is greater than V1.08.01, the affected firmware branch is in use.

Alternatively, connect the LOGO! Soft Comfort engineering tool, go online, and read the firmware version from the Online → Module Information dialog. The version is also printed on the bottom-side rating plate of the base module alongside the article number.

4. Root Cause Analysis

The failure is concentrated in installations where the LOGO! 0BA8 is in active Ethernet communication through the CMK2000. Three conditions must coincide:

4.1 Pre-conditions

1. LOGO! 0BA8 base module firmware > V1.08.01. Earlier firmware branches process the side-bus state machine with a wider timing budget. The post-V1.08.01 firmware tightened the side-bus handshake timing for PROFINET conformance; the tightening is incompatible with the heartbeat timing of the CMK2000 firmware.
2. CMK2000 attached to the side bus and exchanging frames on its Ethernet interface (network discovery, Web server queries, S7 put/get, Modbus TCP polling, or cloud/MQTT heartbeat).
3. Multi-day runtime window. The fault is not immediate. It appears after a deterministic period of multiple days, tied to internal timers in the CMK2000 firmware that are not reset by the LOGO! 0BA8 base module.

4.2 Fault Sequence

When the CMK2000 enters its internal fault state, it asserts the side bus toward the base module. The base module interprets this as a fatal bus error and forces a STOP transition, latching the user program in STOP until the next power cycle. The CMK2000 itself does not recover on its own; it remains in the red RUN state, and a power cycle of the CMK2000 alone is not sufficient to clear the latch on the base module side.

4.3 Why the Standalone Configuration is Not Affected

If the LOGO! 0BA8 is not networked (no Ethernet peer polling, no HMI traffic, no cloud/MQTT heartbeat), the CMK2000 watchdog does not expire in the same way and the side-bus handshake remains within the tolerance of the base module firmware. The same firmware branch on the base module can therefore run indefinitely in a standalone configuration but fails within days when the CMK2000 is in active traffic with the LAN.

5. Diagnostic Procedure

Before assuming the CMK2000 / 0BA8 firmware interaction is the root cause, eliminate other failure modes first.

5.1 Step 1 — Capture the LED Pattern

Document the LED pattern on the CMK2000 at the moment of failure. A solid red RUN LED is the diagnostic signature. A blinking green RUN LED at the moment of failure would indicate a different cause (firmware update in progress, boot sequence). Take a photograph with timestamp for the support case.

5.2 Step 2 — Read the LOGO! 0BA8 Event Log

1. On the LOGO! display, navigate to Setup → Log.
2. The most recent entries show the cause of the last STOP transition. Look for a side-bus-related entry (the exact text varies by language; in English it appears as a side-bus fault entry, in German as a Busfehler or side-bus error entry).
3. If the entry indicates a side-bus fault, the CMK2000 / 0BA8 interaction is implicated.

5.3 Step 3 — Confirm the Firmware Branch

Read the base module firmware version using the procedure in Section 3.3. Confirm that the firmware is in the post-V1.08.01 branch.

5.4 Step 4 — Disconnect the LAN Cable

With the LOGO! 0BA8 in RUN and the CMK2000 RUN LED green, pull the LAN cable from the CMK2000 Ethernet port. Let the system run for at least 7 days. If the red RUN state does not appear during the burn-in window, the network traffic through the CMK2000 is the trigger.

5.5 Step 5 — Disconnect the HMI

With the LAN cable reconnected, disconnect the HMI cable from the LOGO! 0BA8 integrated Ethernet port. Let the system run for at least 7 days. If the red RUN state does not appear, the HMI polling traffic is the trigger.

5.6 Step 6 — Capture a Side-Bus Trace (Advanced)

If a LOGO! Soft Comfort diagnostic session is available, attach the engineering tool to the integrated Ethernet port of the LOGO! 0BA8 and capture the side-bus diagnostic view. The tool exposes the side-bus error counters and the last error timestamp. Export the diagnostic buffer to a CSV file for the support case.

5.7 Step 7 — Swap the CMK2000

Replace the CMK2000 with a known-good spare. If the loop persists with the new CMK2000, the base module is the failing party. If the loop does not return, the original CMK2000 is the failing party.

5.8 Step 8 — Open a Support Request

If the diagnostic steps confirm the symptom and the firmware is in the affected branch, open a support request on the Siemens Industry Online Support portal referencing entry ID 109481657: LOGO! CMK2000 — Siemens Industry Online Support. Attach the LED photograph, the event-log excerpt, the firmware version read-out, and the diagnostic CSV.

6. Workarounds and Mitigations

Because the LOGO! 0BA8 base module firmware is factory-locked, the remediation options are limited to physical-layer changes or hardware replacement. Select the mitigation that matches your risk profile, network topology, and spare-parts availability.

6.1 Mitigation A — Network Segmentation via VLAN

If the LOGO! 0BA8 communicates with the CMK2000 only for outbound connectivity (cloud, remote access, e-mail alerting), place the CMK2000 on a physically separate network segment that does not carry LOGO!-to-LOGO! or LOGO!-to-HMI traffic.

Implementation steps:

1. Configure a managed Ethernet switch (for example, SCALANCE XC-116 or XB-008) with two VLANs: VLAN 10 for the industrial network (LOGO!, HMI, SCADA) and VLAN 20 for the cloud/remote network.
2. Connect the LOGO! 0BA8 integrated Ethernet port to VLAN 10.
3. Connect the CMK2000 to VLAN 20.
4. Disable inter-VLAN routing between VLAN 10 and VLAN 20, or restrict it with an access control list.
5. The CMK2000 retains its role as the cloud gateway for the LOGO!, but the LOGO! 0BA8 side-bus sees a CMK2000 that is not exchanging frames with the LOGO! 0BA8 network in the same broadcast domain.

This mitigation does not address the underlying firmware interaction, but it removes the trigger and allows the system to run indefinitely. The trade-off is that the LOGO! 0BA8 can no longer reach the cloud directly through the CMK2000 in the same broadcast domain. For cloud telemetry, use the CMK2000 as a one-way uplink — the LOGO! writes a process tag to the CMK2000 using S7 put/get, and the CMK2000 reads the tag and forwards it to the cloud via MQTT or HTTP. A sample S7 put/get mapping in the LOGO! program is:

// LOGO! 0BA8: expose VM0 (process tag) to the CMK2000 via S7 put/get
// Network input: enable Network IN/OUT on the LOGO! 0BA8 (Setup → Network IN/OUT → ON)
// VM0 is mapped to the first data word of the S7 put/get area
// CMK2000 polls VM0 over S7 put/get at a 5-second cadence
// CMK2000 forwards the value to the cloud via its MQTT client

The VLAN segmentation is the lowest-risk mitigation because it requires no firmware change and no hardware replacement. It is the recommended first-line response for affected installations.

6.2 Mitigation B — Replace the Base Module

Source a LOGO! 0BA8 base module with firmware at or before V1.08.01 from your spare-parts inventory or from your distributor. Inspect the bottom-side label of the module; the firmware version is printed on the rating plate alongside the article number. Swap the base module, restore the LOGO! program from the SD card or from the LOGO! Soft Comfort project file, and validate the network connectivity with the CMK2000.

This mitigation is the most direct fix for installations where the LOGO! 0BA8 must remain in the same broadcast domain as the CMK2000 (for example, when the CMK2000 acts as a transparent bridge for HMI traffic that is not on the integrated Ethernet port).

6.3 Mitigation C — Replace the CMK2000 With a CMR2020 or Newer Variant

In some installations, swapping the CMK2000 for a CMR2020 (cellular variant) routes traffic through a different code path on the LOGO! 0BA8 side. Validate the new combination in a controlled test bench before deploying fleet-wide. The CMR2020 introduces a cellular radio — verify regulatory compliance, antenna placement, and SIM provisioning before deployment.

6.4 Mitigation D — Hardware Replacement Under Warranty

If the affected module is within the warranty window, return it to Siemens via the standard RMA process. Reference the Siemens support entry ID 109481657 at Siemens Industry Online Support to ensure the fault is documented against the known issue. Include the LOGO! 0BA8 event log, the CMK2000 LED photograph, and the firmware version read-out in the RMA documentation.

7. Preventive Measures for New Installations

For new installations, apply the following baseline:

• Verify the firmware revision against the Siemens Industry Online Support firmware index before commissioning. The current index is maintained at the Siemens Industry Online Support portal. Document the validated firmware pair in the project documentation.
• Keep the LOGO! 0BA8 and CMK2000 firmware in matched, validated pairs. Document the validated pair in the project documentation and the FAT/SAT report. Do not mix firmware branches across the stack.
• For networked LOGO! installations, enable a managed switch with port-down alarms on the CMK2000 port so a faulted CMK2000 is detected before the LOGO! 0BA8 drops to STOP. The SCALANCE switch family supports this via PROFINET diagnostics or SNMP traps.
• Log every STOP transition to a remote syslog server if the CMK2000 supports it. The CMK2000 Web interface exposes syslog forwarding under System → Logging. The syslog stream should be polled for STOP events and alarmed in the SCADA.
• Establish a 7- to 30-day burn-in window for new networked LOGO! installations. Run the system continuously, with normal network traffic, and verify that the CMK2000 RUN LED remains green throughout. If the loop appears during the burn-in, apply Mitigation A or B before the SAT.
• Avoid mixing post-V1.08.01 base module firmware with a CMK2000 in the same broadcast domain as the LOGO! 0BA8 until Siemens publishes a corrected firmware or a documented workaround.

8. Verification Procedure

After applying a mitigation, validate with the following acceptance test:

1. Power the LOGO! 0BA8 + CMK2000 combination with the mitigation in place.
2. Force the program to RUN and let it run continuously for at least 7 days (168 hours) with normal network traffic. If the original fault was associated with a longer cycle, extend the burn-in to 30 days.
3. Periodically poll the CMK2000 RUN LED status (e.g., every 4 hours, automated via the Web server status page or a script that reads the syslog stream). It must remain green throughout the burn-in window.
4. Read the LOGO! 0BA8 event log at the end of the burn-in window. No side-bus fault entries should be recorded.
5. Perform 10 cold restarts (power cycle) of the LOGO! 0BA8 with the CMK2000 attached and the network connected. Each restart must come up clean and reach RUN within the normal boot time of the combined stack.
6. Capture the system event timeline in a commissioning report. The report should include the firmware versions of the base module and the CMK2000, the network topology (with VLAN IDs and switch port assignments), the LED pattern, the event log excerpts, and the syslog stream excerpt.

8.1 Acceptance Criteria

9. Frequently Asked Questions