Resolving LOGO! 8.3 LWE Webpage Not Loading After Download

Problem Overview

Engineers deploying custom web visualization on the Siemens LOGO! 8.3 base module (BM) frequently encounter a situation where a modified LOGO! Web Editor (LWE) project downloads successfully to the controller, but the integrated web server continues to display the previous revision of the page rather than the new one. The LWE runtime on the LOGO! 8.3 stores user-authored HTML, CSS, JavaScript, and image assets on a removable SD(HC) card inserted in the base module, and the controller's HTTP server reads those files at request time. When the page does not refresh after a download, the symptom almost always points to one of four failure paths: (1) browser-side caching of the previous response, (2) read/write faults on the SD card that prevent the new project from landing on the media, (3) stale firmware-state buffers in the base module, or (4) a corrupted LWE project archive that survives the download handshake but cannot be served by the integrated web server.

Field experience across industrial-machine skids, building-automation panels, and small process cells shows that the most common root cause on a hardware-revision-stable site is a degraded SD(HC) card. SD cards have a finite program/erase cycle budget on the raw NAND, and consumer-grade cards in continuous-logger or web-server use cases can fail well before the controller's expected service life. A card that mounts and shows a clean FAT32 directory in the operating system can still fail during the LOGO! 8.3 boot sequence or during the LWE download, leaving the controller serving the previous generation of files from a stale internal buffer or from a partially-written shadow copy.

This article walks through the four-layer diagnostic workflow used to isolate the failing layer, then prescribes the corrective actions in increasing order of invasiveness: browser hard reload, SD card inspection and replacement, factory reset of the base module using the Siemens reset tool, and clean redeployment of the LWE project under a new project name. A verification sequence and a preventive-maintenance checklist close the article.

Affected Hardware and Software

The failure pattern described in this article applies specifically to the LOGO! 8.3 generation of base modules and the LWE toolchain bundled with LOGO! Soft Comfort V8.3 and later (V8.4 and V9.0 are also affected on the same BM hardware). The following table summarizes the affected catalog numbers, the minimum software levels that exhibit the symptom, and the role each component plays in the fault chain.

Refer to the LOGO! 8.3 product manual for the complete catalog-number matrix and to the LOGO! 8.3 system manual / reset-tool FAQ for the LWE toolchain documentation and the reset-tool download.

Runtime Architecture and Where the Fault Lives

Understanding where the fault lives in the LOGO! 8.3 web-server architecture is the difference between a 30-second fix and a full-day investigation. The LWE download is not a flat-file transfer; LOGO! Soft Comfort packages the LWE project as a binary blob with a manifest, the LOGO! transfers the blob to the SD card through the same Ethernet path used for program download, and the controller's web server rebuilds a file index the next time a client opens a session. The four failure modes map to four layers of this stack.

Layer 1 — Browser HTTP Cache

Most modern browsers cache both the index HTML and the static asset graph (CSS, JS, image files) with a Last-Modified or ETag header. After a download, the browser reuses the cached copy if the controller has not bumped the ETag. The user sees the previous page even though the controller is serving the new one. This is the only failure mode in which the LOGO! 8.3 itself is healthy, and the fix lives entirely on the workstation.

Layer 2 — SD Card Wear or Corruption

SD(HC) cards use a Flash Translation Layer (FTL) to map logical sectors to physical NAND pages. When the FTL tables are inconsistent — typically because the card lost power during a write, or because wear-leveling metadata is corrupted — the card can present a clean FAT32 view to a host PC while failing to commit writes from the LOGO! downloader. The new LWE project reaches the card metadata layer but never reaches the file-data blocks, and the previous project remains the only one the web server can serve. This is the failure mode most often diagnosed as "the SD card was defective in some way" on a field site.

Layer 3 — Stale Firmware Buffers

The LOGO! 8.3 firmware holds an in-memory file index that is rebuilt on power-up. If the firmware does not refresh this index after a download (a known behavior on certain LOGO! Soft Comfort V8.3 patch levels with the LWE add-on), the controller continues to serve from the previous in-memory index until a power cycle. This is the failure mode that the factory reset tool clears, because the reset path forces a full re-initialization of the file-system services.

Layer 4 — Project-Archive Corruption

If the LWE project on the engineering workstation has been edited with an external HTML tool that has introduced binary-incompatible characters (BOM markers, line-ending mismatches, or oversized embedded images), the LOGO! Soft Comfort downloader will accept the project, but the LWE runtime on the controller will silently fall back to the previous project. Saving the project under a new name and redeploying forces a fresh archive build and resolves this layer. This is the failure mode that responds to a project rename without any hardware intervention.

Diagnostic Workflow

Run through the following five checks in order. Each check takes less than two minutes and uses only the resources already on the bench. Stop at the first check that fails and move to the matching solution section.

1. Confirm the controller is on the new program revision. Open LOGO! Soft Comfort, connect to the BM in online mode, and read the program header. The version string must match the version of the .lsc file currently open on the workstation. If it does not, repeat the PC → Controller download and observe the status bar for green completion before continuing.
2. Bypass the browser cache. Press Ctrl+Shift+R (Firefox, Chrome, Edge) or Cmd+Shift+R (macOS) to perform a hard reload. If the new page appears, the fault is browser-side and no further action is required beyond clearing the cache. Refer to Mozilla's website-loading troubleshooting guide for the cross-browser cache-clearing sequence, to Microsoft's Q&A on Edge and Chrome page-loading for Edge-specific cache-clearing steps, and to Google Chrome Help on pages not loading for Chrome's site-data management path.
3. Inspect the SD card on a host PC. Power down the LOGO! 8.3 BM, remove the SD card, and mount it in a Windows or Linux workstation. Verify the FAT32 filesystem is clean (chkdsk /f on Windows, fsck.vfat on Linux), and confirm that the LWE project folder contains the expected HTML files with today's modification timestamp. If the timestamp is the previous project, the card is dropping writes.
4. Read the LOGO! 8.3 diagnostic LEDs and the SD-card activity LED. During a download, the SD card activity LED on the BM should pulse steadily. If the LED is dark while LOGO! Soft Comfort reports a successful download, the BM is not writing to the card — a strong indicator of either a defective card or a damaged SD-card socket.
5. Validate the LWE project archive on the workstation. Open the LWE tool inside LOGO! Soft Comfort, click Validate, and resolve every warning. Warnings about image size, HTML structure, or unsupported JavaScript are the leading indicators of Layer-4 corruption.

Troubleshooting Matrix

The matrix below maps the most common field symptoms to the failing layer, the diagnostic step that confirms the layer, and the corrective action. Use it as a quick triage reference during commissioning or service calls.

Solution 1: Browser-Side Remediation

If the diagnostic workflow isolates the fault to the browser cache, no LOGO! hardware intervention is required. Apply the following corrections in order.

1. Open the LOGO! 8.3 web server in a private or incognito window. Private windows disable the persistent HTTP cache, so a successful load in private mode confirms the controller is serving the new page.
2. If the load succeeds in private mode, clear the browser's cache for the controller's IP address. In Chrome, open chrome://settings/siteData, search for the controller's IP, and remove the entry. In Firefox, open about:preferences#privacy, scroll to Cookies and Site Data, click Manage Data, and search for the controller's IP. The Microsoft Edge path is documented in the Microsoft Q&A on Edge and Chrome page-loading, and Chrome-specific steps are in the Google Chrome Help page on pages not loading.
3. Disable HTTP caching for the controller's IP in the workstation's hosts-file override, or assign the controller a fresh IP address from the DHCP server to invalidate every cached entry at once. The latter is the cleanest field fix when the controller is on a managed network and several workstations have the old page cached.
4. Add a Cache-Control: no-store header to the LWE project's index.html as a permanent fix. The LWE tool does not expose a header-control field, so the header must be added by editing the index.html inside the LWE project (in the LOGO! Soft Comfort LWE editor, right-click index.html, choose Edit Source, and prepend the meta tag <meta http-equiv="Cache-Control" content="no-store"> inside the <head> section).

Solution 2: SD Card Inspection and Replacement

If the diagnostic workflow shows that the SD card is dropping writes, replace it with a card that meets the LOGO! 8.3 specification. The following table summarizes the card requirements taken from the LOGO! 8.3 system manual and field-experience notes.

1. Power down the LOGO! 8.3 BM and remove the SD card. Note the card's label date and the BM's last SD-replacement date for the maintenance log.
2. Format the new card with the SD Association's sdformatter tool. The standard Windows format tool sometimes leaves metadata fragments that the LOGO! boot loader rejects, especially on cards larger than 16 GB.
3. Insert the new card into the BM, power up, and confirm the BM's display indicates SD-card recognition (the SD icon appears in the status bar on the BM's display, and the on-board LED labeled "SD" illuminates steadily).
4. Re-download the LOGO! program from LOGO! Soft Comfort. The download will re-create the LWE folder and write the new project to the fresh card.
5. Reload the web page in the browser. The new page should appear immediately. If it does not, proceed to Solution 3.

Solution 3: Reset to Delivery State

If the SD card replacement does not resolve the fault, the base module's firmware state is the next layer to clear. The Siemens reset tool for LOGO! 8.3 restores the BM to its factory-default firmware state, clears the program, the password, the IP configuration, and the LWE index. Use this option only when the previous two solutions have failed, because the reset is destructive and forces a full project redeployment.

1. Download the reset tool from the Siemens Industry Online Support portal (entry ID 109766026 in the FAQ list). The tool runs as a Windows executable and requires a direct Ethernet connection to the BM.
2. Power cycle the BM, then launch the reset tool within the first 30 seconds of boot. The tool detects the BM in the reset window and rewrites the firmware partition. The BM's display shows "RESET" during the operation.
3. After the reset completes, the BM reboots into delivery state. The default IP address on a 6ED1052-1MD08-0BA1 is 192.168.0.10, with subnet mask 255.255.255.0. Configure a host PC in the same subnet to access the BM in online mode. The default Ethernet port is 80 (HTTP) and 8443 (HTTPS, available on firmware 8.3.0 and later).
4. Re-download the LOGO! program and the LWE project. The new page will appear after the first browser reload.
5. Re-apply the site-specific IP address, subnet mask, and gateway. The reset clears all network parameters; the BM will be reachable on 192.168.0.10 until the new address is written back through LOGO! Soft Comfort or through the BM's on-board menu.

Solution 4: Clean LWE Project Redeployment

If the diagnostic workflow shows that the LOGO! is on the new program revision, the SD card is healthy, and the browser cache is clear, the fault is in the LWE project archive. Apply the following clean redeployment sequence.

1. In LOGO! Soft Comfort, open the LWE project, choose File → Save Project As, and save the project under a brand-new name (for example, Pump_Skid_01_v2.lwe). The new name forces LOGO! Soft Comfort to rebuild the binary archive from the current source files rather than copying a previously compiled blob.
2. Validate the project: open the LWE tool, click Validate, and resolve every warning. Pay particular attention to image files larger than 200 KB (compress to WebP or JPEG), to HTML files with absolute paths to the workstation's local disk, and to inline JavaScript that references window.parent (the LWE sandbox does not expose parent-window access).
3. Download the new program and the LWE project to the BM. Observe the download progress bar and confirm a green completion before reloading the browser.
4. Reload the browser. The new page should appear. If it does not, return to Solution 2 and replace the SD card before proceeding to Solution 3.
5. Delete the previous project from the SD card once the new project is verified. Stale projects on the card increase the file count and can interfere with the BM's file-system index in long-running installations.

LOGO! 8.3 SD Card Specification Reference

The following reference table consolidates the SD-card specification from the LOGO! 8.3 system manual and from Siemens Industry Online Support FAQ entry 109766026. Use this table as a field checklist when qualifying a new card.

LED Diagnostic Reference

The LOGO! 8.3 BM has a small set of on-board LEDs that, when read together, narrow the fault to a single layer. The following reference table is derived from the LOGO! 8.3 product manual and from field-validated observation.

Network Configuration Quick Check

When the web server does not load at all — not even the old page — the fault is in the network layer, not in the LWE pipeline. Run the following four checks before assuming an LWE fault.

1. Confirm the BM's IP address. On the BM's display, navigate to Network → IP Address and read the address. Compare it to the address the workstation is using in the browser URL.
2. Ping the BM from the workstation. Open a command prompt and run ping 192.168.0.10 (substitute the BM's address). A response within 5 ms confirms Layer 3 connectivity.
3. Verify the subnet mask and gateway. On the BM, navigate to Network → Subnet Mask and Network → Gateway. The workstation's IP must be in the same subnet. A workstation at 192.168.1.50 cannot reach a BM at 192.168.0.10 with a 255.255.255.0 mask.
4. Check for HTTPS-only enforcement. If the browser is configured to force HTTPS and the BM is on HTTP, the page will fail to load. Try http://<IP>/ explicitly, or, on firmware 8.3.0 and later, switch the BM to HTTPS via the on-board menu and use https://<IP>/.

Verification Procedure

After applying any of the four solutions, run the following verification sequence to confirm the fault is cleared and document the resolution.

1. Open a private or incognito browser window and navigate to http://<LOGO!_IP>/. The new LWE page must load without manual cache intervention.
2. Open a second browser profile (or a different browser entirely) and repeat the load. A clean load across two browser engines confirms the controller is serving the new page rather than the browser serving a cached copy.
3. Trigger a hard reload (Ctrl+Shift+R) on the original browser profile. The page must remain on the new revision. If the page reverts to the old revision after a hard reload, the SD card is dropping writes and Solution 2 must be repeated.
4. Power cycle the BM and repeat the load. A clean load after a power cycle confirms the firmware index is fresh and Solution 3 is not required.
5. Capture a screenshot of the new page from the controller's IP address, archive it with the project's revision number, and attach it to the project's as-built documentation. This step prevents the same fault from being re-investigated on the next revision.
6. Record the SD card's serial number, capacity, and installation date in the maintenance log. A 24-month replacement reminder is the lowest-cost preventive measure.

Preventive Measures and Field-Proven Tips

The following measures reduce the likelihood of a recurrence on a production site and shorten the time-to-resolution on the next service call.

• Use industrial-grade SD cards in any installation where the BM is in continuous service, the ambient temperature exceeds 40 °C, or the site is subject to vibration. Industrial cards have a wider temperature rating and a higher program/erase cycle budget.
• Maintain a one-to-one mapping between the LOGO! program file and the LWE project file in the version-control system. Saving the LWE project under the same name as the .lsc file (for example, Pump_Skid_01.lsc and Pump_Skid_01.lwe) makes the next engineer-investigation faster.
• Avoid editing the LWE HTML directly with an external editor. The LWE tool inside LOGO! Soft Comfort is the only tool that produces a guaranteed-compatible archive. External edits are the most common source of Layer-4 corruption.
• Disable datalog on the SD card if it is not required. Datalog is the single highest wear source on the SD card in continuous service. A site that runs datalog at 1 Hz writes one row per second, which adds up to 31.5 million rows per year — well into the consumer-grade SD card's wear budget.
• Schedule an SD-card replacement every 24 months for installations with datalog enabled, every 36 months otherwise. Track the replacement on a label affixed to the BM's enclosure.
• Document the controller's IP address and the LWE root path on the project's as-built drawing. When the next engineer-investigation is launched at 2 a.m., the documented IP saves the half-hour of subnet discovery.
• Add a Cache-Control: no-store meta tag to the LWE project's index.html to prevent browser caching from masking future LWE download faults. This single change eliminates Layer-1 faults entirely.
• Use a static IP address rather than DHCP for the BM. DHCP leases change, and a renewed IP address is a leading cause of "the page was working yesterday and is broken today" symptoms that have nothing to do with the LWE pipeline.

Frequently Asked Questions