Resolving LOGO! Web Editor Variable Not Updating on Extended Web

1. Problem Statement

Engineers deploying a Siemens LOGO! 12/24RCEo (0BA8 platform) for Modbus-based gas detection telemetry — for example, polling a Drager Regard 3900 multi-channel controller — frequently encounter a symptom where the LOGO! internal I/O status screen and the LOGO!Soft Comfort online test display the correct live analog values, but the custom page generated by LOGO! Web Editor (LWE) shows stale or zeroed variables when accessed through the extended web server (EWS). Inputs from the field are present, the Modbus transaction is succeeding, and the analog math (AM) function blocks compute valid results, yet the browser never reflects the latest reading.

The root cause is typically a mismatch between the LWE project version, the LOGO! firmware, and the way variable memory (VM) addresses are mapped in the LWE variable table. A version upgrade of the LWE tool (e.g., from v1.1 to v1.2) is often the only required change to make the extended web server re-read VM data and push it to the browser.

2. Affected Hardware, Firmware, and Software

The following components are confirmed to be involved in this fault class:

The 12/24RCEo part number is a LOGO! 8 (0BA8) device. Confusion sometimes arises because the legacy 0BA1 designation was the first-generation LOGO! released in 1996; the 0BA8 designation refers to the eighth-generation platform with the integrated web server. Always confirm the exact hardware generation by reading the part number on the side label, not by generation index.

3. Root Cause: LWE v1.1 vs. v1.2 Project File Compatibility

The LWE tool generates a bundled web project that is uploaded to the LOGO! extended web server. The project includes HTML, CSS, JavaScript, and a tag list that binds display elements to LOGO! variable memory addresses. When the project is deployed, the LOGO! EWS serves these files and the embedded JavaScript polls the LOGO! for VM updates at a fixed interval (typically 1 s, configurable in the LWE project properties).

The fault mode observed in the field is:

1. Project created with LWE v1.1.
2. Project deployed successfully to the LOGO! EWS.
3. Browser opens the project URL and renders the layout.
4. VM tags remain at the initial value (often 0) and do not update, even though the LOGO! program, I/O status, and online test all show the correct values.
5. Upgrading to LWE v1.2, redeploying the same logical project, restores the live update.

This indicates that LWE v1.1 emits a project bundle whose JavaScript refresh logic does not correctly negotiate the EWS variable read API on firmware 8.3/8.4. LWE v1.2 re-emits the project with corrected refresh handlers, restoring the polling cycle without any change to the underlying LOGO! program, Modbus mapping, or VM address assignments.

4. LOGO! Variable Memory (VM) and Analog Math (AM) Block Behavior

To understand why the displayed values can be zero even when the LOGO! program is computing correctly, it is necessary to understand how the Analog Math function block reports its output and how the I/O status display differs from the EWS-visible VM address space.

4.1 The AM Function Block

The Analog Math (AM) function block in LOGO!Soft Comfort takes two operand inputs and a mathematical operator and produces a single analog result. Typical uses include scaling (multiply by gain, divide by 1000) and linearization of sensor curves. The result of an AM block is exposed in the variable memory at the address assigned when the block is parameterized in the FBD/LAD editor.

4.2 Observed Calculation Behavior

In the fault report, the user observed four AM blocks (AM1 through AM4) with the following calculation pattern, where B002, B003, B018, B019, B034, B035, B050, B051 are operand VM addresses:

The LOGO! AM block truncates the fractional portion of the result (rounding down toward zero) when the destination variable is an integer type. AM2 yields 5, not 5.48. This is correct LOGO! behavior and is not a fault.

4.3 Why AM2 Appears to Not Update on the Web Page

Even when AM2 is correctly calculating 5 in the LOGO! program, the LWE v1.1-deployed project may fail to push that update to the browser because of the version-specific JavaScript refresh defect described in Section 3. The fix is to upgrade LWE and redeploy. The calculation logic, the operand mapping, and the I/O status remain correct throughout.

5. Step-by-Step Resolution Procedure

The following procedure resolves the LWE-deployed variable not updating on the EWS.

5.1 Prerequisites

• PC with LOGO!Soft Comfort 8.3 or later installed.
• LWE v1.2 (or the latest available LWE version matching the LOGO! firmware family).
• Ethernet connection between the PC and the LOGO! 12/24RCEo.
• The existing LWE project file (.lwe) or the original LOGO! program (.lsc) from which the LWE project was generated.
• Read/write access to the LOGO! web server (Tools → Web Server Access in LOGO!Soft Comfort).

5.2 Procedure

1. Confirm LOGO! firmware and program state. In LOGO!Soft Comfort, connect online (Tools → PC ↔ LOGO! → Connect). Open the I/O Status window and verify that the AM outputs (AM1–AM4) reflect the expected scaled values. Record the live values for comparison after redeploy.
2. Export the LWE project. In the original LWE v1.1 instance, open the project and export the LWE project archive so that all variable bindings and layout are preserved.
3. Install LWE v1.2. Download the LWE v1.2 installer from the Siemens LOGO! support page and install. Do not uninstall v1.1 first; the v1.2 installer handles version migration. Restart the PC after installation.
4. Open the project in LWE v1.2. Launch LWE v1.2 and open the project. The tool will prompt to upgrade the project format. Accept the upgrade; the variable bindings, layout, and tag list are migrated automatically.
5. Re-validate variable bindings. Open the Variable Table in LWE v1.2 and confirm that each display element is bound to the correct VM address. Cross-reference with the LOGO! program block addresses (B002, B003, etc.) and the AM output addresses (AM1, AM2, etc.).
6. Compile the project. Use the LWE → Compile menu to regenerate the web project bundle. Watch for any compile warnings about deprecated tag formats or unsupported VM ranges.
7. Deploy to the LOGO!. In LWE v1.2, select Web → Deploy. Enter the LOGO! IP address and the web server access credentials. Wait for the deployment to complete. The LOGO! will restart the EWS automatically.
8. Clear the browser cache. On the client PC, clear the browser cache and cookies for the LOGO! IP address, or use a private/incognito browsing window. This forces the browser to download the freshly deployed project bundle rather than serving the cached v1.1-generated files.
9. Re-test the web page. Open http://<logo-ip>/<project-name> in the browser. Verify that the values update at the configured refresh interval (default 1 s). The previously stuck AM2 should now reflect 5 (or whatever the live truncated value is).

6. Verification and Commissioning Checks

After redeploying the LWE v1.2 project, perform the following checks to confirm correct operation:

• Initial render check. The web page should load without JavaScript errors. Open the browser developer console (F12) and confirm there are no 404s for project assets and no JavaScript exceptions.
• Variable update check. Trigger a known state change in the LOGO! program (e.g., force a Modbus register to a new value using the Drager Regard 3900 service tool, or toggle a digital input mapped to a relevant calculation). Confirm that the web page updates within the configured refresh interval.
• Network round-trip check. In the browser developer console, observe the network tab for requests to /<project>/vmread or equivalent EWS endpoints. The requests should occur at the configured cadence and return HTTP 200 with a JSON or text payload containing the latest VM values.
• Multi-client check. Open the web page on a second client device (phone, tablet) and confirm that both clients see consistent values. This rules out per-client caching defects.
• Endurance check. Leave the web page open for at least 10 minutes. Some LWE deployment defects manifest as refreshes that fail after a long uptime due to memory leaks in the EWS CGI handler.

7. Modbus Integration with Drager Regard 3900

The Drager Regard 3900 is a multi-channel gas detection controller that exposes gas concentration data, alarm status, and device health over Modbus RTU (RS-485) and Modbus TCP/IP. When integrating with a LOGO! 12/24RCEo, the typical architecture is:

• Drager Regard 3900 → Modbus TCP → LOGO! 12/24RCEo (Modbus client/master) → LOGO! variable memory → LWE display.

The LOGO! acts as a Modbus client using the Modbus TCP master capability available in the LOGO! 8 (0BA8) base module with the appropriate function block. The polled registers are placed into VM addresses, which are then read by the LWE project.

7.1 Common Modbus Register Map for Regard 3900

While the exact register map is documented in the Drager Regard 3900 Modbus interface manual, the typical data structure includes holding registers for gas concentration, engineering units, alarm thresholds, and device status. The LOGO! Modbus client block reads these registers on a configurable poll interval and stores the results in consecutive VM addresses.

7.2 Scaling Considerations

Gas concentration values from the Drager are typically returned as 16-bit integers representing 0–100 % LEL, 0–5000 ppm, or 0–25 %Vol depending on the sensor type. Use the AM block to scale the raw register value to engineering units before displaying. For example:

• Raw register value × 100 / 1000 = % LEL (0–100 scaled to 0–10 if needed).
• Raw register value ÷ 10 = ppm in 0.1 ppm resolution.

Apply the same truncation rule described in Section 4.2 when the destination variable is integer.

8. Browser, Cache, and Network Considerations

Even after a successful LWE v1.2 redeploy, the browser may continue to serve the old project bundle from cache. This produces the false impression that the redeploy failed. The following mitigations apply:

• Hard refresh. Press Ctrl+F5 (Windows/Linux) or Cmd+Shift+R (macOS) to force a reload bypassing the cache.
• Cache disable during commissioning. Open the browser developer tools, navigate to the Network tab, and check "Disable cache" while the developer tools are open. This prevents the browser from caching any project assets during the commissioning phase.
• Service Worker inspection. Some LWE versions register a service worker for offline operation. Clear the service worker from the browser (Application tab → Service Workers → Unregister) to ensure the new project bundle is loaded.
• Cookie and storage clear. Clear site-specific cookies and local storage for the LOGO! IP. The LWE JavaScript may use local storage to cache tag values between page loads.
• Proxy and corporate cache. If the client PC is behind a corporate proxy or web filter, the proxy may cache the project bundle. Configure the proxy to bypass the LOGO! IP, or use a direct network connection during commissioning.

9. Firmware and Software Compatibility Matrix

The following matrix summarizes the observed compatibility between LOGO! firmware, LWE version, and EWS variable refresh behavior. Always verify against the latest Siemens product documentation before deploying in production.

For full product specifications and the latest compatibility information, consult the official Siemens LOGO! 8 system manual and the Siemens LOGO! product page.

10. Troubleshooting Decision Matrix

Use the following matrix to triage the symptom of EWS variables not updating. The matrix is derived from the field experience of the LWE v1.1 fault and adjacent defect classes.

11. Best Practices for LWE Projects

The following best practices reduce the risk of encountering the variable not updating fault and adjacent defects:

1. Pin LWE version to firmware. Document the LWE version used for each deployed project. When upgrading LOGO! firmware, review the LWE release notes and re-validate the project before redeployment.
2. Use a unique project name per firmware. LWE allows multiple web projects to coexist on the LOGO!. Use names that include the firmware and LWE version (e.g., gas_panel_fw83_lwe12) to make rollbacks and A/B testing straightforward.
3. Minimize refresh frequency. The default 1 s refresh is appropriate for process monitoring. For trend displays or non-critical readouts, extend the refresh interval to 2–5 s to reduce EWS load.
4. Validate in LOGO!Soft Comfort online test first. Always confirm the LOGO! program, AM blocks, and Modbus mapping in the online test before opening LWE. This isolates LWE-specific defects from program defects.
5. Maintain a deployment log. Record the LWE version, LOGO! firmware, project file hash, and deployment date for every project change. This is invaluable for regression analysis when a fault appears.
6. Test from a clean browser profile. During commissioning, use a private browsing window or a clean browser profile to eliminate cached assets from prior deployments.
7. Reserve at least 1 MB of free EWS storage. The LOGO! 8 (0BA8) has limited internal storage for web projects. Large projects with many high-resolution images can exhaust the storage and cause silent deployment failures that present as variable refresh issues.
8. Avoid mixing LWE versions across a fleet. Standardize on a single LWE version across all deployed LOGO! 8 controllers in a facility to simplify maintenance and reduce cross-controller debugging complexity.

12. Frequently Asked Questions