LOGO! 8.3 Communication: S7 Connections vs NI/NQ Network Blocks

LOGO! 8.3 Communication Architecture Overview

The Siemens LOGO! 8.3 (order group 6ED1052-1xx08-0BAx) is a logic module with a built-in Ethernet interface that supports two distinct mechanisms for exchanging data with peer devices on the LAN:

• NI/NQ network blocks – a peer-to-peer data exchange implemented as a dedicated instruction pair inside the LOGO! Soft Comfort program. Each NI pulls a value from a partner LOGO!, each NQ publishes a value to a partner LOGO!.
• S7 connections – a passive/active ISO-on-TCP transport (port 102, RFC 1006) that exposes LOGO! tags at S7 addresses so any S7-compatible client (another LOGO!, an S7-1200/1500 CPU, an HMI, a SCADA) can read and write them.

Both mechanisms travel over the same physical Ethernet port and coexist in the same connection table. They are not mutually exclusive — a single LOGO! 8.3 can run up to 8 S7 connections and up to 16 NI/NQ network connections in parallel. The question is not which one is “better” in absolute terms; it is which one fits the data-flow pattern of the application.

NI/NQ Network Block Linking: Peer-to-Peer Data Exchange

NI (Network Input) and NQ (Network Output) are function blocks that you place in the LOGO! Soft Comfort FBD/LAD program. They are configured in the Network Block Properties dialog by entering the partner IP address and the connection slot. The values they carry can be Boolean, analog (word), or double-word depending on which block type is selected.

Internally, LOGO! Soft Comfort generates a cyclic UDP message on the LAN. The default update time is 100 ms for digital values and 200 ms for analog values. The exact timing is set in the connection properties.

Key Characteristics of NI/NQ

• Direction-aware — the master LOGO! must place an NI to read from a slave; the slave must place a matching NQ to publish. Without the NQ on the slave side, the NI on the master will not resolve.
• Drag-and-drop configuration — in LOGO! Soft Comfort, you can drag from an NI pin onto a target block in a partner project, and the connection is auto-generated. This is the workflow shown in the typical LOGO!-to-LOGO setup screenshot.
• Local to LOGO! — only LOGO! devices understand the NI/NQ payload. A S7-1200, an HMI, or a SCADA cannot subscribe to a LOGO! NI/NQ stream.
• No address mapping required — the user does not deal with TSAP, DB numbers, or byte offsets. The block I/O pins are the address.

Limits and Versions

S7 Connection Communication: Protocol-Level Integration

An S7 connection is configured in the Ethernet Connections list of LOGO! Soft Comfort. It is not a function block you place in the program — it is a transport session that exposes the LOGO! tag space at S7-compatible addresses. A partner device then reads/writes those addresses using S7 PUT/GET or S7 read/write services.

Connection Establishment

Each S7 connection entry contains:

• Local TSAP — transport service access point on the local LOGO! (two bytes, e.g. 02.00).
• Remote TSAP — the TSAP the partner expects (e.g. 01.01 for a partner on slot 1 of an S7-1200).
• Partner IP address — the IPv4 address of the active side.
• Active/Passive — the active LOGO! initiates the TCP handshake; the passive side listens on port 102. Only one side may be active.

The TSAP is the single most common misconfiguration point. The local TSAP on device A must equal the remote TSAP configured on device B, and vice versa. The byte pairs encode connection resource.byte; the LOGO! default is 02.00, but any two-byte combination is allowed as long as it is unique within the device.

S7 Address Mapping on LOGO! 8.3

LOGO! 8.3 exposes its variables at the following S7 address locations — the values can be read by any S7 client without the LOGO! program needing to be modified:

Technical Comparison: S7 vs NI/NQ

The two mechanisms are not redundant — they solve different problems. The table below summarizes the engineering trade-offs.

Prerequisites: Hardware, Firmware, and Software Stack

Before configuring the master/slave web server scenario (4× LOGO! 8.3, one acting as web server), verify the following:

1. Hardware — 4× LOGO! 8.3 base modules with Ethernet (e.g. 6ED1052-1MD08-0BA0) plus 4× LOGO! POWER 24 V supplies and a managed Ethernet switch.
2. Firmware — all four modules at the same firmware level (FS3 or later, e.g. V1.08.x). Mixing FS2 and FS3 in a peer-to-peer network is not supported.
3. Software — LOGO! Soft Comfort 8.3 (build 8.3.0 or later) for program development, and LOGO! Web Editor (LWE) for the custom web pages.
4. IP plan — assign static IPs in the same /24 subnet. Example: master 192.168.0.10, slaves 192.168.0.11…192.168.0.13. Disable DHCP on the LOGO! base modules to avoid address drift.
5. IP routing — confirm that the four LOGO! devices are on the same broadcast domain. Cross-subnet routing requires L3 switches and additional firewall rules.

Configuring NI/NQ for Master/Slave Web Server Projects

The recommended approach for a homogeneous 4× LOGO! 8.3 cluster is to keep all inter-device traffic on the NI/NQ channel. The configuration steps are:

1. On each slave LOGO! — in LOGO! Soft Comfort, open the slave program. Place an NQ block (Network Output) on every output you want to expose to the master. In the NQ block properties, set the Connection field to a unique connection ID (e.g. 1 for Q1, 2 for Q2, etc.). The connection target IP must be the master’s IP (192.168.0.10).
2. On the master LOGO! — in the master program, place a matching NI block (Network Input) for each slave output. The connection ID on the master NI must match the slave NQ ID exactly, and the source IP must be the slave’s IP.
3. Linking NI outputs to web-server variables — connect the NI output pins to a LOGO! flag (M) or directly to the LWE variable list. The flag is then displayed in the web page.

A minimal master program fragment for exposing two slave outputs is shown below in FBD pseudo-code:

+-----------+        +--------+        +----------+
| NI from   |        | Flag   |        | Web      |
| 192.168.  |------>| M10    |------>| Variable |
| 0.11 / Q1 |        |        |        | "Slave1Q1"|
+-----------+        +--------+        +----------+

+-----------+        +--------+        +----------+
| NI from   |        | Flag   |        | Web      |
| 192.168.  |------>| M11    |------>| Variable |
| 0.12 / Q1 |        |        |        | "Slave2Q1"|
+-----------+        +--------+        +----------+

The flag buffer (M10, M11) provides a stable reference for the LWE variable list and survives any program reorganization on the master. It also lets you add local logic between the remote state and the web display (e.g. invert, debounce, or aggregate multiple sources).

Configuring S7 Connections with TSAP Parameters

S7 connections are the right tool when the partner is a SIMATIC S7 CPU or an HMI/SCADA that needs direct access to LOGO! tags. Configure them as follows:

1. Open the Ethernet Connections list in the master LOGO! Soft Comfort project.
2. Add a new S7 connection: enter a free local TSAP (e.g. 02.00), the slave IP as partner, the slave’s local TSAP as remote TSAP (also 02.00 for LOGO!-to-LOGO), and mark the master as Active and the slave as Passive in their respective connection tables.
3. Download to both devices and verify the connection status under Diagnostics > Ethernet Connections on the master web interface.
4. Read/write from a third party: from a TIA Portal project on an S7-1200/1500, use a PUT/GET instruction block (FB14/FB15 legacy, or the distributed I/O “LOGO!” CP option) targeting the master LOGO!’s IP. PUT/GET access on the S7-1200/1500 must be enabled in the CPU properties under Connection mechanisms > Permit access with PUT/GET communication.

Exposing Real Output State in LOGO! Web Editor (LWE)

The user’s specific need — displaying the actual output state, not the input trigger — is solved by reflecting the output bit back into a tag the web server can read. Two reliable patterns are:

Pattern A: NI Read of Slave Output

1. Configure NQ on the slave (publish Q1).
2. Configure NI on the master (read Q1 from slave).
3. Map NI to flag M10.
4. In LWE, create a status indicator bound to VM0 or M10.

Pattern B: Local Feedback in the Master

If the trigger source is a digital input on the master, the master can mirror its own output coil back to a flag using a self-holding circuit. The flag, not the input, is then bound to the web page. This avoids the round-trip latency of NI/NQ for fast toggles.

LWE Variable Binding

Inside LOGO! Web Editor, each visual element (text, indicator, button) is bound to one LOGO! operand. The supported operand types are:

• Inputs: I1…I24
• Outputs: Q1…Q20
• Flags: M1…M64
• Variable memory: VW0…VW848
• Network inputs: NI1…NI64

Binding a web element directly to an NI pin is supported; the value will reflect whatever the partner is currently publishing. For most operator panels, however, the flag-buffered pattern is preferred because it allows debounce and inversion logic to be inserted in the master program.

Decision Matrix: Which Method to Use and When

Best Practices for Multi-LOGO Web Server Projects

1. Keep NI/NQ for LOGO!-to-LOGO. Resist the temptation to use S7 connections between LOGO! devices — it adds TSAP bookkeeping for no functional benefit.
2. Always publish on the slave, subscribe on the master. The slave owns the output; only the slave should expose it. Centralizing subscriptions on the master reduces configuration churn when slaves are added.
3. Use a flag buffer on the master. Never bind the web UI directly to NI pins if you anticipate adding local logic (debounce, inversion, alarms). The flag is a stable hand-off point.
4. Document TSAPs in the connection table. Maintain a project spreadsheet that lists every S7 connection: local TSAP, remote TSAP, active/passive role, partner IP, last verified date.
5. Lock the LWE version. When deploying a web page, export the LWE project as part of the version-controlled project bundle. LWE revisions can change variable binding paths and break a deployed page silently.
6. Set explicit update times. In NI/NQ properties, do not leave the default 100/200 ms if the panel has a faster refresh requirement — LOGO! 8.3 supports tightening to 50 ms for digital signals at the cost of network traffic.
7. Use a managed switch with IGMP snooping disabled for NI/NQ networks. LOGO! NI/NQ uses multicast-style discovery; aggressive IGMP pruning can drop packets.
8. Segment the LOGO! network from the office LAN. Even though both protocols are unauthenticated, isolating the logic network reduces accidental misconfiguration risk.

Troubleshooting Communication Faults

Frequently Asked Questions