Resolving the Siemens LOGO! "Online Test Not Possible" Error Over a Building Network

When a Siemens LOGO! 8 (or LOGO! 8.3 / LOGO! 8.4) is monitored successfully from a local network drop next to the controller, but the same project file is rejected with the dialog "Online test not possible - The circuit programs on the device and the PC are not identical" from a remote office, the fault almost always lies in one of two distinct mechanisms: a runtime parameter drift caused by networked peer-to-peer traffic, or a path-dependent integrity check that is sensitive to network behaviour. This reference walks through how the online test comparison actually works, what causes it to disagree when the bytes are otherwise identical, and how to bring up a stable remote engineering channel.

1. How the LOGO! Online Test Comparison Works

LOGO!Soft Comfort does not actually diff line-by-line. The "Online test" command in the Tools menu performs a fixed comparison: it reads a single integrity token from the LOGO! and compares it against the token that LSC computes from the open *.lsc or *.lma project file. The token has two parts:

1. Circuit-program checksum (static). A CRC-style hash over the compiled function-block diagram (FBD) - every block, every connection, every constant, every parameter-box default. The LOGO! stores this in non-volatile memory whenever a new program is transferred with PC → LOGO!. It is recomputed by LSC at compile time and embedded in the *.lma binary that is downloaded to the controller.
2. Parameter-set image (dynamic). The current values of every parameter exposed in the program (threshold trigger setpoints, on/off delays, counter presets, analog gain/offset, timer runtime values, M-flag states for VM mapping, etc.). These are read at the moment the online test starts and used only for display, but a single byte of the online-test handshake still varies depending on whether LSC is satisfied that the parameter set is "in sync" with the program source.

The handshake used to read those two values is a UDP-based, connectionless dialog on port 10005 (LOGO! 0BA7 and earlier use TCP 8443 - 6BA7 introduced a separate web-server port; 0BA8 prefers UDP). LSC sends a GetProjectInfo request, the LOGO! responds with a small TLV (type-length-value) record containing the checksum and a snapshot, and LSC matches the checksum against the open project. If the checksum matches, the dialog reports Online test possible; if not, you see the dialog the operator in the source ticket saw.

2. The Two Real Root Causes

2.1 Runtime parameter drift across a peer-to-peer LAN

LOGO! 8 supports up to eight S7-compatible peer connections (PUT/GET, ISO-on-TCP, MODBUS-TCP server, MODBUS-RTU master) and up to sixteen network variables (Network Inputs / Network Outputs in the VM mapping table). The peer on the other side - in the case described, a Simatic S7 PLC in another cabinet - can write into LOGO! memory areas at runtime, including the parameter block of certain function blocks. Two real-world cases are common:

• Threshold trigger (B001-B013 family) setpoint write-back. A peer S7 program pushes a new On / Off threshold into the LOGO! over a PUT/GET connection. The value is written into the volatile parameter set; it does not change the circuit-program checksum, but it changes the secondary snapshot, which LSC treats as a sign of drift.
• Analog amplifier / math instruction gain update. A peer writes a new gain or offset to a math instruction (B015-B043). Same symptom.
• Network variable write into a flag that is also a parameter box default. If the S7 peer and the LOGO! both write the same tag, the LOGO! parameter set will diverge from the offline project the moment the S7 takes control.

This is exactly the case the engineer in the source case described: the LOGO! is being used to pass signals to a peer S7 over the building network. As soon as the S7 begins writing, the parameter set drifts, and the next online test from the office fails. The same parameter set, when read from a network drop next to the LOGO!, may still report OK only because the parameters were last overwritten just before the test and happen to match the project defaults within tolerance - or because the local test was performed inside a different timing window. The behaviour is timing-dependent and confusing.

2.2 Path-dependent integrity read (MTU, latency, fragmentation, NAT)

If you have already ruled out parameter drift (see Section 4), the second family of causes is the network path between the engineering PC and the LOGO!:

3. Differentiating Real Program Differences from Runtime Drift

Before chasing the network, prove the program in the controller is byte-for-byte the program on disk. Use this decision tree:

1. Open LSC, File → Open the saved project machineX.lsc.
2. Select Tools → Transfer → Upload from LOGO! to PC. Save the upload as machineX_upload.lma.
3. Compare the two files with a binary diff: fc /b "machineX_upload.lma" "machineX.lma" on Windows, or xxd machineX_upload.lma > a.txt; xxd machineX.lma > b.txt; diff a.txt b.txt on Linux.
4. Within LSC, open Tools → Options → Compare Programs (LSC V8.3 and later) for a structured block-by-block view. The dialog shows which parameter boxes differ between the two programs.
5. If the two binaries are identical, the fault is in the path or in the runtime parameter set, not in the program. Continue to Section 4.
6. If the two binaries differ in the static circuit (function-block IDs, connection list, comment table), the controller holds a different program from the one in your project. This is usually a sign that a colleague re-flashed the LOGO! from a different version. Re-download the canonical *.lma from the office to confirm and document the change in the project's revision log.

4. Isolating Parameter Drift from the Peer S7

Once the static programs are confirmed identical, prove or disprove parameter drift in three steps:

4.1 Capture the parameter set remotely

From the office, do an Upload from LOGO! to PC while the S7 peer is actively writing. Save the result as drift_capture.lma. Open the file in LSC, switch to Online test with the Show parameter set option enabled (LSC V8.2 and later: View → Parameter Box Monitor). Every block whose parameter box shows a value in red is one the LOGO! has overwritten since the last cold start.

4.2 Capture the parameter set locally

Walk to the local drop, repeat the upload and parameter-box inspection. If the same blocks are red, the drift is permanent - the S7 is overwriting the parameter set on every cycle. If the local capture is clean but the remote capture is red, the difference is timing: the local engineer arrived after the S7's last write window.

4.3 Confirm with network capture

Run Wireshark on the office PC and filter for udp.port == 10005 while the S7 peer is busy. You will see two streams: the S7's PUT/GET writes and LSC's online-test polls. The decisive packet is the LOGO!'s response to LSC's GetParameterSet request - it contains the current parameter set, and you can compare the bytes in the response with the bytes LSC expects from the offline project. If they differ, you have hard proof of drift.

5. Network-Path Troubleshooting Procedure

Work through this in order; each step rules out a layer before you move on.

1. Layer-1 / Layer-2 reachability. From the office, ping <LOGO_IP> -t for 60 seconds. Loss > 0% and high jitter are bad signs. arp -a should show exactly one MAC for the LOGO! IP; duplicates mean an IP conflict (Section 2.1 of the source case explicitly tested this - duplicate-IP behaviour on a routed segment can manifest as a corrupted response that looks like a checksum mismatch).
2. Layer-3 MTU. From the office, run ping <LOGO_IP> -f -l 1472 (Windows) or ping -M do -s 1472 <LOGO_IP> (Linux). If 1472 fails and 1400 works, the path MTU is below 1500 and you have found a fragmentation source. Lower the engineering NIC MTU to 1400 or remove the VPN/PPPoE on the engineering VLAN until the test passes.
3. Layer-4 port reachability. From the office, Test-NetConnection <LOGO_IP> -Port 10005 (PowerShell) or nc -vz <LOGO_IP> 10005 -u (Linux). If UDP 10005 is filtered, the firewall in the path is the problem. Open the port bidirectionally or, in a pinch, switch the engineering link to a flat L2 VLAN that does not traverse the firewall.
4. Web-server probe. In a browser, open http://<LOGO_IP>. If the LOGO! web UI loads, IP and routing are good. If it does not, the network problem is upstream of LSC's UDP traffic and will affect the online test too.
5. Eliminate the VPN. If the office is connected over a corporate VPN, disconnect and use a direct connection (tether the engineering laptop to a 4G/5G hotspot or to a switch on the same VLAN as the LOGO!). If the online test now passes, the VPN MTU, NAT timeout, or split-tunnel ACL is the cause. Fix the VPN profile (lower MTU to 1380, raise NAT idle-timeout to 600 s) rather than the LOGO! configuration.
6. Eliminate the building-network router. If the office VLAN is routed to the LOGO! VLAN, temporarily move the engineering laptop onto the LOGO! VLAN via a small unmanaged switch at the cabinet. If the test now passes, the router is the cause. The most common culprit on a routed path is a stateful firewall with a session timeout shorter than LSC's polling interval.
7. Eliminate the management plane. Confirm the managed switches along the path are not running a control-plane storm or a high-CPU process. show processes cpu history (Cisco IOS) and equivalent on HPE/Comware should show < 30% sustained. A CPU-bound switch drops UDP and presents exactly this failure mode.

6. Local vs Remote Online Test - Comparison

The fact that the test passes locally and fails remotely is, by itself, diagnostic. It tells you either the network path is corrupting the response or the parameter set has drifted further between the two timing windows. The LSC dialog does not tell you which.

7. Preventing the Error in Networked LOGO! Installations

7.1 Lock the parameter set

Where the LOGO! is acting as a pure peer to a Simatic S7, prefer the following design pattern: the LOGO! owns the logic and the constants; the S7 owns the setpoints via VM mapping, not via direct parameter-box writes. The S7 should write to a network input on the LOGO! and the LOGO! should compute the threshold internally. This keeps the LOGO! parameter set static and the online test will succeed at any point in the cycle.

7.2 Pin LOGO! IP outside the DHCP pool

Assign the LOGO! a static IP outside the DHCP range of every router in the path, including the office router, the building core router, and any access-layer router. Use a reservation on the DHCP server if you cannot set a static IP on the LOGO! itself (LOGO! 0BA8 supports DHCP by default - this is a known foot-gun). Verify with show ip dhcp binding | include <LOGO_MAC> on the router.

7.3 Document the peer S7's write set

Maintain a register in the project's revision log of every S7 PUT/GET that writes into the LOGO!. Each entry should list the source DB / byte offset, the destination LOGO! tag, and the trigger. The first time the online test fails, this list tells you instantly which block's parameter box is going to be red.

7.4 Use the web UI as a quick check

The LOGO! web UI (TCP 80, no authentication by default on 0BA8 - change the password) shows the live parameter box values in a browser. If the parameter set in the web UI matches the project file, the program is in sync; the online test failure is a network-path problem. If the web UI shows different values, the parameter set has drifted.

8. Verification Checklist

Run through this list before declaring the case closed.

• *.lma on disk matches the upload from the office (binary identical, byte for byte).
• *.lma on disk matches the upload from the local drop (binary identical).
• Ping from office to LOGO! succeeds with 0% loss over 60 s.
• UDP 10005 from office to LOGO! succeeds (or is at least not blocked at the firewall).
• Path MTU from office to LOGO! is ≥ 1500 (or engineering NIC MTU reduced to match).
• LOGO! web UI loads from the office.
• Wireshark capture of the GetParameterSet response shows parameter bytes equal to the offline project.
• No duplicate ARP entry for the LOGO! IP on the office VLAN.
• LOGO! static IP set outside every DHCP pool in the path.
• S7 peer write set documented and limited to VM mapping rather than direct parameter-box writes.
• Online test passes from office against the original saved project (the one that originally failed).
• Online test passes from office against a fresh upload (sanity check).

9. Field-Proven Caveats

10. Related Error Strings You Will See in the Same Family

For the official Siemens documentation set on LOGO! 8, see the LOGO! 8 System Manual (6ED1052-1**08-0BA1), the LOGO!Soft Comfort V8.4 Online Help, and the LOGO! 8 Communication (Ethernet) Manual. The parameter-box write semantics and the online-test checksum format are described in the System Manual chapter on Program transfer and online test.

11. Frequently Asked Questions