Resolving Siemens LOGO! 'Unable to Access Remote Device' Error

Overview

The "Unable to access the remote device" message is one of the most common failure modes reported by engineers commissioning a Siemens LOGO! 8.3 logic module with LOGO! Soft Comfort (LSC). The error appears in the LOGO! -> Ethernet Connection dialog when an operator clicks the Online or Test button after the device has already been discovered on the subnet by the Refresh icon.

The classic symptom set is:

• Refresh icon (two blue arrows) lists the LOGO! BM with its configured IP (typically 192.168.0.3).
• ICMP ping to the LOGO! IP succeeds from the PC.
• TCP transfer of the LSC project fails with "Unable to access the remote device."
• Disabling or moving the BM outside the DHCP pool restores communication.
• Older LOGO! BMs (e.g., 6ED1052-1MD08-0BA0) on the same PC and same IP work normally.

Three independent root causes have been confirmed across multiple field reports:

1. Firmware / LSC version mismatch between LOGO! 8.3 BM and an LSC V8.2.x installation.
2. DHCP pool collision when the BM holds a static IP that the DHCP server is free to hand out again.
3. Host network misconfiguration (dual NIC, missing gateway, firewall blocking UDP/TCP 8443, antivirus NPF filter).

This article consolidates the documented diagnostic procedure and the corrected commissioning workflow that resolves all three.

Affected Hardware and Software

Technical Background: How LSC Talks to a LOGO! BM

LOGO! Soft Comfort uses Siemens' S7ONLINE access point over TCP/UDP port 8443 to upload and download projects. Discovery is a UDP broadcast on the local subnet; download is a TCP session negotiated with the BM after discovery. The "Unable to access the remote device" error is raised by LSC when the TCP session cannot be opened within the timeout window even though the BM responded to the discovery broadcast.

The fact that the BM appears in the refresh list and answers ping proves step 1 and step 2 succeed. The error therefore points at step 3: the TCP session is being refused or dropped somewhere between the PC and the BM. The three causes documented below each break this handshake in a different way.

Root Cause 1: LSC and LOGO! Firmware Version Mismatch

The most frequently missed cause is a hidden version mismatch. The original report named a brand-new 6ED105-2MD08-0BA1 paired with an installation that the engineer believed to be current. Several follow-up posts confirm the same pattern: the BM is a LOGO! 8.3 device, but LSC is the older V8.2.x line.

How to verify

1. Open LSC and select Help -> About. Read the exact build string.
2. On the LOGO! BM, press ESC until the main menu appears, then navigate to Diagnostics -> Product Information. The firmware line will read either LOGO! 8.2 or LOGO! 8.3 for current hardware.
3. Cross-reference against the matrix in the next section.

Compatibility matrix

Resolution

1. Download LOGO! Soft Comfort V8.3 from Siemens Industry Online Support.
2. The download is export-restricted. You must sign in with a registered Siemens Industry account and expand your registration profile with the requested business data. Without that step the installer link is grayed out.
3. Install V8.3 over (or alongside) V8.2.x. The two installs use different program folders and can coexist.
4. Open the project in V8.3, repeat the download sequence, confirm "Transfer complete."

Root Cause 2: Static IP Inside the DHCP Pool (Collision)

Several field reports converge on a behavior that, while unusual for industrial devices, is documented for the LOGO! 8.3 firmware: if the BM's static IP address falls inside the DHCP server's pool, the BM loses the TCP handshake to the device that the DHCP server has just leased that address to.

The DHCP server has no knowledge of the BM's manual lease. It hands the address to whoever asks first after expiry. The router then sends gratuitous ARPs and the BM, not having a duplicate-address-detection routine of its own, becomes unreachable on L4 even though it still answers ICMP from cached ARP entries on a subset of hosts.

This explains the symptom precisely: ping works intermittently, refresh works (broadcast), but the TCP session that follows fails when the BM and the leased device contend for the IP.

How to verify

1. Log into the DHCP server / router and read the configured pool range (commonly 192.168.0.100 - 192.168.0.200).
2. Compare to the BM's static IP. If it falls inside the pool, treat as the likely cause.
3. Watch the BM's MAC address in the router's DHCP lease table. If the BM's MAC never appears with its static IP, the pool is colliding.

Resolution

1. Re-address the BM to a value outside the DHCP pool. Field-confirmed working example: 192.168.0.150 with a pool of 192.168.0.100 - 192.168.0.200.
2. On the BM itself: navigate to Network -> IP Address and enter the new address manually.
3. Update the LSC Ethernet Connection dialog to match.
4. Re-attempt the transfer.

Root Cause 3: Host Network Adapter Misconfiguration

The LSC refresh request goes out as a subnet-limited broadcast on every active NIC of the PC. Whichever NIC responds first is the one LSC tries to use for the subsequent TCP transfer. If the host has two adapters (wired + Wi-Fi, wired + VPN, wired + server NIC), LSC may discover the BM through one adapter and then attempt the TCP transfer through another, which fails because the broadcast is non-routable.

Diagnostic: enumerate the active path

Run from an elevated command prompt on Windows 10 / 11:

ipconfig /all
route print
netsh interface show interface

For the BM at 192.168.0.3 with PC at 192.168.0.2, confirm exactly one route in the routing table:

Network Destination    Netmask          Gateway        Interface         Metric
0.0.0.0                0.0.0.0          192.168.0.254  192.168.0.2       25
192.168.0.0            255.255.255.0    0.0.0.0        192.168.0.2       25

A second default route through the unrelated NIC (for example 192.168.0.254 on the second NIC while 192.168.0.2 is on the first) creates an asymmetric path. LSC's refresh broadcast replies may arrive through the wrong interface and confuse the connection logic.

Resolution

1. Disable every NIC not actively used to talk to the LOGO! BM (Wi-Fi off, VPN off, Hyper-V virtual switches off, docking-station NIC off).
2. Confirm with ipconfig that only the wired adapter to the LOGO! shows a 192.168.0.x address.
3. If the BM is on a separate management subnet, enter a Default Gateway on the wired adapter pointing at the router on that subnet. An empty gateway field combined with a static IP is a frequent cause of "discovery OK, transfer fails."
4. Repeat the transfer.

Direct PC-to-BM cabling

For point-to-point commissioning, a crossover cable is not required on modern PCs. The BM auto-MDIX's the link. Disable any "green ethernet" energy-saving feature on the PC NIC; some implementations drop the link below 100 ms during power-state transitions and the TCP handshake times out.

Root Cause 4: Firewall, Antivirus, and NPF Drivers

Windows Defender Firewall and most enterprise antivirus suites ship with rules that block inbound broadcasts and unrequested TCP sessions on port 8443. LSC requires that the BM-initiated TCP callback be allowed back into the PC.

Resolution checklist

1. In Windows Defender Firewall with Advanced Security, create an inbound rule for %ProgramFiles%\Siemens\LOGOComfort\LogoComfort.exe allowing any port, any profile, during commissioning.
2. Temporarily disable third-party antivirus / endpoint protection (CrowdStrike, SentinelOne, Trend Micro, Sophos) and retry. If the transfer now succeeds, add an exclusion for LogoComfort.exe and for TCP/UDP 8443.
3. Verify the WinPcap / Npcap driver is the version bundled with LSC. Mixing an old Npcap install with a newer LSC (or vice versa) breaks the broadcast listener. Reinstall Npcap from the LSC installation media when in doubt.

Step-by-Step Commissioning Workflow (Field-Tested)

1. Confirm the BM catalog number ends in -0BA1 (LOGO! 8.3). If yes, install LSC V8.3 before continuing.
2. Wire the BM directly to the PC with a known-good Cat5e/Cat6 cable. Power the BM.
3. Disable every PC NIC except the wired one. Set the wired NIC to a static IP outside the DHCP pool, for example 192.168.0.2 / 255.255.255.0, gateway 192.168.0.254.
4. Open LSC, select Tools -> Ethernet Connection. Click the refresh icon. The BM should appear.
5. Click Test. A green status means the TCP handshake succeeded and you can proceed to PC -> LOGO!.
6. Click PC -> LOGO! to download. Confirm "Transfer complete."
7. Re-enable Wi-Fi / VPN / other adapters only after the transfer is finished.

Verification

Troubleshooting Matrix

Notes on CMR2040 and Cloud Connectivity

The CMR2040 module (6BK1400-0BA00-0AA0) extends LOGO! with remote access over cellular. When the BM sits behind a CMR, LSC discovery traverses the CMR tunnel but transfer is sensitive to the same DHCP-collision condition because the CMR relies on a stable peer IP. Apply the same "static IP outside the DHCP pool" rule when commissioning through a CMR, and reserve the CMR's IP in the upstream router so that it cannot be re-leased either.

Reference: Key URLs

• LOGO! Soft Comfort V8.3 download
• Siemens LOGO! product page
• Siemens Industry Online Support - LOGO! entry point

FAQ