LOGO! Web Editor and Web Server Licensing, Firmware, and Network

Overview

Siemens LOGO! 8.2 logic modules ship with two distinct web-related capabilities that are frequently confused: the firmware-resident LOGO! Web Server and the separately licensed LOGO! Web Editor (LWE) tool. The Web Server is delivered with the device firmware and renders LOGO! status information (or, on newer firmware, custom HTML pages) to any browser pointed at the device IP. The Web Editor is a Windows authoring tool used to lay out those custom pages, including widgets that bind to LOGO! variables, network inputs, and network outputs. This reference consolidates the licensing, firmware matrix, network I/O behavior, and multi-controller data-collection topology that the two pieces support together.

The single most important constraint to understand before commissioning is: each LOGO! can only render its own variables on its own web server. To display values from other LOGO! 8.2 modules on one consolidated dashboard, those values must first be transferred across the Ethernet network using the Network Input (NI) and Network Output (NA) function blocks exposed in LOGO!Soft Comfort V8.2. The Web Editor is then used to bind the receiving LOGO!'s local tags (or its NI-mapped tags) to the dashboard widgets.

LOGO! Web Server vs LOGO! Web Editor

The simple web server shipped with firmware V1.08.xx and V1.81.xx mirrors the LOGO!'s on-device display and any connected LOGO! TDE in the browser. It exposes the virtual cursor keys and a status view. It cannot render custom layouts.

The extended web server introduced with firmware V1.82.xx (LOGO! 8.2 generation) is the surface that the LOGO! Web Editor writes to. It accepts a project archive loaded onto a microSD card and inserted into the LOGO! at runtime. Once the mSD is detected, the LOGO! serves the custom pages instead of the default display mirror.

Firmware Version Matrix and Capabilities

If the custom dashboard requirement is in scope, the LOGO! must be at firmware V1.82.xx or later and identified on the rear label as a LOGO! 8.2 BM/CM. Older 0BA8 devices can be firmware-upgraded through LOGO!Soft Comfort in many cases, but the model variant must support 1.82.xx; consult the device's release for upgrade notes before assuming it is feasible. A device running 1.81.xx cannot load a Web Editor project - the extended server is not present in the firmware.

LOGO! Web Editor Licensing and Part Numbers

The LOGO! Web Editor is licensed separately from LOGO!Soft Comfort. A single-user license is the typical purchase for a programming or commissioning PC. The license is tied to the installation and can be transferred when a PC is re-imaged. There is no per-dashboard or per-runtime license - the LOGO! itself runs the web project from mSD without any license enforcement.

Always cross-check the active ordering data on the Siemens Industry Online Support (SIOS) portal before placing an order; 6ED numbers are stable but the bundle suffix (e.g., -0YA1 vs -0YA2) changes with each major release of LOGO!Soft Comfort.

The full authoring guidance - including widget palette, variable binding syntax, image/asset handling, and project upload workflow - is documented in the official LOGO! Web Editor Online Help hosted on SIOS.

Network I/O: Pull vs Push Topology

Network Input (NI) and Network Output (NA) are the only mechanisms by which one LOGO! can expose a tag to another LOGO! over Ethernet. They map to a small fixed range of virtual registers in the receiving LOGO!. The defaults differ slightly across firmware revisions, so always re-confirm in the LOGO!Soft Comfort block help for the firmware you target.

Push Pattern (recommended for data collector)

1. On each remote LOGO!, place NA blocks for every tag you want exposed. Pick a unique VW/VQ address for each. Record the mapping in a project note (e.g., VW0 = Tank A level, VW2 = Tank B level, VQ0.0 = Pump 1 run).
2. Configure each NA with the IP address of the data collector LOGO! and the target VW/VQ slot on that collector.
3. The data collector LOGO! receives the values into its VM memory at the chosen slots; bind those slots to widgets in the Web Editor project.

Pull Pattern (recommended when remotes are intermittent)

1. On the data collector, place NI blocks pointing at each remote LOGO!'s IP and the specific VW/VQ slot you want to read.
2. NI actively polls; it does not require the remote to know the collector's address. Useful when a remote LOGO! is on a different subnet reachable only through a VPN or NAT.
3. Trade-off: if the remote LOGO! is offline, NI shows the last good value or a configured default. Push (NA) on the remote will simply fail to deliver with no retry queue.

Building a Data Collector LOGO!

The data collector pattern is the canonical way to consolidate values from many LOGO!s onto one dashboard. It is the only way to show values from other LOGO!s on a single Web Editor page, because the extended web server can only render tags that exist inside the hosting LOGO!'s VM.

1. Choose one LOGO! 8.2 with extended web server capability as the collector. It runs the LWE project on its mSD.
2. Assign each remote LOGO! a static IP on the same subnet (or ensure routable addresses across the VPN). The collector must be able to reach each remote on UDP/port 10005 (the LOGO! S7/NI-NA transport port - confirm in your firmware's help).
3. On each remote, program NA blocks that push the relevant values to the collector's IP and to a unique VM slot on the collector.
4. On the collector, write the LWE project. Bind widgets to the collector's VM addresses that the remote NAs are writing into.
5. Insert the mSD containing the project and power-cycle or soft-reset the collector. Verify by browsing to the collector's IP and confirming the dashboard populates.

Address Mapping Worksheet

Keeping this table in the project documentation makes it easy to debug "which LOGO! owns this value" when a widget reads wrong. The collector's Web Editor can be opened in preview mode in LOGO!Soft Comfort to step through the bindings before deploying to mSD.

Extended Web Server Page Design Limits

The extended web server is a small, embedded HTTP engine. It is not a general-purpose browser. Limits to plan around:

• Values per standard display widget: Up to 8 values per default display page. If you need more, use paging - place multiple display blocks in the LOGO! program and switch between them via digital inputs or scheduled logic.
• Custom Web Editor pages: The LWE does not impose a hard count, but the embedded renderer will struggle with very large projects. Keep total asset size (HTML + images + JS) under a few hundred kilobytes and avoid external CDN references - the LOGO! only serves assets stored on the mSD.
• Image formats: JPG and PNG are supported. Prefer compressed JPGs for background art. Use SVG sparingly; rendering performance is browser-dependent.
• Refresh model: The web page polls the LOGO! at an interval configurable in the LWE project (typically 1-5 seconds). Live values faster than 1 Hz require AJAX polling patterns explicitly enabled in the project settings.
• No client-side scripting framework: Avoid importing jQuery, React, or any framework. Use plain JavaScript only; bundle it as part of the project archive on the mSD.

Data Logging and Historical Trends

The LOGO! 8.2 can log any of its local VM tags - including NI/NA-populated slots - to a CSV file on the mSD. This is the only history mechanism on the platform; there is no built-in trend widget in the Web Editor. To chart history, export the CSV and plot externally (Excel, Python, Grafana with the CSV file watcher plugin, etc.).

• Configure the data log block in LOGO!Soft Comfort to record the desired VM addresses at the desired interval (1 s minimum, slower for long-duration logs).
• Filename pattern is fixed by the firmware (typically LOGO_csv.txt on the mSD root).
• Log file rotation is automatic once the configured size cap is reached; back up the mSD periodically if the data is mission-critical.
• The web page itself can include a link to download the CSV if the project includes the proper path-relative URL; otherwise retrieve it directly by removing the mSD and reading it on a PC.

Port Mapping for Multi-LOGO Access

The default web server port on every LOGO! is 80. It cannot be changed in firmware. To access more than one LOGO! across a NAT boundary (e.g., a single public IP from a broadband router), use port mapping on the edge device.

Each LOGO! continues to serve on its internal port 80; the router translates the public-side port to 80 on the destination. This is the standard pattern when no corporate VPN is in use. If you have only one public IP and cannot dedicate distinct external ports, the LOGO! cannot be multiplexed on the same public port; you must use a VPN or a reverse proxy with path-based routing.

VPN and Cross-Network Access

The collector/NA-NI pattern works across a VPN as long as a few constraints are met:

• Fixed IPs on both ends: Each LOGO! must be reachable at a stable address. DHCP across a VPN tunnel is unreliable.
• No double-NAT blocking the S7/NI-NA transport port: The default LOGO! NI/NA transport is UDP/10005 (verify in the firmware help for the exact port and protocol). Both endpoints must permit it.
• Lateral latency tolerance: NI pulls on a poll interval. A 200-500 ms RTT across a continental VPN is acceptable for 1-5 s polling. Sub-second live values will appear choppy.
• MTU: Default Ethernet MTU is fine. If the VPN encapsulates and fragments, raise the tunnel MTU or set the LOGO! to a smaller packet if your router permits.
• DNS not required: Use raw IP addressing in the NA/NI blocks. Resolving LOGO! hostnames across VPN is not supported.

Practical Commissioning Checklist

1. Confirm all LOGO!s are at firmware V1.82.xx or later. Update via LOGO!Soft Comfort if a compatible update is available for each device variant.
2. Assign static IPs to every LOGO! and to the collector. Document the address map.
3. Install LOGO! Web Editor license on the commissioning PC; confirm activation.
4. Program each remote LOGO! with NA blocks pushing required tags to the collector's VM slots.
5. Program the collector with NI blocks for any remote values you prefer to pull rather than receive as push.
6. Author the LWE project on the commissioning PC. Bind widgets to the collector's VM slots that are now populated by NI/NA.
7. Export the LWE project to the mSD, insert the mSD into the collector, and power-cycle.
8. From a PC on the same subnet, browse to the collector's IP and verify each widget populates. Cross-check against the live values on the remote LOGO! displays.
9. Configure port mapping on the edge router or set up the VPN. Verify external access by browsing the public URL.
10. Configure data logging on the collector for any tags that need history. Verify CSV file growth on the mSD.

Specifications and Limits

FAQ