Detecting Powered-Off Siemens LOGO! 8.FS4 Modules Over Ethernet

A Siemens LOGO! 8.FS4 controller receiving network inputs (NI) from a peer that has been de-energized will hold those NI in their last logical state indefinitely. This reference explains why, and how to build deterministic power-loss detection using life bits, watchdog timers, and diagnostic inputs inside LOGO!Soft Comfort.

1. Problem Definition

A common architecture in small-machine automation uses one Siemens LOGO! 8.FS4 as a supervisory "master" with three or more remote LOGO! 8.FS4 stations reporting digital status via Ethernet. The local master drives a KTP400 HMI from the SIMATIC HMI portfolio that must indicate to the operator whether each remote station is healthy or has been turned off.

The symptom that breaks naive logic is this: as soon as the remote LOGO! 8.FS4 loses 24 VDC, the corresponding NI on the master (which was previously reading the state of a remote NQ output through the LOGO!-to-LOGO! connection) stays at its last value. There is no automatic zero, no transition to FALSE, no timeout flag; the bit simply freezes.

This is documented behavior of the LOGO! 8 network stack: when a TCP connection terminates unexpectedly, the receiver places no forced default on its NI memory. Forcing the master to interpret "last value held" as "remote is alive" produces a dangerous false-positive, especially when the value indicates a healthy state.

2. LOGO! 8.FS4 Network I/O Background

The LOGO! 8.FS4 family (order prefix 6ED1052-...) integrates a 10/100 Mbit/s Ethernet interface supporting S7-compatible communication, Modbus TCP, and LOGO!-to-LOGO! peer messaging. Refer to the Siemens Industry Online Support portal for the LOGO! 8 system manual (entry ID 109741041) and the LOGO! product page at siemens.com/logo.

On each Ethernet connection (up to 8 simultaneous connections per LOGO! 8.FS4), the master's NQ1..NQ8 are written into the peer's NI1..NI8 of the corresponding connection. The physical transport is a TCP keep-alive socket opened by LOGO!Soft Comfort configuration. There is no application-level heartbeat in the default NQ/NI mapping, which is precisely why a power-down on the transmitter produces the frozen-NI symptom.

3. Why Network Inputs Hold Last State

The LOGO! 8 system manual states that on connection loss the receiver treats the NI memory as undefined or frozen at last value rather than forcing it to zero. Three underlying causes combine:

1. No application-level handshake. NQ/NI are mapped bit-for-bit into the periodic update; the receiver cannot distinguish "remote is sending zeros" from "remote is offline."
2. No TCP RST on hardware power-down. When 24 VDC is removed, the LOGO! Ethernet PHY collapses without sending FIN/RST. The master's socket enters a long timeout window during which NI registers stay populated.
3. LOGO! scan semantics. The NI register is treated as a memory location that is overwritten only when fresh data arrives. With no data arriving, the memory location is preserved.

4. Solution Architecture: Three Detection Methods

Three field-proven techniques detect a powered-down remote. Each can be implemented in pure LOGO! ladder or FBD without external hardware.

4.1 Method A - Pulsed Output plus Watchdog Timer

This is the method that resolves the original problem statement. It is the most universally applicable because it works on any LOGO! 8 (and even LOGO! 7 with Ethernet) regardless of firmware micro-version, and requires no special configuration toggle.

1. On each remote LOGO!, configure an unused digital output or a flag-driven NQ that toggles every ~500 ms (a clock-pulse generator, base 1 s, On/Off 0.5 s/0.5 s).
2. Map this toggling NQ into the corresponding NI on the local master.
3. On the local master, route that NI into an On-delay timer with a preset of 2 s.
4. The timer output stays TRUE while the toggle is arriving within 2 s; it goes FALSE the moment the remote stops updating, because the NI stops changing.

Why it works: when the remote loses power, the NI on the master freezes at its last value (either 0 or 1). Either way it stops changing, so the 2-second no-change timer expires and the output goes FALSE, giving you a deterministic "remote OFF" flag.

4.2 Method B - Life Bit

LOGO! 8.FS4 supports a dedicated Life bit per Ethernet connection. In LOGO!Soft Comfort's network configuration dialog, each connection entry exposes a "Life bit" checkbox. When enabled, the LOGO! appends a single toggling bit to the periodic update that the peer can monitor separately from the user NQ/NI bits.

On the local master, the Life bit of connection N is exposed as a special marker flag (labeled Network error / Life bit connection N in the special-marker picker). When the peer is alive, this flag toggles at the configured period (typically 1 s). When the peer drops, the flag freezes, exactly the same latch problem as NQ/NI. The difference is that you have a designated, named flag for the purpose, simplifying documentation.

The Life bit is the Siemens-recommended path when the firmware supports it (LOGO! 8.FS4 onward). It avoids "stealing" one of your 8 NQ bits for heartbeat purposes.

4.3 Method C - Connection Diagnostic Input

LOGO! 8.FS4 exposes a per-connection diagnostic input. In LOGO!Soft Comfort, drag a Network input block onto the diagram; selecting "Diagnostic input" in the dialog returns one bit per configured connection that asserts on link-down and connection-error conditions detected by the LOGO! firmware (TCP timeout, ARP failure).

The diagnostic input is the fastest indicator; it asserts within one TCP keep-alive interval (typically 5-10 s) of the remote going dark. The downside is that it cannot always identify which peer is down if multiple connections share error handling. In practice, dedicating one connection per remote and one diagnostic input per connection gives you the per-peer granularity you need.

5. Network Topology Comparison

For the described installation (one KTP400 HMI plus three remote LOGO! 8.FS4 plus one supervisory master), the cleanest design is master-master with one Ethernet connection per remote, each connection carrying:

• Up to 7 user NQ/NI bits for actual I/O
• 1 dedicated NQ bit reserved as heartbeat (Method A), or
• The Life bit feature enabled (Method B), or
• A diagnostic input added to the NI list (Method C)

6. Implementation: Watchdog Timer with Pulsed Output

6.1 Remote LOGO! Program (FBD excerpt)

1. Insert a Clock generator (German: Taktgeber) block, block number B001.
2. Set Base = 1 s, On time = 0.5 s, Off time = 0.5 s. Output Q toggles every 500 ms.
3. Assign output B001 to Network output NQ1 of the Ethernet connection to the master.

[B001 Clock Generator]   Base=1s  On=0.5s  Off=0.5s
        |
        v
    [NQ1  conn=Master]

6.2 Local Master LOGO! Program

1. Insert a Network input block, address NI1 from remote #1.
2. Insert an On-delay (German: Einschaltverzögerung) timer block B010, preset 2 s.
3. Wire NI1 to B010 input Tr. B010 output Q becomes Remote1_OK.
4. Repeat for remote #2 (NI2 to B011, 2 s preset, Remote2_OK) and remote #3 (NI3 to B012, Remote3_OK).
5. Wire Remote1_OK, Remote2_OK, Remote3_OK to three VM bits that are bound to the KTP400 HMI tags, e.g. VM0.0, VM0.1, VM0.2.

NI1 (Remote#1) ---[B010 On-Delay 2.0s Tr]--- Q -> Remote1_OK
NI2 (Remote#2) ---[B011 On-Delay 2.0s Tr]--- Q -> Remote2_OK
NI3 (Remote#3) ---[B012 On-Delay 2.0s Tr]--- Q -> Remote3_OK

Remote1_OK, Remote2_OK, Remote3_OK  --> VM mapping for HMI

6.3 Why 2 seconds?

The on-delay timer must be longer than the period between two heartbeat edges (1 s for a 50/50 toggle) but short enough that operators perceive the loss promptly. A practical rule:

T_watchdog > 2 * T_period
T_watchdog < 0.1 * T_operator_response_expectation

For a 500 ms heartbeat (1 s period), 2 s gives one full missed cycle plus 1 s of margin. The master LOGO! 8 cycle time is typically 8-20 ms, so timer resolution is not a concern.

7. Implementation: Life Bit and Diagnostic Input Methods

7.1 Enable Life Bit (Method B)

1. In LOGO!Soft Comfort, open Tools > Ethernet Connections.
2. Select the connection to the remote LOGO!.
3. Tick Use life bit. The Life bit toggle period defaults to 1 s and is editable.
4. Click OK. Transfer the program to the master.

The Life bit of connection N is available as a special marker. In the FBD editor, drag a Special marker block and select Network error / Life bit connection N from the drop-down. The flag toggles while the remote is alive and freezes when it drops. Wire it into the same on-delay watchdog as in section 6.

7.2 Add a Diagnostic Input (Method C)

1. In LOGO!Soft Comfort, place a new Network input block on the diagram.
2. In the dialog, tick "Diagnostic input" and choose the connection number.
3. The block output Q asserts when the LOGO! detects a TCP-level error on that connection.
4. OR the diagnostic input with the watchdog output to differentiate "power off" (watchdog drops, diagnostic asserts after keep-alive timeout) from "cable pull" (diagnostic asserts quickly).

8. LOGO!Soft Comfort V8.x Configuration

Always reserve a static IP for each LOGO! via the LOGO! on-board menu (or via DHCP reservation on the switch). Do not rely on DHCP fallback in an industrial cell; an APIPA address on a remote produces silent failure.

9. KTP400 HMI Integration

The KTP400 Basic (part number 6AV2123-2DB03-0AX0) from the SIMATIC HMI family reads the master's VM area. Configure the master's Remote1_OK through Remote3_OK flags into a contiguous VM range and bind each bit to a "station online" indicator on the KTP400 screen.

In WinCC (the configuration software for the KTP400), add an IO field or a graphic IO field per station showing a green/red bar driven by the corresponding VM bit. Refresh cycle can be 1 s; the watchdog already filters faster events.

10. Verification and Commissioning Procedure

1. Power all three remote LOGO! 8.FS4 stations. Confirm Remote1_OK, Remote2_OK, Remote3_OK are all TRUE on the KTP400.
2. De-energize remote #1 (open the 24 VDC breaker). Wait 3 s. Confirm Remote1_OK on the HMI turns FALSE; confirm Remote2_OK and Remote3_OK remain TRUE.
3. Re-energize remote #1. Confirm Remote1_OK returns to TRUE within 3 s (one heartbeat period plus one watchdog timeout).
4. Repeat for remote #2 and remote #3.
5. Pull the Ethernet cable from a remote while it remains powered. Confirm the corresponding OK flag drops within ~10 s (TCP keep-alive window) instead of 3 s; this validates that the diagnostic input (Method C) is also wired correctly, giving you a different alarm message ("link loss") versus "power loss."
6. With all stations healthy, disconnect the master from the HMI and read the VM mapping via LOGO!Soft Comfort online mode. Verify each OK flag is TRUE.
7. Stress test by toggling 24 VDC rapidly (1 s on, 1 s off) for 10 cycles; verify the watchdog reports the outage but does not latch FALSE after recovery.

11. Troubleshooting Matrix

12. Safety and Best-Practice Notes

• Treat any "remote is alive" signal as advisory, not as a safety interlock. LOGO! 8.FS4 is not a fail-safe controller; for SIL-rated applications, use a S7-1200F or S7-1500F with PROFIsafe.
• Use a managed industrial switch (SCALANCE XC-100 or XC-200) with port-level link monitoring so the master can detect cable pulls even when the remote stays powered.
• Document the watchdog timeout on the electrical drawing; operators must know how long a station can be dark before the HMI flags it.
• Reserve one NQ bit per connection for heartbeat. Never overload this bit with real I/O.
• When scaling beyond three remotes, consider an S7-1200 as the supervisory controller; LOGO! 8 tops out at 8 simultaneous Ethernet connections and the FBD program size becomes hard to maintain.
• Prefer Method B (Life bit) over Method A (stolen NQ) when the firmware supports it; it leaves all 8 user NQ bits free for I/O.
• Combine Method A or B with Method C so the operator can distinguish "station power removed" from "network cable disconnected."

FAQ