LOGO! 8 Network Inputs vs Merker Flags: VM Memory and S7 Mapping

Overview

The Siemens LOGO! 8.2 logic module is a compact controller that integrates an HMI, PLC, and Ethernet interface in a single device. When a SCADA, HMI, or IIoT client needs to read or write process data, the LOGO! exposes its internal Variable Memory (VM) as a single S7 data block, DB1. Within that data block, three functional memory regions carry fixed offsets: digital Merker (M) flags, digital Network Inputs (NI) and analog Network Inputs (NAI), and their output counterparts, NQ and NAQ.

The address ranges are the only stable contract between LOGO! and any S7-compatible client, including the third-party node-red-contrib-s7 palette. Choosing the correct region for a given bit is therefore an architectural decision, not a cosmetic one. A light driven by a Network Input is commanded by the external system; a light driven by a Merker is decided locally inside the LOGO! program and merely observed by the external system.

This reference describes the VM layout, the DB1 mapping, the functional difference between Network Inputs and Merker flags, and the configuration steps required to read and write both regions from Node-RED. All examples assume LOGO! 8 (0BA8 Standard and 0BA8.S) firmware FS04 or later; consult the official LOGO! 8 System Manual (Siemens support entry ID 109751159) for the exact version history.

LOGO! 8 Variable Memory Architecture

The LOGO! 8 base module provides 850 bytes of variable memory organized into several functional groups. The groups relevant to external S7 clients are:

• Merker flags (M): bit-addressed working bits used inside the LOGO! program.
• Network Inputs (NI): bit-addressed inputs that the LOGO! reads from external clients.
• Network Analog Inputs (NAI): word-addressed (16-bit) analog inputs supplied by external clients.
• Network Outputs (NQ): bit-addressed outputs that the LOGO! writes for external clients to read.
• Network Analog Outputs (NAQ): word-addressed (16-bit) analog outputs published by LOGO!.

None of these regions overlap. Every byte and bit has a single fixed meaning and a single fixed DB1 offset, which is why an S7 client can address them deterministically with no additional configuration on the LOGO! side. The mapping is built into the LOGO! firmware itself and is documented in the LOGO! 8 System Manual under the topic "Variable Memory (VM) Address Areas".

Network Inputs (NI, NAI) and Network Outputs (NQ, NAQ)

Network Inputs are not physical I/O points and they are not driven by the LOGO! program. They are mailbox locations: an external client writes a value, and the LOGO! program reads that value. The LOGO! function block diagram uses a Network Input block (NI block) just like a digital input block, but the source is the VM, not the terminal strip.

There are two sub-types:

• Digital Network Inputs (NI): single-bit locations, 8 per byte, accessed by the LOGO! program as a regular digital input.
• Analog Network Inputs (NAI): 16-bit word locations, accessed by the LOGO! program as an analog value (0–1000 representing 0–10 V by default, scaled by the analog gain block when applicable).

Network Outputs are the mirror image. They are written by the LOGO! program and read by the external client. They are useful for publishing intermediate results, status flags, and analog measurements to a SCADA without using physical output terminals.

Merker (M) Flags

Merker flags — also called markers or simply flags — are the LOGO!'s internal working memory. They are bit-addressed and exist primarily to:

• Hold the result of a logic operation between scan cycles.
• Bridge a function block output to a function block input when no physical I/O exists.
• Provide a retention bit that survives power-down when declared as a "retain" flag.

From the LOGO! program perspective, an M flag is a coil. From the external S7 client perspective, the M flag is a location in DB1 that can be read freely and written only if no LOGO! program coil currently drives it. If the LOGO! program writes to M1 every cycle, an external write to the same bit is overwritten on the next cycle. This is the single most common cause of "writes that don't stick" reported on LOGO! integrations.

S7-Compatible DB1 Address Mapping

Every byte of VM is mapped to DB1 of an S7 PUT/GET, ISO-on-TCP, or TCP transport. The mapping uses byte offsets, and the specific examples confirmed in field deployments are:

The address range and the count of available NI / NAI / NQ / NAQ objects depend on the LOGO! 8 firmware version. For FS04 and later, the LOGO! 8 System Manual lists 8 digital Network Inputs (NI1–NI8) at DBX1246.0–DBX1246.7, with the remaining NI objects filling consecutive bits in the same byte. Network Analog Inputs start at DBW1262 and increment in two-byte steps. Always confirm the exact count against the System Manual for the firmware version loaded on the target device.

Access functions are limited to:

• Bit access: DB1, DBX<offset>.<bit> — e.g. DB1, DBX1104.0 for M1.
• Byte access: DB1, DBB<offset> — e.g. DB1, DBB1104 for MB0 (M1–M8).
• Word access: DB1, DBW<offset> — e.g. DB1, DBW1262 for NAI1.

DWord (32-bit) access is not part of the standard mapping; read two consecutive DBWs and combine in the client application if a 32-bit value is required.

Functional Comparison: Network Input vs Merker

The single sentence the field experience yields — "Network inputs are network inputs and flags are flags" — captures the architectural separation. If a value enters the LOGO! from outside, it belongs in a Network Input. If a value lives entirely inside the LOGO! program, it belongs in a Merker.

Configuring node-red-contrib-s7 for the LOGO! 8

The node-red-contrib-s7 palette uses the S7comm protocol. For the LOGO! 8, configure each S7 endpoint node with the following parameters:

Address strings for the S7 input/output nodes follow the S7 palette syntax: DB1,X1104.0 for M1, DB1,X1246.0 for NI1, and DB1,INT1262 for NAI1 (the INT keyword selects a 16-bit signed integer read from DBW1262). For 32-bit floats, read DBW1262 and DBW1264 as two INT values and combine them in a function node, or read DBW1262 as a 16-bit value and rescale in the client.

Example minimal Node-RED flow:

1. Add an s7 endpoint node configured for the LOGO! IP, port 102, rack 0, slot 1.
2. Add an s7 in node with the address DB1,X1246.0 and a cycle of 500 ms; connect its output to a debug node to verify the Network Input transitions.
3. Add an s7 out node with the address DB1,X1104.0 triggered by an inject node to set M1. Observe in LOGO!Soft Comfort Online that M1 toggles only when the LOGO! program is not driving it.

Lights vs Rollers: Engineering Rationale

The example from the source project — lights wired to Network Inputs, rollers wired to Merker flags — is a valid and common pattern. The decision is driven by who owns the command:

• Lights (Network Input NI1 at DB1,X1246.0): The light state is decided remotely, typically by a building management system, a presence sensor aggregator, or a Node-RED flow that interprets a higher-level rule. The LOGO! program reads NI1 and drives a physical output. The LOGO! is a remote-controlled actuator for the lights.
• Rollers (Merker M1 at DB1,X1104.0): The roller logic is decided entirely inside the LOGO! program — local push buttons, interlock conditions, end-of-travel feedback. The Merker is the internal decision bit. Node-RED reads it to observe the roller state; it does not control it.

This split is clean and matches the safety philosophy. Anything safety-relevant (a roller door, an emergency stop, a guard interlock) must never be controlled by an external client via a Network Input. The local program must own the decision, and any external supervision is read-only via the Merker (or via a Network Output NQ if the LOGO! program publishes the state explicitly).

If the designer had used a Merker for the lights and a Network Input for the rollers, the consequences would be:

• The light Merker would be overwritten every scan by the LOGO! logic, ignoring the remote command.
• The roller Network Input would allow the SCADA to drive the roller directly, defeating the local interlock and the safety case.

Both are anti-patterns. The original choice — Network Input for remote-controlled bits, Merker for locally-controlled bits — is the correct default.

Diagnostic and Verification with LOGO!Soft Comfort

To verify the live state of a Network Input or a Merker from a PC, use the LOGO!Soft Comfort Online view:

1. Connect LOGO!Soft Comfort to the LOGO! over Ethernet (Tools → Connect → Ethernet TCP/IP).
2. Open the program in online view; the function block diagram will show live values on every block, including NI blocks and M coils.
3. Use Tools → Parameter VM Mapping to display the complete VM byte table with the running values for the byte range of interest.
4. Trigger the external write from Node-RED and observe the corresponding NI or M location transitioning.

For an external client that needs a positive verification, prefer writing a Network Input and reading a Network Output that echoes the value. This is the LOGO! equivalent of a write-then-read protocol and proves end-to-end reachability of the client-to-controller path. If the echo does not appear within one scan cycle, the connection is dropping frames and the cycle time in Node-RED should be increased.

If writes appear to have no effect, check in this order:

1. Confirm the LOGO! program does not have a coil driving the same Merker bit (open the program in LOGO!Soft Comfort and search for the M address).
2. Confirm the address string in Node-RED uses the correct DB1 offset (1104 for M-bits, 1246 for NI-bits, 1262 for NAI-words).
3. Confirm only one S7 endpoint is open against the LOGO! at any given time.
4. Confirm the LOGO! Ethernet access protection is not blocking the connection. The setting is at Parameters → Ethernet → Access Control and is documented in the LOGO! 8 System Manual under "Access Protection".
5. Confirm the LOGO! clock is not in stop mode (LOGO! display reads "STOP"); all DB1 writes from external clients are ignored when the program is halted.

Version Notes and Compatibility

The DB1 mapping has been stable across LOGO! 8 (0BA8) firmware revisions. The following notes apply:

• LOGO! 8 FS01–FS03: NI/NAI/NQ/NAQ region count is smaller. The exact start addresses are unchanged but the upper bound of each region differs.
• LOGO! 8 FS04 and later: full NI/NAI/NQ/NAQ object count. The addresses 1104 (M), 1246 (NI), 1262 (NAI) are stable and documented in the System Manual.
• LOGO! 8.3 (0BA9) with Web Editor and expanded VM: same DB1 mapping; additional VM bytes are exposed beyond byte 1400 and are documented in the 0BA9 System Manual supplement.

For the 0BA8 base module, the LOGO! 8 System Manual (Siemens support entry ID 109751159) is the canonical reference. For 0BA8.S, the additional S-function memory is documented in the LOGO! CMK2000 / CMK4000 communication module manuals. Always cross-check the VM byte table for the exact firmware version before commissioning.

Frequently Asked Questions