Configuring LOGO! Web Editor Weekly Timer Time Input

Overview

The Siemens LOGO! 8 base module (BM) exposes an integrated Web Server that is populated and styled through the LOGO! Web Editor (LWE) tool inside LOGO! Soft Comfort (LSC). Operators can monitor and modify function block parameters from any browser, but Weekly Timer on/off times are not exposed as plain decimal hours and minutes. They live inside the LOGO! VM (Variable Memory) image as raw byte values that the editor renders in hexadecimal form. This article documents the exact VM layout, the two recommended LWE display approaches (Scaled Time vs. raw hex), and the field-proven workarounds for the well-known "16#" prefix issue and the apparent "value bouncing" symptom that occurs on browsers when read-only fields refresh every 2 to 3 seconds.

The workflow described here is valid for the LOGO! 8 generation (order numbers 6ED1052-1MD08-0BA1, 6ED1052-1HB08-0BA1, 6ED1052-1FB08-0BA1, 6ED1052-1CC08-0BA1, and the -0BA2 ES4/ES5 successors), LSC V8.3.0 (6AV2101-0AA05-0AA5), LWE V1.0.1 and the converted V1.1.0 project format, and LOGO! BM firmware 1.82.01. Newer LSC V8.4 / V9.0 projects use the same VM layout; the techniques scale to every Weekly Timer with up to three cams (older) or eight cams (newer blocks).

Prerequisites

Confirm the following before starting:

• LOGO! 8 base module with Web Server license active (default enabled on -0BA2 hardware). The Web Server option must be checked in Tools > Options > Web Access inside LSC.
• LOGO! Soft Comfort V8.3.0 or newer installed on the engineering PC. The LWE plug-in is bundled with LSC and is launched from Tools > LOGO! Web Editor.
• LWE V1.0.1 projects auto-convert to V1.1.0 on first save. V1.1.0 introduced the Scaled Time element that supersedes the manual hex-pair trick used in V1.0.1.
• LOGO! BM firmware ≥ 1.82.01 (display under Online > Diagnostics). Earlier firmware 0BA1 versions (1.80.x) have a smaller Parameter VM window and cannot expose all weekly timer cams.
• The LOGO! project contains at least one Weekly Timer block (B001) and that block has been parameterized with a base address in the Parameter VM area (default auto-allocation is sufficient).

Weekly Timer Parameter VM Layout

Each Weekly Timer block stores its parameter set inside the LOGO! Parameter VM. The mapping is fixed by the LOGO! firmware and is identical across all 8-series BMs. The address range that LSC reports under Tools > Parameter VM Mapping is the authoritative source; the byte layout below assumes B001 is the first Weekly Timer in the program.

Each weekly timer occupies 15 contiguous bytes of Parameter VM space. If the program contains a second Weekly Timer block (B002), it starts at offset +15 from the first one. The byte layout was introduced in LOGO! firmware 1.80.01 and has not changed through 1.82.01 and the current 1.83.x release.

Locating the Base Address in LSC

1. Open the LSC project and switch to Diagram Editor.
2. Click the Weekly Timer block (B001) to select it.
3. Open Tools > Parameter VM Mapping. LSC lists every function block that has parameter VM storage along with its start address.
4. Record the start address for the Weekly Timer. Assume the value 1024 (decimal) for the worked example below; substitute your real value in production.

Approach 1 – Scaled Time Elements (LWE V1.1.0)

The Scaled Time element added in LWE V1.1.0 is the recommended method for any new project. It accepts hours and minutes as integer values, applies a divisor and offset, and writes a single byte to a Parameter VM location. Use two Scaled Time elements per cam (one for on, one for off) if you want independent hour/minute entry, or a single combined element if the operator only edits one of the two times.

Adding the element

1. Open Tools > LOGO! Web Editor from LSC.
2. Drag a Scaled Time element onto the workspace. Its configuration dialog opens.
3. Set Source VM address to the byte that holds the hour or minute you want to edit (for example, 1025 for Cam 1 on-hour).
4. Set Read divisor and Write divisor to 1. No scaling is needed because the VM byte is already in 0-23 or 0-59 units.
5. Set Read offset and Write offset to 0.
6. Set Display format to DEC.
7. Set Min to 0 and Max to 23 for hour fields or 59 for minute fields.
8. Set Label to a meaningful string such as Cam 1 On Hour and click OK.
9. Repeat steps 2-7 for the On minute, Off hour, and Off minute fields. Use addresses 1026, 1027, and 1028 respectively for Cam 1.

Linking to the Weekly Timer block

The Scaled Time element writes directly to the VM byte the firmware uses to drive the cam. Once the user changes the value in the browser and presses Apply, the BM updates the parameter image, the next scan cycle re-evaluates the cam, and the new schedule takes effect immediately. No additional program logic is required.

Approach 2 – Hex I/O Fields (LWE V1.0.1 / V1.1.0)

Older LWE V1.0.1 projects and projects that need the lowest possible screen footprint use raw Hex I/O fields. The approach is identical to the Scaled Time method except the display format is set to HEX, and the operator must enter the value as a hex literal. This is where the "16#" prefix appears in the browser – it is the IEC 61131-3 hex literal marker that LWE prepends when the byte value exceeds 9.

Hex I/O configuration

1. Drag an Analog I/O field onto the workspace.
2. Set VM address to the cam time byte.
3. Set Display format to HEX.
4. Set Length to 1 byte.
5. Leave Min at 0 and Max at 255 if you want the operator to enter any byte; otherwise set Max to 23 or 59 to clamp the value.

Conversion references for the operator (or for hard-coding default values during commissioning):

For values ≥ 10 (decimal), the browser shows the literal as 16#0A, 16#17, 16#3B, etc. This is documented in the LOGO! Soft Comfort online help under Web Editor > Display formats > Hex and is a cosmetic rendering issue only; the underlying value written to VM is still the raw byte.

Troubleshooting: The "Value Bouncing" Symptom

A frequent field report describes a behavior where the time value in the browser appears to revert to a stale value 2 to 3 seconds after the operator changes it, while the LOGO! itself continues to honor the new schedule. The root cause is that the LOGO! Web Server reads Parameter VM at scan time but only refreshes the browser-displayed value when the BM re-publishes the page. Because the Web Server pushes a snapshot every 2 to 3 seconds, an edit that lands between two snapshots is overwritten on the next snapshot by the previously committed value.

Root cause analysis

1. Operator enters 14 in the On-hour field and presses Apply. The browser POSTs the value to the BM.
2. The BM writes 14 into the parameter VM byte and re-evaluates the Weekly Timer cam. The cam turns on at 14:00 as expected.
3. The BM has not yet republished the page, so the next polling refresh (~2 s later) re-reads parameter VM from a buffer that still holds the old snapshot if the BM is under heavy scan load.
4. The browser shows 6 (the previous hour) even though the BM is correctly executing the new schedule.

Resolution

• Verify that the BM firmware is at least 1.82.01; firmware below 1.80.01 has a known parameter VM caching bug that magnifies the bouncing symptom.
• Reduce the number of Web Editor pages the BM has to republish. Combine multiple cams on a single page rather than splitting them across tabs.
• Avoid editing the Weekly Timer while the BM is servicing an FTP transfer or Ethernet/IP I/O update; the polling refresh is suppressed during heavy traffic and the snapshot can lag by more than 10 seconds.
• If the visual bouncing remains unacceptable, force the operator to use a confirmation step (e.g., a "Reload page" button on the LWE canvas) so they always see the post-write state.

Commissioning Procedure

1. Download the LSC program to the BM and start it. Verify the BM runs the program without errors by checking Online > Diagnostics > Status.
2. Launch LWE and confirm the project converts cleanly to V1.1.0 if it was originally saved as V1.0.1. A clean conversion means LWE will accept the new Scaled Time elements.
3. Upload the LWE project to the BM via Tools > Transfer > Web Project to LOGO!. The transfer takes 20 to 60 seconds depending on project size.
4. Open a browser to http://<logo-ip> and authenticate if a password was configured under Web Access > Password.
5. For each Scaled Time / Hex I/O field, enter a known time, press Apply, then verify on the LOGO! display or via the LOGO! app that the cam schedule updated.
6. Set the BM clock under Setup > Clock if NTP is not available; the Weekly Timer evaluates against the BM's local RTC, not the browser PC clock.
7. Document the VM base address of each Weekly Timer in the project README so future maintenance does not have to re-derive the offsets.

Edge Cases and Field-Proven Caveats

• Day-of-week mask: The day-of-week byte for a cam uses bit-mask semantics (Mon = 0x01, Tue = 0x02, …, Sun = 0x40, all days = 0xFF). Entering 16#20 selects Saturday only; 16#3F selects weekdays; 16#41 selects Monday plus Sunday. The LOGO! onboard editor masks this as 1-7 / "Mo-Su" but the web editor exposes the raw byte.
• Out-of-range clamping: LWE does not clamp values to the 0-23 / 0-59 range by default. An entry of 30 in the hour field writes 30 to VM, the cam never fires (hour 30 does not exist), and no error is raised. Always set the Scaled Time Max parameter to 23 or 59.
• Cam enable byte: If the Weekly Timer block was set up with "No cams" or with disabled cams in LSC, the corresponding VM bytes still exist but are not used by the firmware. Writing to them has no effect.
• Consecutive timers: Two Weekly Timer blocks do not share VM offsets; B002 starts where B001 ends. If the operator edits B002 offsets from the B001 page layout, the edits silently land on the wrong timer. Verify the base address in Parameter VM Mapping after every program change.
• Browser caching: Chrome and Edge aggressively cache the LWE page. After uploading a new LWE project, hard-reload the browser (Ctrl+Shift+R) to clear the cached HTML.
• Mobile browsers: The Scaled Time input field on iOS Safari re-validates on every keystroke. If Max is set to 23, typing 2 first is accepted, then 23 is accepted, but intermediate state 2 triggers a transient invalid-style highlight. This is cosmetic; the value still commits on Apply.

Verification Matrix

FAQ