Resolving Siemens LOGO! to UR3e Modbus TCP Connection Failures

Problem Overview

Engineers integrating a Siemens LOGO! 8 (6ED1052-1xxx-xBA8) programmable logic relay with a Universal Robots UR3e collaborative arm over Modbus TCP routinely encounter a Connection status: no route to server indication on the robot side, or a refused TCP handshake on the PLC side, even when both devices report valid IPv4 addresses that appear to share a common subnet. The failure is rarely a true routing problem on a flat shop-floor network. In nearly every documented case the root cause is a combination of (a) the LOGO! Modbus server not being enabled in the LOGO! Soft Comfort project, (b) a hidden subnet-mask or default-gateway mismatch on the UR3e controller, (c) the LOGO! Soft Comfort engineering software holding the only open TCP/502 connection, or (d) the robot side still configured for an older Modbus RTU server address after a project change.

This article consolidates the working configuration for a LOGO! 8 (firmware FS4 or later) acting as a Modbus TCP server and a UR3e (PolyScope 5.13 or 6.x) acting as a Modbus TCP client. It then walks through register mapping, commissioning checks, and a complete troubleshooting matrix for the error states typically reported by field integrators.

System Architecture & Prerequisites

Verify the following hardware and software prerequisites before commissioning. Substituting older hardware is the single largest source of "no route to server" reports.

The LOGO! BM provides a single 10/100 Ethernet port and exposes the Modbus TCP server on TCP port 502. The UR3e controller ships with its own DHCP-enabled Ethernet port (typically XLAN1) and a service port (XLAN2). For deterministic Modbus polling, disable DHCP and assign static addresses to both devices.

Siemens LOGO! 8 Modbus Server Configuration

Two configuration locations must be addressed: the LOGO! BM's IP stack (configured on the device itself or in the LOGO! Soft Comfort project) and the Modbus server enable bit (configured in the LOGO! Soft Comfort project only).

Step 1 — Assign the LOGO! IP Address

1. Open LOGO! Soft Comfort and load (or create) the project.
2. From the menu, select Tools → Select Target Device (or right-click the project node and choose Properties).
3. Open the Network tab and enter the IP address, subnet mask, and default router. Example values that work with a default UR3e controller subnet:

   IP address:   192.168.1.10
   Subnet mask:   255.255.255.0
   Default gateway: 192.168.1.1

4. Click PC -> LOGO! (download) to push the project to the LOGO! BM. After restart, the device advertises its IP on the front-panel display (use the cursor-down key to navigate to Network).

Step 2 — Enable the Modbus Server

1. With the project open in LOGO! Soft Comfort, select File → Properties and open the Modbus Server tab (visible only in LOGO! 8.x projects).
2. Tick Activate Modbus TCP server.
3. Set Port to 502 (default; do not change unless a firewall policy requires a different port).
4. Set Max. number of connections to 8 (LOGO! 8.x supports up to eight simultaneous Modbus TCP clients; the UR3e only uses one, but leave headroom for diagnostic tools).
5. Click OK and re-download the project.

The Modbus server is now active on the configured IP and port. Holding registers start at Modbus address 0 and map directly to LOGO! variable-memory words: address 0 = VW0, address 1 = VW1, etc., through the full VM range of 0..850. This one-to-one mapping is documented in the Siemens LOGO! 8 system manual (entry ID 109751634) under the Modbus TCP topic.

UR3e Modbus Client Configuration

Universal Robots ships a freely available Modbus TCP URCap that adds a client driver to the PolyScope installation menu. Without this URCap, the UR3e exposes only the legacy Modbus RTU server on TCP/502 of the controller itself, which is a different node and uses a different register set.

Step 1 — Install the URCap

1. Insert a USB stick containing the Modbus TCP .urcap file into the UR3e teach pendant.
2. From the PolyScope main menu, choose Setup Robot → URCaps.
3. Select the file, tap Install, and restart the controller when prompted.

Step 2 — Add a Modbus Client and Define Signals

1. From the PolyScope Program tab, choose Installation → Modbus TCP.
2. Tap Add client and enter the connection parameters:

   Host name / IP:  192.168.1.10   (the LOGO! BM)
   Port:             502
   Reconnect delay:  10  (s)
   Timeout:          3   (s)

3. Tap Add signal for each data point. For a typical cell where the UR3e reads a part-present bit and writes a cycle-start bit, define the following two holding registers:

   Signal 1 (input to UR3e):
      Name:        part_present
      Type:        Holding register
      Address:     0     (= LOGO! VW0)
      Polling rate: 10 Hz
   Signal 2 (output from UR3e):
      Name:        cycle_start
      Type:        Holding register
      Address:     100   (= LOGO! VW100)
      Polling rate: 10 Hz

The Polyscope variable part_present will be updated every 100 ms and is read in robot programs as get_standard_digital_in(0) or directly via URScript get_modbus_signal("part_present"). The signal is the canonical reference for the URCap and is documented in the Universal Robots Modbus Client manual.

Network Configuration & Subnet Verification

The single largest source of no route to server on the UR3e is a configuration in which the LOGO! and the UR3e are on different subnets even though their IPv4 prefixes look identical. Verify the three values below on both devices, in this exact order, before chasing anything else.

Ping Test from the UR3e

1. On the UR3e teach pendant, navigate to Setup Robot → Network → Ping host.
2. Enter 192.168.1.10 (the LOGO! address).
3. A successful ping (latency typically <1 ms on a switched copper link) confirms L3 connectivity. If the ping fails, the Modbus client cannot succeed; resolve the network path first.

Register Mapping Between LOGO! and UR3e

The default address space used by the UR3e URCap and the LOGO! Modbus server is the holding-register range (function code 0x03 read, 0x06 / 0x10 write). The mapping is as follows.

Bit-level access inside a 16-bit register uses the LOGO! bit-of-word functions in the FBD editor (set/reset bit in VW, negate bit in VW). For example, exposing UR3e digital input bit 0 of VW0 as a Boolean to the robot program is done by connecting a LOGO! Boolean network to bit 0 of VW0. The robot reads the entire word and uses URScript masking to extract the bit.

Coil (function 0x01/0x05) and discrete-input (function 0x02) access are also supported by the LOGO! Modbus server but are not normally used by the UR3e URCap. Sticking to holding registers avoids ambiguity in register width when both sides are 16-bit.

Verification & Polling Test Procedure

1. Power up the LOGO! and the UR3e. Confirm the LOGO! has no diagnostic LED pattern (a steady display with no symbol other than the network IP is normal).
2. On the LOGO!, force VW100 = 0x0001 from the LOGO! Soft Comfort online monitor.
3. In PolyScope, navigate to Installation → Modbus TCP. The connection state must read Connected, with the last successful transaction timestamp updating.
4. Add a URScript line to a test program: var := get_modbus_signal("cycle_start") and display the result in a popup or write it to a log file. The value should read 1.
5. Toggle the LOGO! input that drives VW0.0 and verify that the UR3e polls the value within 100 ms (one polling interval).
6. Power-cycle the LOGO! while the UR3e program is running. The URCap must reconnect automatically within the Reconnect delay window (default 10 s). Persistent no route to server after a power-cycle indicates either a firewall on the UR3e or an IP-stack issue on the LOGO!.

Troubleshooting Matrix

Advanced Notes & Field-Proven Caveats

• Watchdog on the LOGO! side: The LOGO! 8 Modbus server does not echo a connection-loss event. Implement a heartbeat in the robot program: a register that the UR3e toggles every 250 ms. If the LOGO! does not see the toggle within 1 s, declare communication lost and force a stop.
• Polyscope version differences: PolyScope 5.13 and 6.x both ship the Modbus TCP URCap, but the older 1.x version did not support the Reconnect delay field. Update to the latest URCap from UR Modbus Client if you observe erratic reconnects.
• LOGO! 8.3 specifics: The 8.3 generation (6ED1052-1xx01-xBA8) supports the same Modbus register map but adds an additional S7 connection limit. If you are mixing Modbus and S7 PUT/GET on the same device, the Modbus server may refuse connections when the S7 stack is saturated. Reduce the number of S7 partners in the project properties.
• Switch port isolation: Some plant networks isolate ports with port security. A LOGO! that has been offline for an extended period can lose its CAM table entry and appear unroutable. Reset the switch port or assign a static ARP entry on the UR3e controller.
• Firewall on the UR3e: The e-Series controller does not run iptables by default for the XLAN1 port, but a system-installer modification can introduce a firewall. If you have full access, run iptables -L -n from a service shell to confirm that no rules block port 502.