Troubleshooting LOGO! 8 FS4 Communication Failures with S7-1200

Problem Summary

When migrating from a LOGO! 8 BM (0BA8, pre-FS4) to a LOGO! 8 BM FS4 module, S7-1200 CPUs (typically firmware V4.1 through V4.6) lose live data exchange in three distinct ways:

1. TIA Portal DB monitoring breaks: Bits that should toggle from a LOGO! program (for example, a 1 Hz flag or a marker M57) appear frozen at their last value. The connection status shows "established" but the data does not refresh.
2. LOGO! Soft Comfort V8.1 online test freezes: Inputs and outputs show the correct state at session start, then stop updating. Timer values stop incrementing after the first scan.
3. HMI network inputs go dark: A previously working HMI tag bound to LOGO! network inputs (NI1-NI24 / NQ1-NQ20) shows no value or shows a stale snapshot, while the same tag works in a freshly built TIA project.

The root cause is not a hardware fault on either device. It is a project-to-hardware binding artifact created by the functional-state (FS) versioning model used by LOGO! 8, combined with stale S7 connection metadata stored inside the TIA Portal project.

Affected Hardware and Firmware

Why the Old Project Fails on FS4

LOGO! 8 uses Siemens' functional-state versioning. Each FS level (FS1 through FS4) is a firmware-only update that can change:

• The internal VM (Variable Memory) layout and marker byte ranges
• The S7 communication server defaults (TSAP, slot, max simultaneous connections)
• The network I/O address map and maximum NI/NQ counts
• The LSC project metadata that binds the program to a specific FS descriptor

A TIA Portal project that was commissioned against a LOGO! 8 (FS3) and downloaded into a LOGO! 8 (FS4) compiles and downloads without errors. The S7-1200 keeps the connection up (no fault LED, no diagnostic buffer entry), but the binding layer no longer matches the runtime. The byte offsets the CPU reads from the LOGO! no longer point to the data the LSC program wrote, so every read returns a frozen snapshot from the FS3 layout region that is not used by the FS4 firmware.

The same effect shows up in LSC's online test: the tool reads a valid first frame, then the cyclic polling path hangs because the FS4 firmware returns a different response frame for the legacy read command set that the FS3-bound project still expects.

A brand new TIA + LSC project pair works because it is created against the FS4 device descriptor from the start, so the byte offsets, marker ranges, and TSAPs are aligned by default.

S7 Communication Architecture Between LOGO! 8 and S7-1200

LOGO! 8 FS4 is a passive S7 server. The S7-1200 is the active S7 client. The exchange uses the S7 communication protocol over the PROFINET interface. Two paths exist:

The S7 connection path is the most common in production and the one that carries the migration breakage. The PUT/GET path uses the same S7 transport but stores its parameters in the S7-1200 program code rather than the connection table. The HMI direct path is configured independently in the TIA project and must be rebuilt against the FS4 device descriptor separately.

Connection limits on the LOGO! 8 FS4 side:

• Up to 8 S7 server connections (passive) simultaneously
• Up to 16 S7 client connections (active) simultaneously
• Total active + passive combined cap: 16 S7 connections

VM Memory Layout (FS4 Reference)

LOGO! 8 FS4 exposes its variable memory (VM) as an S7-compatible byte array to the S7 client. The following offsets are the typical FS4 layout. Always verify against the live device using the LOGO! web server (Tools → Diagnostics → VM Memory) because Siemens may revise the layout in minor firmware updates.

For the example cited in the field ("bit M57"): on an FS4 device, M57 lives in marker byte 7 (M56-M63), which is at VM offset VB42 + 1 = VB43. The S7-1200 must read DB1.DBB43 and look at bit 1. A TIA DB mapped to DB1.DBB38 (marker byte 1) would read M8-M15 and show the wrong data, which is what creates the "frozen bit" appearance.

Root Cause Mapping

Step-by-Step Recovery Procedure

The following procedure restores communication in the majority of FS3 to FS4 migration cases without re-engineering the application logic.

Step 1: Confirm the device is actually FS4

1. On the LOGO! HMI, press ESC to reach the main menu.
2. Navigate to Diagnostics → Product Info → Firmware.
3. Confirm the FS field shows 4.
4. Note the firmware build (typical FS4 builds: V1.81.01, V1.81.02, V1.82.01).

If the device shows FS3 or earlier, the migration problem is not FS-related and the investigation must look at IP, TSAP, or wiring instead.

Step 2: Re-select the hardware inside the existing LSC project

Do not start a new project. The ladder or FBD program is forward-compatible across FS levels. Only the device descriptor binding needs to be updated.

1. Open the .lsc file in LOGO! Soft Comfort V8.1 or newer.
2. Go to Tools → Select Hardware (or right-click the device banner at the top of the workspace).
3. Choose the matching 0BA8 FS4 variant for the physical module (LOGO! 12/24RCE, 230RCE, 24CE, etc.).
4. Recompile the project (Ctrl+B).
5. Transfer to the LOGO!: PC → LOGO! (Download).

Step 3: Verify the VM memory layout on the live device

1. Open a browser and connect to the LOGO!'s web server (http://<LOGO!_IP>).
2. Log in (default user: LOGO!, default password: LOGO!; both are case-sensitive).
3. Navigate to Diagnostics → VM Memory.
4. Compare the live byte values at the offsets the TIA project reads against the expected program state.

This is the fastest way to confirm whether the S7-1200 is reading the right bytes. If the web server shows the marker toggling at offset VB43 but TIA shows it stuck at VB38, the S7 connection in TIA is reading the wrong offset and must be rebuilt.

Step 4: Rebuild the S7 connection in TIA Portal

1. In the TIA project, open Devices & Networks.
2. Select the S7-1200 CPU.
3. Right-click and choose Add new connection.
4. Select LOGO! 8 as the partner (not "Unspecific S7 partner").
5. Configure the connection:
   • Partner IP: must match the LOGO!'s current IP. Verify under LOGO! → Setup → Network → IP Address.
   • Partner TSAP: 03.00 (default for LOGO! 8 S7 server, slot 0).
   • Local endpoint: S7-1200 PROFINET interface.
   • Connection resource ID: local.
6. Right-click the connection and choose Compile → Connections.
7. Download the hardware configuration to the S7-1200.

Step 5: Re-map the TIA Portal data block

1. Open the DB that holds the LOGO! data.
2. For each tag, confirm the start address and length match the LOGO! VM layout from Step 3.
3. Delete any absolute addressing that was hand-typed during the original commissioning.
4. Re-assign tags by dragging them from the connection's I/O view (right-click the S7 connection → I/O view).
5. Recompile the S7-1200 program and download.

The most common mapping mistake is offset drift by 1 or 2 bytes. The connection establishes, reads return valid bytes, but those bytes are not the network I/O or marker region the program expects. The result looks exactly like a frozen bit.

Step 6: Re-test online

• TIA Portal: Go online → Monitor All → confirm the DB shows live changes for every mapped tag.
• LSC: Tools → Online Test → confirm I/Q states and timer values update cyclically.
• HMI: Trigger a network input from the panel and confirm the LOGO! program reacts.

Network I/O Configuration (HMI to LOGO! Direct)

The HMI network I/O problem is separate from the S7-1200 monitoring problem. HMI panels (KTP700, KTP1200, Comfort panels) read LOGO! data via the panel's own S7 connection to the LOGO!, not through the S7-1200. The two paths must be configured and re-verified independently.

1. In the TIA project, locate the HMI connection to the LOGO! (Devices & Networks → HMI panel → Connections).
2. Right-click and open Connection properties.
3. Confirm:
   • Partner: LOGO! 8 (not "Unspecific S7" or a cached FS3 descriptor)
   • Partner IP: matches the current LOGO!
   • TSAP: 03.00
4. Recompile the HMI image.
5. Download the HMI image to the panel.

A common failure pattern is that the HMI connection was built against a different LOGO! hardware descriptor in TIA, so the panel's runtime expects a VM layout that does not match the FS4 firmware on the wire. The connection stays up because the panel is reading valid bytes, but those bytes are not the network I/O region.

S7-1200 Firmware-Specific Notes

If the S7-1200 is being upgraded at the same time as the LOGO!, the firmware jump can change how the CPU handles incoming S7 communication. The following notes are the access-protection settings that commonly break an otherwise correct migration:

For general S7-1200 system documentation, see the Siemens Industry Online Support portal at support.industry.siemens.com and search for the S7-1200 system manual entry ID 109772059.

S7-1200 Diagnostic Buffer Codes Relevant to LOGO! Communication

When the S7 connection fails to come up, the S7-1200 diagnostic buffer will typically show one of the following. Match the code to the cause:

Verification Checklist

Run through the following after any FS3 to FS4 migration, or after any S7-1200 firmware update that changes access protection:

Edge Cases and Field-Proven Caveats

1. Same part number, different FS: A LOGO! 8 6ED1052-1MD08-0BA8 can ship as FS3 or FS4 depending on the production date. Always check the FS field, not just the order number on the label.
2. LOGO! Soft Comfort V8.0 cannot program an FS4: The compiler will accept the file, but the download is rejected by the FS4 firmware. Upgrading LSC to V8.1 or newer is mandatory for FS4 work.
3. S7-1200 access protection in V4.4+: New User Management and Access Control (UMAC) settings can block S7 communication that worked in V4.1. Check CPU Properties → Protection → Connection mechanisms.
4. TSAP collision with a second LOGO!: If the network has more than one LOGO!, the default TSAP 03.00 will collide. Use 03.01, 03.02, etc. on the secondary units.
5. Network I/O and S7 connection are independent: Configuring the S7 connection does not automatically configure the network I/O area. Both must be set up in LSC and in TIA.
6. IP address change after FS4 swap: A factory-fresh LOGO! 8 FS4 ships with DHCP enabled. The new IP can differ from the FS3 unit it replaced, and the S7 connection in TIA will silently fail to bind. Always verify the IP after a swap.
7. Web server access disabled by default on FS4: The LOGO! 8 FS4 ships with the web server disabled in some firmware builds. Enable it under Setup → Network → Web Server → Access before relying on it for VM diagnostics.
8. S7-1200 CPU operating mode STOP: If the S7-1200 transitions to STOP after a program download, the S7 connection is torn down and the LOGO! S7 server drops the partner. Bring the CPU back to RUN before testing.

When to Open a Siemens Support Request

Escalate to Siemens Technical Support if:

• All ten verification checks pass but the DB is still frozen
• The LOGO! web server shows a valid VM layout but the S7-1200 reads garbage or all zeros
• The S7-1200 diagnostic buffer shows "Communication fault" with error code 0x8082 or 0x8083 (resource or partner-not-reachable) repeatedly, with no other network devices affected
• Multiple LOGO! 8 FS4 units on the same network all show the same symptom (indicates a network, switch, or VLAN issue, not a per-unit configuration)
• The LOGO! firmware build is newer than what LOGO! Soft Comfort V8.1 supports (rare, but occurs when a new service release ships ahead of the LSC update)

Open the request via the Siemens Industry Online Support portal at support.industry.siemens.com and include the LOGO! firmware build, the LSC version, the S7-1200 article number and firmware version, the S7 diagnostic buffer export, and a screenshot of the TIA S7 connection properties.

Summary

LOGO! 8 FS4 is firmware-compatible with FS3 at the application-logic level, but project metadata, S7 connection defaults, and VM layout are not identical. The migration failure pattern reported in the field (frozen DB bits, frozen LSC online test, dark HMI network inputs) is caused by a TIA + LSC project pair that was commissioned against an FS3 device descriptor and is now running on FS4 firmware. Re-selecting the hardware inside the existing LSC project, rebuilding the S7 connection in TIA, re-mapping the data block to the correct VM offsets, and re-verifying the HMI connection resolves the issue in the majority of cases. Always validate the live VM layout against the LOGO! web server before changing TIA addresses.

FAQ