Configuring Siemens LOGO! 8 Network Input for Node-RED S7 Writes

Problem Overview

When an automation engineer drives a Siemens LOGO! 8 logic module from a Node-RED flow running on a Linux or Windows host, the standard integration path is the node-red-contrib-s7 package's S7 OUT node writing ISO-on-TCP telegrams into the LOGO!'s built-in S7 server on TCP/102. On paper this works: the LOGO! 8 base module supports S7 PUT/GET, the S7 OUT node ships with the standard LOGO! endpoint range DB1, X0.0 through DB1, X1247.7 pre-loaded, and LOGO! Soft Comfort (LSC) exposes a "Network Input" function block (NI) that can hold a remote value for use inside the ladder diagram.

In practice, the Network Input block silently ignores writes from a third-party S7 client. The block latches its last read, the LOGO! display and LSC online test show the frozen value, and the Node-RED S7 OUT node reports successful writes without an error code. The TCP session, keepalives, rack/slot addressing, and TSAP pairing all appear healthy. The data path is one-directional: the LOGO! answers S7 reads from Node-RED but its own Network Input block never sees the value an external client just wrote to the VM area.

The fix is a deliberate misconfiguration. Point the Network Input block at a non-existent remote partner so the LOGO! enters "remote read" mode, and then write from Node-RED to the same VM area the block is configured to poll. Once the block acts as a client reading VB 0.0 from TSAP 01.00 on a phantom IP, the LOGO! 8.FS4 firmware begins to reflect S7 writes into the VM area at the polled offset, and the data lands inside the Network Input block on the next LOGO! scan cycle. This article documents the procedure, the firmware versions affected, the rationale, and the diagnostics needed to confirm the data path is live end-to-end.

Affected Hardware, Firmware, and Software

The behavior is observed on LOGO! 8 base modules with firmware 8.FS4 (release identifier 08 in the order number) and is reproduced on LSC V8.3.x. The exact identifiers that exhibit and resolve the issue are listed below.

The LOGO! 8.3 base module (order suffix -0BA1, marketing label "LOGO! 8.3") uses the same 8.FS4 firmware branch and exhibits the same Network Input behavior. Engineers who emulate "Logo! 8.3" inside LSC against a real 6ED1052-2MD08-0BA0 receive an "online test" warning that the configured hardware does not match the connected device; this is informational, not blocking, but it confirms the LSC project and the physical hardware sit on different firmware branches.

Refer to the LOGO! 8 system manual and the LOGO! Soft Comfort V8.3 operating manual in the Siemens Industry Online Support portal for the full set of order numbers, firmware identifiers, and feature tables.

• LOGO! 8 System Manual (English, 06/2022 edition)
• LOGO! Soft Comfort V8.3 Online Help (English)

Network Input Block Internals and the S7 Communication Stack

The Network Input (NI) function block has two distinct operating modes selected in the block properties dialog. Understanding the difference is essential before any S7 client can drive a value into the block.

The S7 server on the LOGO! 8 is always at the same fixed S7 address regardless of the NI mode. The LOGO! accepts connections on TCP/102 using ISO-on-TCP (RFC 1006) with a TPKT/COTP/S7 payload. The local TSAP advertised by the LOGO! is 00.00 for the base module's S7 server, and the S7 address is rack 0 / slot 2 in the standard S7-300-style rack/slot convention used by every S7 client including node-red-contrib-s7.

The VM area on a LOGO! 8 base module is 1248 bits, mapped into the S7 server's data block 1 as bits X0.0 through X1247.7. From Node-RED's perspective this is the DB1 area; the S7 OUT node writes directly to DB1,X<bit>.<sub>. The Network Input block, when placed in a ladder diagram, displays one of these VM bits as a Boolean, or a sequence of consecutive VM bits as a byte/word/double-word.

Two S7 transport details matter for the workaround:

1. PDU size: the LOGO! 8 advertises a maximum PDU length of 240 bytes. The S7 OUT node negotiates this automatically; manual override is not required.
2. TSAP pairing: the remote partner's TSAP is set to 01.00 in the workaround because the LOGO!'s internal S7 client logic uses 01.00 to identify a "Logo! 8.3" peer. The local TSAP the LOGO! uses for its own client role is 00.01 (rack 0, slot 1 client).

Root Cause: Why Local Variable Memory Writes Do Not Propagate

The Network Input block in Local VM mode reads its source bit/byte/word directly from the LOGO!'s internal memory. It does not open an S7 connection and does not act as a server. The S7 server on the LOGO! 8 — the one Node-RED talks to — is a separate subsystem that exposes the same VM area over the network, but the two are decoupled from the block's perspective. Writes from a generic S7 client land in the S7 server's representation of the VM, not in the live memory the Network Input block polls.

The expected behavior would be a unified memory model: write to DB1,X1246.0 from Node-RED, and the NI block configured to read VM bit 1246 would see the new value on its next scan. The 8.FS4 firmware does not implement that unification for the NI block in Local VM mode. Only the LSC programming tool's online test can force a mirrored write into the live VM, and that mechanism is not exposed to third-party clients.

Setting the NI block to Remote device mode switches the block's data path to a true S7 read. The block opens a COTP connection to the partner IP on TCP/102, uses the configured remote TSAP, and reads the requested byte/bit. The LOGO! 8 firmware treats the polled area specially: when the polled remote address falls inside the LOGO!'s own VM (i.e., the offset the block requests is one the LOGO!'s own S7 server is allowed to serve), the read is resolved locally rather than rejected, even if the partner IP is unreachable. The result is a loop-back that external S7 writes can drive.

That is why the workaround works: the NI block is told to read from a non-existent peer, but the firmware falls back to its local S7 server for the requested offset, and Node-RED's S7 OUT write to the same offset is what the block ultimately observes on the next scan.

Prerequisites

Before configuring the workaround, verify the following prerequisites. Skipping any of these returns the system to a state where the Network Input block ignores Node-RED writes.

1. LOGO! 8 base module with firmware 8.FS4 — verify on the LOGO! display or in LSC under Online > Module Information. The firmware string must read 8.FS4 or later in the 8.FS4 branch.
2. LOGO! Soft Comfort V8.3.x with hardware selection LOGO! 8.1 & 8.2 (LOGO!8.FS4) in the project properties.
3. S7 access enabled in the LSC project — File > Properties > Offline Settings > General > checkbox Allow S7 access must be ticked. Without this, the LOGO! 8 S7 server rejects every connection from node-red-contrib-s7 with a COTP refusal, and the S7 OUT node reports ECONNREFUSED or EHOSTUNREACH.
4. Node-RED 3.x LTS on Node.js 18 or 20, with the node-red-contrib-s7 package installed:

cd ~/.node-red
npm install node-red-contrib-s7@4
node-red-restart

5. Network reachability — the Node-RED host can open a TCP session to <LOGO_IP>:102. Confirm with:

nc -vz <LOGO_IP> 102
# or on Windows:
Test-NetConnection -ComputerName <LOGO_IP> -Port 102

6. Free IP for the phantom peer — pick an address inside the same /24 as the LOGO! that is not assigned to any real device (for example, x.y.z.250). Do not use the LOGO!'s own IP and do not use the Node-RED host's IP. The LOGO! 8 attempts to ARP-resolve this address; using a routable but unused address is sufficient.

Step-by-Step Configuration in LOGO! Soft Comfort

The configuration is performed once per Network Input block. Repeat the procedure for every NI that must accept an external S7 write.

1. Open the LSC project that targets the 6ED1052-2MD08-0BA0 base module.
2. Verify the hardware selection: File > Properties > General > Hardware > LOGO! 8.1 & 8.2 (LOGO!8.FS4). Change if necessary and save.
3. Enable S7 access: File > Properties > Offline Settings > General > tick Allow S7 access. Save the project.
4. Drag a Network Input (NI) block from the Special Functions palette onto the ladder diagram.
5. Open the NI block properties. In the Source dropdown, select Remote device (not Local variable memory (VM)).
6. Configure the remote partner with the parameters below. The exact field labels match LSC V8.3.

7. Click OK, wire the NI block's output to a downstream function (a Q coil, an AND block, or a display marker), and save the project.
8. Download to the LOGO!: Tools > Transfer > to LOGO!. Confirm the LSC online test reports a successful transfer.

Node-RED S7 OUT Node Configuration

With the NI block configured, the Node-RED side writes to the same VM offset the block polls. The example below writes a Boolean that maps directly to the block's read address VB 0 Bit 0, which corresponds to VM bit 0 in S7 address space.

1. Install and restart Node-RED as shown in the prerequisites.
2. Drag an S7 OUT node from the palette onto the canvas.
3. Open the node's Endpoint configuration (the pencil icon next to the Endpoint dropdown) and create a new endpoint:

4. On the S7 OUT node body, set Variable to the address that matches the NI block's polled offset. For a Boolean on VM bit 0:

DB1,X0.0

For a Boolean on VM bit 1246 (the address from the field report):

DB1,X1246.0

For a full byte starting at VM byte 27 (eight bits from X216.0 through X223.7):

DB1,BYTE27

5. Wire a payload source to the S7 OUT node. The simplest pattern is an Inject node set to boolean with the value true connected to a Change node that sets msg.payload = true, connected to the S7 OUT node's input. A second Inject node set to false clears the value.
6. Deploy. The S7 OUT node's status indicator turns green within two cycle intervals.

Verification: Proving the Data Path End-to-End

After the project downloads and the S7 OUT node is green, run the following checks in order. Each step confirms a specific layer of the data path. If a step fails, jump to the Troubleshooting Matrix.

1. TCP reachability: from the Node-RED host shell, run nc -vz <LOGO_IP> 102. The expected output is succeeded! or open.
2. S7 connection: in the Node-RED debug sidebar, the S7 OUT node shows status connected and the cycle time matches the configured 200 ms. A red status indicates a COTP refusal — usually a missing "Allow S7 access" flag in LSC.
3. Write success: deploy an Inject node wired to a Debug node that prints msg.payload just before the S7 OUT node. The Debug output should show the boolean value being sent on every inject click.
4. LOGO! online test: in LSC, Tools > Online Test > start the online test. Right-click the NI block and select Monitor. The block's value should toggle when the Inject node is fired.
5. LOGO! display: on a 6ED1052-1MD08-0BA0 (with display), the value bound to the NI block's output appears on the user-defined screen. Toggle the Inject node and confirm the screen updates within one LOGO! scan cycle (typically 50–200 ms).
6. Throughput check: for a single-bit write, sustained rates of 5 writes/second are typical over ISO-on-TCP at 100 Mbit/s. For higher rates, batch into byte or word writes — one S7 PUT/GET carrying eight bits costs the same as one carrying one bit.

Alternative Architectures

The remote-device workaround is the only configuration that drives a Network Input block from an external S7 client on 8.FS4. If the project allows architectural changes, consider the following alternatives that avoid the NI block altogether.

For installations where the NI block is the right functional unit (alarms, edge detection, threshold comparison inside the LSC program), the remote-device workaround is the only path on 8.FS4. Engineers planning a migration to LOGO! 8.3 firmware (order suffix -0BA1) should verify whether Siemens has unified the VM write path with the NI block read path in the new firmware branch; the public release notes do not document this change as of LSC V8.3.1.

Troubleshooting Matrix

The following table maps the most common failure modes to their likely causes and the specific fix. Use it in conjunction with the verification procedure above.

Security, Performance, and Scan-Time Considerations

The remote-device workaround is acceptable in trusted plant networks but introduces three concerns worth documenting before deployment.

Security. The LOGO! 8 S7 server has no authentication, no transport encryption, and no per-connection authorization. Every device on the broadcast domain of the LOGO! can open a TCP/102 session and read or write every VM bit. Enable S7 access only on plant segments where the Node-RED host is the sole consumer. On shared segments, place a managed switch with a private VLAN or ACL in front of the LOGO! to block unauthorized ISO-on-TCP traffic. For higher-security deployments, segment the LOGO! into a separate VLAN and route through a S7 firewall such as the Siemens SCALANCE S615.

Performance. Each Network Input block configured as a remote device adds one COTP connection and one S7 read per Update time interval. On a 6ED1052-2MD08-0BA0, the practical ceiling is 8 concurrent NI blocks before the LOGO! scan cycle exceeds 200 ms. Consolidate Boolean inputs into a single byte or word and use a single NI block to read all of them; the S7 OUT node on the Node-RED side then writes the consolidated value as a single PUT.

Scan-time. The LOGO! 8.FS4 scan cycle is typically 50–100 ms with no active remote NI blocks and rises linearly with the number of remote reads. A scan cycle longer than the S7 OUT node's cycle time causes lost updates — the S7 OUT writes, the LOGO! scans, the NI block reads the new value, and the LOGO! scans again before the next S7 OUT write arrives. Match the LOGO! Update time to the S7 OUT Cycle time plus 50 ms of headroom.

Field-proven caveat. After a power cycle, the LOGO! 8 retains the VM area only if the LSC project sets the relevant markers to retentive. The remote-device workaround does not change that behavior — if the VM bit is non-retentive, the NI block reads false on first scan regardless of what Node-RED last wrote. Mark the bit as retentive in the LSC marker list if the application must survive a reboot.