Configuring Siemens LOGO! for Changing Holiday Dates

Use the yearly timer for holidays tied to a fixed month and day; their weekday shift does not require an annual date change. For movable or officially observed holidays, calculate the date in logic, load an annual holiday table, or obtain the holiday state from a network-connected calendar service. Drive digital output 1 from the logical OR of the applicable holiday conditions.

Symptom Classification

The visible symptom is that digital output 1 must turn on during holidays, but a weekly timer cannot follow holidays whose calendar dates vary. The first diagnostic task is to classify each holiday by how its date is defined.

A fixed-date holiday does not move merely because its weekday changes. The yearly timer evaluates the month and day, so the same entry remains valid in later years. A separate observed-holiday rule may move the operational closure to a nearby weekday; treat that as a calculated or table-driven exception.

Calendar Mechanism

The term movable holiday here means a holiday whose month-and-day value changes according to a calendar rule. A weekly timer evaluates a repeating weekday pattern. A yearly timer evaluates annual calendar points or intervals. Neither representation alone expresses every weekday-relative or rule-derived holiday.

The controller clock supplies the date used by all three approaches. A wrong year, month, day, weekday, or time zone produces a wrong holiday state even when the logic is correct. Clock retention and behavior after loss of power therefore belong in the acceptance test.

The required Boolean relationship is:

Holiday state = fixed-date match
             OR calculated movable-date match
             OR annual exception-table match
             OR externally supplied holiday state

Digital output 1 = Holiday state AND process permission

Use the final process-permission term when equipment interlocks or operating modes must retain authority over the output. Do not bypass machine permissives merely because the calendar declares a holiday.

Implementation Selection

The available implementation depends on the installed LOGO! hardware version and its supported date, arithmetic, communications, and storage functions. LOGO! Soft Comfort v9 is the stated engineering environment, but that software choice alone does not identify the target device capabilities.

Prefer local yearly timers for fixed dates. For a small number of movable dates, an annual table is often easier to audit than a dense calendar algorithm. Use an algorithm only when its rule is stable and its boundary cases can be tested. Use an external source only after defining data validity, loss-of-communications behavior, and manual override.

Configuration Procedure

1. Inventory the schedule. List every holiday, weekend condition, observed-day rule, and one-time closure. Mark each entry as fixed, weekday-relative, rule-derived, or exceptional.
2. Confirm the target capabilities. Read the installed LOGO! device identification and compare its supported functions with the project configured in LOGO! Soft Comfort v9. Check for clock access, required arithmetic, retained data, and communications before selecting an architecture.
3. Configure fixed dates. Create yearly-timer conditions for holidays defined only by month and day. Do not duplicate these dates in the weekly timer.
4. Configure weekends separately. Use the weekly timer only for repeating weekday conditions.
5. Implement movable dates. Select one method: calculate each rule from controller date values, enter the dates in an editable annual table, or receive a validated holiday state from a network calendar source.
6. Combine the conditions. OR the fixed, movable, exceptional, and weekend conditions required by the operating specification. Route the combined state through process permissions before commanding digital output 1.
7. Define failure behavior. For annual tables, add a visible indication when the configured year no longer matches the controller year. For network data, define an age or validity check and decide whether invalid data leaves the output off or invokes an approved fallback schedule.
8. Document ownership. Assign responsibility for annual entries, clock correction, rule changes, and post-download testing.

Numbered Verification Checks

1. Check 1: controller clock. Expect the displayed year, month, day, weekday, and local time to match the commissioning reference.
2. Check 2: ordinary working day. Force or simulate a non-holiday date. Expect every holiday condition to be false and digital output 1 to remain off.
3. Check 3: fixed-date holiday. Test the same month and day in two different years. Expect the yearly-timer condition and the output command to become true in both years, subject to process permission.
4. Check 4: movable holiday. Test at least two years in which the calculated or entered dates differ. Expect activation only on the correct date for each year.
5. Check 5: date boundaries. Test immediately before the holiday interval, at its start, at its end, and immediately after it. Expect one transition on and one transition off at the configured boundaries.
6. Check 6: restart behavior. Restart the controller during an active holiday. Expect the clock, retained table data, holiday state, and output logic to return to the specified states without an unintended pulse.
7. Check 7: invalid calendar input. Expire the annual table or remove the network update in a controlled test. Expect the configured alarm, fallback state, or output-off response.

Recurring Implementation Pitfalls

Wrong practice starts with treating every weekday shift as a changed holiday date. A fixed month-and-day entry remains valid; only the weekday label changes. Another common error is embedding observed-day rules into fixed-date timers without documenting whether both the legal date and the observed closure should activate the output.

Calendar logic also fails when it has no validity horizon. An annual table needs a year check, while external data needs a freshness indication. A silent stale value is worse than an explicit invalid state because the program can look healthy while applying last year's schedule.

Keep calendar recognition separate from equipment authorization. Holiday logic should declare a schedule state; interlocks should decide whether energizing digital output 1 is permitted. This separation makes simulation possible without defeating process protection.

FAQ