Two events, one writing on at 06:00 and one writing off at 18:00, is the right pattern. The run-once behavior comes from events saved without repeat and from clock-advanced tests that cross an event time once. Put a weekly Monday repeat on both writes and prove each write at its real time.
Your two events are the right pattern, and the run-once behavior has one cause: both were saved without repeat, so each holds a single start date. The clock you moved forward crossed the on event's time, spent its one write, and left nothing armed for the off transition. Open both events, select repeat, set the recurrence to Monday, and confirm the tag write state boxes: on at 06:00 and off at 18:00. Then prove both writes with the clock left alone. Below is the symptom map, the checks, and a test that never touches the clock.
What each symptom points to
- The on write fired once during your clock test, then never again. Both events are one-shot. An event saved without
repeatcarries one start date, and once that date is behind it there is no further write to make. This sits in the same family as a PLC flag that triggers an HMI event once: the trigger works, the recurrence is what is missing. - The end time field is grayed out. The editor pairs the end time with
repeat, so a one-time event shows a start only. That locked field was the tell: while it was gray, your events had no recurrence. - The tag turns on and flips back off seconds later. The schedule is working; a second writer is on the same address. A PLC rung, another scheduled event, or a second panel can overwrite the bit right after your event sets it.
- The event time arrives and nothing happens. The schedule runs on the panel's own date and time. A panel showing the wrong weekday, date or time zone skips a Monday 06:00 event with no error message.
The fix: one event per write, repeat on both
- Open the first time-based event. Set its start time to 06:00 and check the tag write state
onbox for the target tag. - Select
repeatand set the recurrence to Monday, weekly. The end time field becomes editable when you do; leave it, because the off transition gets its own event. - Create the second event on the same tag. Start time 18:00, tag write state
off,repeatselected, recurrence Monday. - Confirm both events are enabled and both point at the same tag, same address, same bit type. A near-duplicate tag name is the classic wrong target.
- Save, download, then reopen both events and confirm
repeat, the weekday and both write states survived the save. - Read the panel clock display: date, time and weekday. A Monday event needs the panel to agree it is Monday when 06:00 arrives.
A tag holds the last value written to it, so the on write at 06:00 stands until the off write at 18:00. That is the stay-on behavior you wanted. If you later build a schedule from a start and end pair instead, test what the editor writes at the end time before you rely on it; the two-event pattern needs only the two start times.
Checks before you call it fixed
- Read the panel clock and confirm date, time and weekday are all correct.
- Reopen both events after every download; confirm
repeat, Monday, both write states and both enabled flags. - Watch the tag value at the event minute in an online view or a trend, not on the configuration screen.
- Search the PLC program and the event list for anything else writing the same address.
The panel judges the schedule by its own date and time, so the first check is the clock, not the events. Moving the clock forward to hurry a test crosses one event time and fires one write: it checks the write path and tells you nothing about next Monday. Sites that shift the clock for daylight saving should recheck date, time and weekday after each change, the same habit as setting a PLC clock from the operator panel for daylight saving time.
If the tag flips back, find the second writer
An event writes once, at its time. If the bit lands on and returns off within seconds, another writer owns the address. The collision is the one behind two HMI panels making competing writes to one PLC: whoever writes last sets what the machine sees. Give the schedule its own tag and let the PLC read it, or make one writer the owner and turn the rest into readers.
Example: Monday 06:00 to 18:00 on one bit, counted out
Inputs:
- The requirement: bit set at 06:00, cleared at 18:00, every Monday.
- The editor: time-based tag events with a
repeatoption and a weekly day selection. - The panel clock: correct date, time and weekday.
Rule in words: every state change is one write, and every recurring write needs its own event with repeat set to the days it must run.
Arithmetic:
- On window per Monday: 18:00 minus 06:00 = 12 hours with the bit set.
- Writes per Monday: 1 on write + 1 off write = 2 writes.
- Events: 2, each with weekly Monday recurrence.
- Writes per year: 2 writes x 52 Mondays = 104 writes.
- Coverage without
repeat: 2 writes total, both spent in your first test. That is 2 of 104, about 2 percent of the year, which matches what you saw: correct once, silent after.
Fast test with the clock untouched: on any weekday, temporarily set both events to daily recurrence, the on event 2 minutes ahead and the off event 5 minutes ahead. Watch the tag change twice, on then off 3 minutes apart. Restore Monday, 06:00 and 18:00, save, and reopen both events to confirm the recurrence stuck.
Decision: any schedule with 2 or more writes on a repeating pattern gets one event per write, each with repeat selected. A single-write schedule, such as one weekly reset, is the only case a one-shot event serves, and even there a weekly repeat is the safer save.
When the schedule belongs in the PLC
Panel-side events run while the panel runs. If this bit starts a pump, opens a valve or enables a machine at 06:00, treat a missed write as a machine problem and put the time compare in the controller, with the panel used to set times and show state. PLC schedules keep running when the HMI panel is offline, and you can schedule PLC outputs by day and time from an HMI panel for the setup screens. For the controller-side pattern, see weekly run-time schedules written in PLC logic.
The decision
Recommendation: keep your two events and put a weekly Monday repeat on both, the on write at 06:00 and the off write at 18:00 on the same tag, then prove both writes with the clock untouched. Keep the schedule on the panel when the tag drives displays or logging and the panel runs at both times. Move it into the PLC when the bit starts equipment, or when the panel could be off, rebooting or mid-download at either time.
Questions
Why is the end time grayed out until I select repeat?
In this event editor the end time belongs to a repeating schedule, so the field stays locked while the event is one-shot. Selecting repeat makes it editable. For a bit set at 06:00 and cleared at 18:00 you do not need the end time: two events, each writing one edge at its start time, do the whole job.
Can I test the schedule by setting the HMI clock ahead?
Only as a check of the write path. Crossing an event time with a moved clock fires that single write and nothing more, so it verifies the tag, the address and the write access, never the weekly recurrence. Restore the correct date, time and weekday afterward, then run the daily-recurrence test in the example, which leaves the clock alone.
What keeps the tag off between Monday 18:00 and the next 06:00?
The last write stands. A tag holds the value written to it until something writes it again, so the off write at 18:00 on Monday holds through the week until the next 06:00 write. If the bit changes on its own, a second writer is on the address, and the schedule needs a tag nothing else writes.
Should the schedule live in the HMI or in the PLC?
Keep it on the panel when it runs at both write times and the tag only feeds displays, counters or logs. The controller is the better home for a schedule that actuates anything, or one whose write times could fall while no panel is watching: a missed panel-side write happens silently, while the controller keeps its own time compare.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.