Configuring Siemens LOGO! 8 Static and Dynamic Connections

1. Overview

Siemens LOGO! 8 (6ED1052-xxx08-0BA1 family, marketed as LOGO! 8.3 in the 0BA8 hardware generation) is a modular logic module that includes an integrated Ethernet port on the base unit. Unlike LOGO! 7 and earlier generations, LOGO! 8 communicates natively over TCP/IP using S7-compatible messaging and Modbus TCP. This same Ethernet port is what allows multiple LOGO! base modules, LOGO! TDE text displays (6ED1055-4MH08-0BA1), and a LOGO! CMR (6BK1700-0HA00-0AA0 / -0HA02-0AA0) communications module to coexist on a single physical switch infrastructure.

Designing a network with several grouped LOGO! clusters, while still needing a path to a central CMR for SMS fault text messaging, is a common requirement in machine-builder, building-services, and small-process applications. The central constraint is not the physical media; it is the per-base-module connection budget. Each LOGO! 8 base module advertises a fixed ceiling on simultaneous S7/Modbus TCP sessions, and the operator must choose how those sessions are split between static and dynamic connection types.

2. LOGO! 8.3 Connection Architecture

Every LOGO! 8 base module operates as both an S7 client and an S7 server on TCP port 102. It simultaneously speaks Modbus TCP server on port 502. A single base module is therefore a small peer-to-peer logic controller that can publish and consume tags with up to a fixed number of remote partners.

The LOGO! 8 System Manual (ID 109741041) documents the supported Ethernet topology. Each base module can maintain up to 16 TCP/IP-based S7/Modbus communication connections with the following partner types:

• Additional LOGO! base modules in S7 connection mode
• LOGO! base modules acting as Modbus TCP server or client
• LOGO! TDE text displays (one connection reserved per paired TDE)
• LOGO! CMR communications module acting as S7 client
• S7 PLCs (S7-200 SMART, S7-1200, S7-1500, ET 200 CPUs)
• HMI panels supporting S7 or Modbus TCP
• Third-party Modbus TCP masters or slaves

The 16-connection budget is shared between all partner types; it is not additive per protocol. A base module configured with one TDE, three S7 peer connections, and one CMR client already consumes five of the sixteen available slots.

3. Maximum Connection Limits and the Static vs Dynamic Split

Within the 16-connection ceiling, the manual defines two connection classes:

The published rule is: n static connections plus (16 - n) dynamic connections, with n capped at 8. In practice this means a base module can be statically bonded to up to eight persistent partners (typical for a tightly-coupled machine cluster), while the remaining eight slots are reserved for opportunistic partners such as a maintenance laptop, an HMI on a different VLAN, or the CMR.

4. Prerequisites

Before commissioning the multi-group network, verify the following items are present and current.

• LOGO! 8 base modules with firmware 8.0 or higher; for CMR text-message support and for the 16/8 split, firmware 8.1.5 or later is recommended. The latest 0BA8 firmware is 8.3.
• LOGO! Soft Comfort V8.3 (or later) for project authoring, available from the Siemens Industry Online Support portal as a free download.
• LOGO! TDE (6ED1055-4MH08-0BA1) for any local operator panel requirement. Each TDE requires one static connection on the base module it pairs with.
• LOGO! CMR2020 (6BK1700-0HA02-0AA0) for 4G SMS and email alarm forwarding, or the older CMR (6BK1700-0HA00-0AA0) for 2G/3G networks. The CMR variant must match the regional cellular band plan.
• Industrial Ethernet switch (managed or unmanaged, 100 Mbit/s minimum) sized for one port per LOGO!, one per TDE if wired, one for the CMR, plus uplink and engineering laptop.
• A static IP plan with at least one free address for the CMR. DHCP on LOGO! is supported but discouraged for the CMR link.
• Administrator access to each LOGO! base module for IP, subnet, and gateway changes. Per the LOGO! network configuration page (ID 109741041), IP address, subnet mask, and gateway can only be edited with administrator credentials.

5. Three-Group Topology Design

The reference deployment consists of three independent LOGO! clusters sharing a single physical Ethernet segment:

• Group 1: 3 × LOGO! 8 base modules + 1 × LOGO! TDE
• Group 2: 2 × LOGO! 8 base modules (no local HMI)
• Group 3: 4 × LOGO! 8 base modules + 2 × LOGO! TDE

All eleven base modules and three TDEs sit on the same /24 subnet. A single LOGO! CMR is the gateway to the cellular network. Because the CMR can only meaningfully maintain a small number of concurrent S7 sessions to a single partner, the recommended pattern is: select one gateway base module per group and bridge that base to the CMR using a dynamic connection. The other bases in each group reach the gateway base using static connections.

The per-base connection budget then looks like the table below. Counts assume one CMR-facing dynamic link per gateway base and a TDE static link where applicable.

This topology leaves 8 static connections as a hard ceiling per base. The gateway bases use only 3-4 static slots, leaving the static budget largely intact for future HMI or PLC peer additions.

6. Configuring Static Connections Within a Group

Static connections are configured entirely inside LOGO! Soft Comfort. Open the project for the gateway base of a group and proceed as follows:

1. Open the Tools > Ethernet Connections dialog. The dialog lists every configured S7 connection with its TSAP, partner IP, and role (client/server).
2. For each peer base in the group, add a new S7 connection. Mark the gateway as Active (client) and the peer as Passive (server). The TSAP pair must be unique; a common convention is 01.00 for the local TSAP and 02.00 for the remote TSAP, incrementing the second octet per pair.
3. Map the data blocks. Each base has VM area 0-850 (LOGO! 8) or 0-1999 (LOGO! 8.3 with V8.3 firmware). Use the network input/output markers in the FBD/LAD editor to bind VM addresses across bases.
4. Add the TDE in Tools > TDE. The dialog automatically creates one static S7 connection to the TDE's IP. Verify the TDE appears with a green link indicator after the project is downloaded to both base and TDE.
5. Download the project to the gateway base. On startup the base opens all static S7 connections to the configured peer IPs. If a peer is offline, the base retries every few seconds; this does not consume additional slots, it only consumes retry CPU time.

7. Configuring the Dynamic Connection to the LOGO! CMR

The dynamic connection is the opposite direction: the CMR initiates the S7 session to the gateway base. This is the only viable direction because the CMR is the device that needs to push a fault text message out, and because the gateway base is a TCP server that has just accepted the connection.

1. On the gateway base, in the same Ethernet Connections dialog, leave the CMR side empty. Do not create a client connection to the CMR. The base has no knowledge of the CMR at this point.
2. On the CMR web configuration interface (default address 192.168.0.100, credentials admin / printed on the device label), open Connections > S7 Connections and add a new S7 partner.
3. Set partner IP to the gateway base IP, for example 192.168.0.11 for Group 1. Set partner TSAP to the gateway's free server TSAP, for example 03.00. Set the local CMR TSAP to 01.00 or the value printed in the CMR housing.
4. Enable cyclic polling with a 5 s interval for keep-alive; this is what causes the CMR to open the dynamic connection. Set the poll VM area to a small set of tags (typically the first 16 bytes of the gateway's VM area, used as a fault code register and acknowledge bit).
5. Configure SMS or email templates in the CMR Alarms page. Bind each alarm to a specific bit transition in the polled VM area. The CMR can also issue a write back to the gateway VM area; this is the path used to acknowledge the alarm from the SMS reply.

Each gateway base therefore consumes exactly one dynamic slot on its connection budget for the CMR. The other 7-13 dynamic slots per base remain free for engineering laptops, mobile HMIs, or diagnostic dashboards.

8. IP, Subnet, and Gateway Configuration

Network identity on LOGO! 8 is set either from the device menu (Settings > Network) or from LOGO! Soft Comfort under Tools > Ethernet. The Siemens support article on LOGO! network configuration notes that administrator access is mandatory; an operator or standard user cannot change IP, subnet, or gateway once the device is in run mode.

Apply the following values during commissioning:

Keep the gateway address consistent across all bases only if you actually route off-subnet; the LOGO! gateway field is required for the CMR to reach the cellular network's DNS server when resolving SMS provider hostnames. If SMS is delivered via raw SMTP-to-SMS gateway IP, the gateway address is still required for outbound reachability.

9. LOGO! CMR Integration for Fault Text Messaging

The CMR2020 is the only Siemens cellular module designed to interoperate with LOGO! 8.3 over Ethernet. Once the dynamic S7 link is up, the CMR can:

• Poll a fault register in the gateway base every 1-60 s
• Trigger an SMS or email on a 0-to-1 transition of any of the 16 polled bits
• Receive an SMS reply from the operator and write an acknowledgement bit back to the gateway VM area
• Forward the fault code to a central SCADA via its built-in MQTT client (firmware 2.4 or higher)

Since each gateway base exposes 16 VM bits of fault codes, the three-group topology can carry up to 48 distinct fault identifiers, with each gateway translating its local cluster faults into the 16-bit block the CMR is polling. This avoids the need for the CMR to maintain a separate S7 connection to every base in the system.

10. Verification and Commissioning

After downloading the project to every base, perform the following checks in order:

1. On the gateway base, navigate to Diagnostics > Ethernet > Connections. The display should show all configured static S7 partners in the established state and the TDE marked connected.
2. From the engineering laptop, ping the gateway IP, the peer IPs, and the CMR IP. A ping failure on a peer base indicates either a wrong IP, a missing gateway, or a switch port issue, not a LOGO! fault.
3. From LOGO! Soft Comfort, go online to the gateway base and use the VM area monitor to confirm a forced value on a peer base propagates to the gateway VM area mapped for that peer.
4. On the CMR web UI, observe the S7 connection status. It should transition from disconnected to connected within 10 s of the gateway base being in run mode. The S7 partner entry shows a green LED in the dashboard tile.
5. Force a test fault bit in the gateway VM area; the configured SMS should arrive on the test handset within 30 s. Force a 1-to-0 transition to verify that the CMR does not re-fire on the same alarm.
6. Send a reply SMS from the test handset using the configured keyword; the CMR should write the corresponding acknowledge bit back into the gateway VM area, observable in the VM monitor.

Record the on-site results in the commissioning log: IP plan, S7 TSAP map, CMR connection state, test SMS round-trip time, and acknowledge-bit response time. These metrics form the baseline for future troubleshooting.

11. Troubleshooting Matrix

12. Field-Proven Caveats

A few constraints are easy to miss in the project documentation and only show up under load or after a long uptime:

• The 16-connection limit is enforced by the LOGO! firmware. If a 17th partner attempts to connect, the base accepts the TCP session, immediately closes it, and increments an internal rejection counter that is not visible on the TDE or in the web UI. Symptom is a partner that reconnects every few seconds.
• When the gateway base loses power, all 16 connection slots release, but the partner devices may keep retrying at their own interval. After gateway power-up, peer S7 connections re-establish in the order they are configured; if the CMR dynamic link is configured last, expect a 10-20 s SMS outage after every gateway reboot.
• The LOGO! TDE consumes a connection slot even when the operator is not looking at the screen. There is no power-save disconnect. A base with two TDEs has only 14 remaining slots, not 16.
• Cellular networks add 1-3 s of latency to the dynamic S7 keep-alive. A keep-alive interval shorter than 10 s may cause the CMR to flag the connection as unstable and fall back to a slower retry schedule.