Calculating LOGO! Weekly Timer Period Duration in Minutes

The Siemens LOGO! 8 logic module (6ED1052-1xx08-0BAx) ships with up to nine Weekly Timer function blocks per program. On firmware 0BA8 standard each block supports three cams, and from firmware 0BA8.3 (FS:04) onward, four cams are available. Every cam combines a Day-of-Week mask, an ON time (hour:minute) and an OFF time (hour:minute), and produces a single Boolean output that is high while the real-time clock sits inside the configured window. The full LOGO! 8 system manual is published on the Siemens Industry Online Support portal at Siemens LOGO! 8 system manual, entry ID 109757547, and the product family page is at siemens.com/logo.

For a lighting, irrigation, or process control application that is satisfied with a digital on/off decision, that Boolean output is the entire answer. For any application that needs the configured window length, however, the Weekly Timer is silent. The block has no analog output for elapsed minutes, no remaining-minutes tag, and no duration register. If the program is going to display "Period: 12:00 → 13:01 (61 min)" on an HMI, or scale a dosing rate by the fraction of the period that has already elapsed, the value must be reconstructed by reading the parameter table.

This article documents the deterministic, low-block-count procedure for extracting the active period length in minutes from a LOGO! Weekly Timer. It explains why the parameters are stored in BCD, walks through the Parameter-VM-Mapping setup that exposes them to user logic, and shows the math block wiring that converts two packed BCD words into a single integer in the range 0-1439 minutes. It also covers the wrap-around case (a period that crosses midnight), and the architectural decisions required to keep block count reasonable when scaling to nine timers.

1. Problem Definition

The requirement is: given a Weekly Timer cam with an ON time of T_on and an OFF time of T_off, both expressed in 24-hour clock time, compute the integer number of minutes between them before the period expires. The worked example is 12:00 → 13:01, which is 61 minutes. A second requirement is to keep the function-block count manageable when the program contains many weekly timers: nine weekly timers, each with two active cams, totals 18 timer instances and a strong incentive to avoid stacking a separate BCD decoder on every instance.

Two failure modes are common in ad-hoc implementations:

• Using a TON (on-delay) or pulse timer to measure the cam output in real time. This works only while the output is high and cannot return the total configured period at programming time or before the window opens.
• Reading the Weekly Timer parameter as a single 32-bit integer. The parameter is BCD-packed, so the integer is meaningless until each nibble is split.

Both failure modes are avoided by reading the raw parameter, decoding the BCD, and computing the difference in minutes with the same arithmetic that an engineering calculator would use.

2. Why the Weekly Timer Has No Built-in Duration Output

The Weekly Timer is implemented as a comparator: each evaluation tick, the firmware reads the real-time clock, masks off the seconds, and checks whether the resulting DOW/hour/minute falls inside any configured cam. The Boolean OR of all cam match results is exposed on the block output. The cam's ON and OFF values are stored as configuration parameters, not as runtime state, and the firmware does not retain a duration intermediate.

This is a deliberate design choice. Weekly Timers are typically used for slow on/off decisions, and the LOGO! 8 kernel is sized for roughly 400 function blocks, 250 of which can be SF (special functions) including timers. A timer that exposed elapsed/remaining duration as analog tags would need two additional outputs per cam and would consume block memory even in programs that never use the value. By contrast, the Parameter-VM-Mapping feature exposes the raw cam parameters on demand, and the user program decodes them only when the value is actually required.

The trade-off is that the user pays the decoding cost only for the cams that need the duration, which is the right economic model for the kind of program described in the source material.

3. Prerequisites

4. BCD Encoding of Weekly Timer Parameters

Every Weekly Timer cam carries five user-editable parameters:

1. Day-of-Week mask (Mo, Tu, We, Th, Fr, Sa, Su — any combination)
2. ON time (Hour 0-23, Minute 0-59)
3. OFF time (Hour 0-23, Minute 0-59)
4. Start date (optional, for yearly-window cams)
5. End date (optional)

When Parameter-VM-Mapping is enabled, each parameter is written to a 16-bit VM word in BCD. BCD (Binary-Coded Decimal) stores each decimal digit in a 4-bit nibble, so the byte 0x59 is interpreted as decimal 59, not as decimal 89. The reason the source thread observes "4 numbers in one word" is that the four fields (DOW bitmap + ON hour + ON minute, and a separate word for OFF hour + OFF minute) are all small decimal values that fit cleanly into BCD nibbles.

The packing scheme for a single cam, high byte to low byte, is:

The DOW mask is exposed as a separate VM word; on LOGO! 0BA8 it is a bitmap with bit 0 = Mo ... bit 6 = Su. For the duration calculation in this article the DOW mask is not required.

4.1 BCD → Decimal Conversion Rule

For a byte holding BCD value B:

decimal_value = (B AND 0xF0) SHR 4 * 10  +  (B AND 0x0F)

Because LOGO! function block diagram does not expose bitwise AND and SHR as discrete operators on the older FBD, the same operation is implemented with the analog Math block, which accepts a free-form expression in LOGO!Soft Comfort V8.2+ and returns the integer result on its analog output.

5. VM Address Map and Parameter-VM-Mapping Setup

LOGO! 8 reserves the VM area from VB0 to VB850 (851 bytes) for the user. The Parameter-VM-Mapping table sits in the LOGO!Soft Comfort editor under Tools → Parameter VM Mapping (or, equivalently, the mapping tab in the block properties dialog). Each row of the table binds one parameter of one block to one VM word.

For a single cam that needs duration readout, the recommended mapping is:

Choosing a non-overlapping range such as VW100-VW102 keeps the program readable and avoids collisions with the LOGO! internal parameter table, which lives at the bottom of the VM area. The source material confirms that "the VM addresses are free selectable" and that "the user can use in a LOGO! diagram the area from VB0 till VB850", which is the documented contract.

After downloading the program to the LOGO!, the two words update in real time whenever the cam parameters are changed from the LOGO!'s onboard display or from LOGO!Soft Comfort in online mode. This means the duration value stays correct even if the operator edits the timer setpoints from the HMI.

6. Step-by-Step: Decoding ON and OFF to Decimal Hours and Minutes

The decode path for one cam requires three Math blocks per cam if implemented as separate stages (a total of 6 Math blocks for ON+OFF), or one consolidated Math block if the LOGO!Soft Comfort V8.2+ expression mode is used. The four logical steps are:

1. Read VW100 (Time On) — a word that contains the BCD-packed hour and minute.
2. Decode high byte → hour_on; decode low byte → min_on.
3. Convert both to a single minute count: mon = houron × 60 + minon.
4. Repeat for VW102 → m_off.

The Math block in LOGO!Soft Comfort V8.2 and later accepts a formula on its EQ/EX pins and returns the integer result. The expression for the high-byte decode is:

EX  =  ((VW100 >> 8) AND 0x0F) * 10
    +  ((VW100 >> 8) AND 0xF0) SHR 4

For the low-byte decode:

EX  =  (VW100 AND 0x0F) * 10
    +  (VW100 AND 0xF0) SHR 4

Note that the BCD-to-decimal conversion is symmetric — the high nibble of the BCD byte contributes tens, the low nibble contributes units. Once the four fields (hour_on, min_on, hour_off, min_off) are integer decimals, the duration in minutes is:

duration_minutes  =  (hour_off * 60 + min_off)
                  -  (hour_on  * 60 + min_on)

7. Computing Elapsed Minutes

The duration value computed in §6 is the configured window length, available at all times. The elapsed minutes inside the current window are computed differently: the program detects the rising edge of the Weekly Timer output, then integrates a free-running base-clock pulse (typically 1 minute from the internal seconds counter) into a counter that resets on the falling edge. This pattern uses the Hours Counter block (SF) or the Up/Down Counter (SF) and does not require the BCD decode at all. The two values, "configured period" and "elapsed", are independent outputs that both feed the downstream calculation.

If the requirement is "elapsed minutes before the period finishes so that a soft-stop can be triggered", the BCD decode in §6 yields the remaining value via:

remaining_minutes  =  (hour_off * 60 + min_off)
                    -  (current_hour * 60 + current_minute)

The current RTC value is read by mapping the LOGO!'s internal real-time clock to a VM word, or, more commonly, by using a second Weekly Timer (or any SF) as a ticker that pulses on the minute boundary. The source thread's wording — "before the period is finish, so I cant use a timer and a counter" — matches this remaining-time pattern, not the elapsed-time pattern.

8. Handling Periods That Cross Midnight

If the cam is configured as 22:00 → 06:00, the raw subtraction (6×60 + 0) − (22×60 + 0) = −1200 is meaningless. The correction is a wrap-around add of one day (1440 minutes) when the off-time word is less than the on-time word:

if (m_off < m_on) then
    m_off = m_off + 1440
end
duration_minutes = m_off - m_on

In LOGO! function block wiring, the same comparison is built with an Analog Comparator (SF) on the two decoded minute totals, an analog multiplexer to add 1440 (constant block, value 1440) to m_off when the comparator trips, and the Math block to perform the final subtraction. Three blocks per cam is a typical implementation footprint for the wrap-around path.

A special case: a cam whose ON and OFF times are identical (e.g., 12:00 → 12:00) is interpreted by the LOGO! kernel as a 24-hour window, not zero minutes. The procedure above yields 0; if 1440 is required, the user must detect the equality separately and substitute the constant 1440. This edge case is rare in practice but should be covered by the verification test plan.

9. Reducing Block Count for Many Weekly Timers

The source concern — "9 weekly timers, with 2 cam in, that is 18 total, I think it is too many blocks" — is valid. The naive one-decoder-per-cam architecture consumes 6 Math blocks per cam, or 108 Math blocks for 18 cams, which exceeds the LOGO! 8 SF budget. Three techniques keep the count manageable.

9.1 Multiplex the decoder. Place the BCD-decode Math block in the program once, drive its inputs from an Analog Multiplexer (SF) that selects VW100 + 2×cam_index, and clock the multiplexer through the same trigger that selects which cam is "active" downstream. This reduces the per-cam cost to one multiplexer input, not one full decoder. The downside is that the duration is computed for one cam at a time, which is acceptable for the soft-stop / remaining-time use case because the active cam is, by definition, the one with the rising-edge output.

9.2 Use the Hours Counter (SF) and skip the decode entirely. The Hours Counter accumulates the time its input is high. If the Weekly Timer output is wired to the Hours Counter enable input and reset on the falling edge, the accumulated value at any moment is the elapsed seconds-or-minutes in the current window — exactly the "elapsed minutes" quantity from §7 — without any BCD decoding. The trade-off is that the value is only valid after the cam has fired, not before; the procedure in §6 is required if the configured period must be known before the window opens.

9.3 Split the program across slave LOGO! modules. The LOGO! 8 supports LOGO! → LOGO! communication over Ethernet, which allows a master LOGO! to read block parameters from up to eight slaves. Mapping 9 weekly timers onto 2 LOGO! 8 base modules (5 cams on the master, 4 on the slave) cuts the per-module SF budget in half. This option is rarely worth the hardware cost for a 9-timer program, but it is worth knowing for 20+ timer programs.

9.4 Exploit parameter VM mapping sharing. The source thread observes that "it is only 6 of them I use at the same time". A practical optimization is to map only the 6 active cams to VM and to leave the remaining 12 cams unmapped, then use an Analog Multiplexer with a cam-select input to pick the active one. This saves 12 of the 18 parameter mapping slots and 72 Math blocks if naively deployed.

10. Verification Procedure

1. Static check in LOGO!Soft Comfort simulation. Open the simulation, set the LOGO! internal clock to 11:59:00, force Weekly Timer B001 to 12:00 → 13:01, and step the clock forward one minute at a time. Verify the decoded duration word shows 61 between 12:00 and 13:00, and rolls over to 60 at 13:01.
2. Midnight-wrap check. Force a cam to 22:00 → 06:00, set the clock to 21:59, and verify duration is 480 minutes. Set the clock to 23:00 and verify the remaining-minutes value counts down 60 minutes per hour.
3. Equal-ON-OFF check. Force a cam to 14:30 → 14:30, verify that the application logic treats it as a 24-hour window (1440 min), not 0 min. The application should explicitly test for this edge case.
4. Block count audit. After wiring the decoder, check Tools → Block Properties to confirm the SF count is below 250 (LOGO! 8 limit). If it is, consolidate the decoder as in §9.1.
5. Onboard display test. Download the program to a physical LOGO! 8, navigate to Program → B001 → Cam 1, change the ON time to 14:00, and verify the VM words VW100/VW102 update without requiring a redownload.
6. Field acceptance. Run the system for at least one full on/off cycle and confirm the HMI shows the same period length as the Web-Based Management screen and the LOGO!'s onboard display.

11. Troubleshooting Matrix

12. Frequently Asked Questions