LOGO! 8 (0BA8) PC Download Troubleshooting: Network and Program

Overview

Siemens LOGO! 8 (catalog designation 0BA8) is a compact logic module with on-board Ethernet that is normally programmed from LOGO! Soft Comfort (LSC) over a direct LAN cable. The vast majority of "PC → LOGO! download does not work" complaints fall into one of three categories:

1. Incorrect IP / subnet assignment on PC and on the base module, or the assignment not actually committed into the device.
2. LSC version mismatch with the LOGO! firmware family (FS03 / FS04) so the program is generated for a newer device than the target.
3. A circuit-diagram problem — for example, a Flag block with no path to a digital output — that the compiler silently rejects at transfer time, even though the program uploads, edits, and runs in simulation.

This reference reconstructs the three failure modes from first principles, shows how to confirm which one is hitting your installation, and gives a verification procedure for each branch. The article is based on the documented behavior of LSC V8.0 / V8.1 / V8.2 / V8.3 against LOGO! 8 base modules (0BA8, FS03) and LOGO! 8.1 / FS04 (0BA8.1, FS04) hardware.

Symptom Catalog

The following behaviors are the ones field engineers most often mis-classify as "the network is broken" but that actually have nothing wrong with the Ethernet link:

Network Configuration for a Direct PC ↔ LOGO! Link

LOGO! 0BA8 and 0BA8.1 both ship with a default IP of 192.168.0.10/24 and a default gateway of 0.0.0.0. The simplest robust configuration for a one-to-one link is to keep the LOGO! at its default and align the PC to the same subnet. The configuration shown below is the canonical one that has proven reliable across LSC V8.x.

Physical layer is plain Cat 5e or better Ethernet. All LOGO! 8 base modules have auto-MDI/MDIX on the RJ45, so a straight-through cable works against a PC NIC and a cross-over cable works against older switches. There is no need for PoE; the LOGO! powers the Ethernet port from its 24 V supply.

Disabling the Windows side that interferes with transfer

Two Windows features are responsible for most "I can ping the LOGO! but transfer still fails" tickets:

1. Wi-Fi: if Wi-Fi is enabled and has a default route to a real network, the 192.168.0.0/24 traffic may go to the wrong adapter depending on interface metric. Disable Wi-Fi, or set the wired NIC's metric lower than the wireless one with Set-NetIPInterface -InterfaceAlias "Ethernet" -InterfaceMetric 10.
2. Windows Defender Firewall with Advanced Security: even if you disabled the firewall, the scope filter can still block inbound S7-style TPKT frames. Add a rule to permit TCP port 102 and UDP port 161 (SNMP) for the Ethernet profile, or temporarily turn off the public profile firewall.

Verifying the link before touching LSC

1. Open a command prompt: ping 192.168.0.10 -n 4. A successful reply within < 5 ms confirms Layer 3 reachability.
2. From a browser, open http://192.168.0.10. The LOGO! web server returns its status page with IP, firmware, and program name. If you see this page, LSC will be able to connect.
3. From a browser, open http://192.168.0.10:8080/var for the variable table — a fast sanity check that the running program is the one you expect.

IP Assignment Through LSC: Why the Dialog Re-Opens

The LOGO! 0BA8 stores its IP, subnet, and gateway in non-volatile memory. LSC exposes the assignment two ways: through File → Preferences → Online Settings → Assign IP Address, and through the connection dialog that pops up when you click PC → LOGO! on the toolbar.

The "pop-up every time I connect" symptom is the network equivalent of not pressing Apply on a Windows adapter properties dialog. The fix sequence is:

1. Connect to the LOGO!. The pop-up appears with the Assign IP address tab open.
2. Enter 192.168.0.10 / 255.255.255.0 / 0.0.0.0 if not already there. Make sure the IP from LSC radio button is selected, not DHCP (no server on a direct link) and not Manual on the device (only relevant when the IP is set on the LOGO! display).
3. Click Assign. Wait for the dialog to confirm.
4. Power-cycle the LOGO! if you changed the IP from a non-default value. The change is persistent across power-cycles, but a fresh boot is the cleanest way to confirm.

LSC Version vs. LOGO! Firmware Family

Each release of LSC is mapped to one or two LOGO! firmware families. Mixing them gives a connect-then-grey-out behaviour, not a hard error:

If you create a program in LSC V8.3 and try to download to an FS03 device, the transfer will fail with a message of the form The program cannot be transferred to the connected device. LSC V8.1 is the last common LSC that will work against both FS03 and FS04 hardware and is the version to install for a mixed fleet. Confirm the device firmware with Help → About on the LOGO! display, or read the FSxx string from the LOGO! web server status page.

Root Cause: Programs with No Output Connection

The third — and most subtle — failure mode is a project that compiles, simulates, and uploads cleanly, but that the device refuses to take. The Info Window (F4) is the diagnostic. When the program is opened, the Info Window reports lines such as:

Block 27 (Flag, M17) has no connection to an output.
Block 41 (Flag, M22) has no connection to an output.
Warning: program is not referenced from Q1..Q16.

What is happening is that LSC, when generating the binary it ships to the LOGO!, walks the circuit and verifies that every live block can be reached from a digital output (Q1..Q16) or from a network output that is in turn bound to a real Q. Blocks that do not reach a real output — typically Flag (M) blocks, but also Shift register bits, Counter coil blocks used only as memory, and Analog flag blocks — are stripped from the runtime image. The downloader detects that the image is materially different from the source circuit and refuses to write it.

Why Flag blocks cause this

Flag blocks (Memory Marker, range M1..M27 on LOGO! 0BA8) are intended as intermediate storage: the output of one block feeds the input of another. When a Flag is used as a dead-end — its output is not wired to any other block, or that path is broken — LSC has nowhere to route the runtime value. The download is rejected to prevent the user from being surprised by logic that "compiled" but did not run.

The first step toward the fix is to ask: is the Flag actually needed? Common reasons engineers add a Flag and forget to wire it are:

• They intended to latch a momentary pushbutton to drive a coil and a second block, but wired only the second block.
• They used a Flag as a self-holding latch without an output coil in the path.
• They renamed an existing block to a Flag and never re-wired downstream consumers.

Resolution procedure for the Flag issue

1. Open the project in LSC, press F4 to bring up the Info Window, and read every warning.
2. For every Flag block named in a warning, identify the target that should have consumed it: a coil (Q), another block, or a network output.
3. Either rewire the Flag's output to that target, or delete the Flag entirely if it is no longer needed.
4. Reopen the Info Window. All Block … has no connection to an output warnings must be gone before the project will transfer.
5. Rebuild and re-save the project (File → Save as with a new revision tag, e.g. myproj_v02.lsc).
6. Run PC → LOGO! → Transfer (Ctrl+D).

Transfer Mode and Run/Stop Behaviour

A successful PC → LOGO! transfer writes the new program into the device, but it does not necessarily start the new program running. There are four states to be aware of:

The most common "the download worked but nothing happens" ticket is a transfer into a STOP-ed device. The fix is LOGO! → Start on the toolbar (or pressing the OK button on the LOGO! display for > 3 s).

Step-by-Step Resolution Procedure

1. Confirm reachability: ping 192.168.0.10 from the PC. If it fails, the problem is network, not LSC.
2. Confirm firmware: from a browser, open http://192.168.0.10 and read the Firmware version line. Match it against the LSC version you have installed.
3. Match the LSC version to the firmware family (see the table above). If the project is the wrong generation, open it in the matching LSC and re-save before retrying.
4. Open the project in LSC and read F4. If the Info Window lists output-disconnected blocks, fix them, re-save.
5. Connect to the LOGO! using PC → LOGO! Connect. The IP-assign dialog appears: set the IP, click Assign, wait for confirmation, then click OK.
6. Check the Online state: the toolbar's Online indicator must show green. If it is grey, the LSC install is treating the device as offline; toggle Extras → Online or restart LSC.
7. Download: PC → LOGO! → Transfer (Ctrl+D). The progress bar should reach 100 % and the Info Window should report Transfer successful.
8. Verify: the LOGO! display shows the new program name; outputs respond to inputs; LOGO! → Diagram shows the running values overlaid on the circuit.

Verification Matrix

Diagnostic Tools Built into LSC

Info Window (F4)

The single most useful troubleshooting tool. It surfaces compiler errors, transfer-guard warnings, and runtime warnings such as Block not connected to an output and Output not assigned. Always read the Info Window before and after a transfer.

Online / Offline indicator

Located in the status bar. A grey indicator means LSC is in Edit mode and will not be able to download; a green indicator means it is bound to the connected LOGO! and is ready to transfer. Toggling is Extras → Online or Ctrl+1.

Web-based monitoring

Independent of LSC, the LOGO! web server at http://<ip> shows the program name, firmware, current I/O state, and variable values. This is the fastest way to confirm that the program running on the device is the one you think is running.

Common Adjacent Issues

"I changed the program, downloaded, and now the LOGO! is in STOP"

LSC, by default, leaves the device in Stop while the transfer is in progress and only re-starts it on success. If the transfer reports success but the device does not resume, manually LOGO! → Start from the toolbar.

"I get a transfer error about an unknown block type"

The project was created in a newer LSC than the one connected. Open the project in the matching LSC and re-save; do not try to use a downgrade wizard — there is none for 0BA8.

"The PC is on a corporate VLAN and cannot reach the LOGO!"

A direct 1:1 link is not a corporate network. Either take the laptop off the corporate network (disable Wi-Fi, plug a direct cable), or get a managed-switch configuration that bridges the corporate VLAN to a small isolated subnet. The LOGO! has no 802.1X client, so it cannot join a corporate domain.

"SD card says program is loaded but the LOGO! runs the old one"

The LOGO! 0BA8 has an SD slot that takes a micro-SD card with an .lma or .bin project. The card is read at power-up; if a card is inserted with a different program name from the internal one, the LOGO! boots from the card. Remove the card, power-cycle, and confirm the internal program is the one you downloaded.

Best-Practices Checklist

• Pin your LSC version to the oldest FSxx hardware in the fleet. LSC V8.1 is the safest for mixed FS03 / FS04 installations.
• Keep the IP fixed at the LOGO! default (192.168.0.10/24) for a service laptop, and use the IP from LSC radio in the connection dialog.
• Use the F4 Info Window as a release gate. A program with no Info-Window warnings is almost guaranteed to transfer.
• Avoid Flag blocks as dead-ends. If you need a Flag, wire it to a Q or to another consuming block.
• Use version-stamped file names (machine_v01.lsc, machine_v02.lsc). The LOGO! stores the program in non-volatile memory but only one slot; the PC must keep the history.
• Periodically back up the LOGO! to a micro-SD card as a failsafe recovery image.

Field-Proven Diagnostic Decision Tree

1. Is the Online indicator green after Connect? If no → check LSC version vs. firmware FSxx.
2. Is the Info Window (F4) clean? If no → fix the listed blocks; re-save.
3. Does the transfer progress to 100 %? If no → confirm PC ↔ LOGO! subnet and gateway; check firewall; disable Wi-Fi.
4. Is the LOGO! in RUN after transfer? If no → LOGO! → Start on the toolbar or OK on the display.
5. Do the inputs and outputs behave as the circuit specifies? If no → the program is running the new image, the logic is wrong; debug the circuit.