One HMI demo button that turns every simulated light off

Can one pushbutton turn off every simulated light without a PLC?

Yes, and the build is one event or recipe action that writes the OFF value to every light's internal bit from a single press: six lights means six OFF writes behind one button, running with no controller attached.

Simulation exists for exactly this stage of a project. The screen needs to behave while the purchase order waits on the customer's feedback, so the whole demonstration, individual buttons, indicators and the all-off button, runs on internal bits with no controller attached. Keep the two layers separate in your head from the first build. The simulator pass demonstrates the screen: button behavior, indicator appearance, the all-off interaction. Machine validation, meaning controller logic, output wiring and real lamps, happens later and on hardware. A customer who approves the screens after a simulator demo has approved the interaction, and that is all the demo claims.

What do you need before you build the all-off button?

Three things: an inventory that pairs every light indicator with its own internal bit, individual toggle buttons already working on those same bits, and the simulator, whose Data View box lets you force any bit to 0 or 1 while the screen runs.

• The light inventory. One line per light: the indicator's name and the internal bit it reads. Six lights means six lines. The action list gets checked against this list line by line.
• Working individual buttons. Each light keeps its own toggle button on the same internal bit. The shared button changes none of that; the two controls coexist by design.
• The simulator and its Data View. Starting a simulation opens a Data View box beside the screen, and forcing bits there is what produces the mixed and all-on starting states for the tests.

Why must the all-off button write OFF instead of toggling each light?

Because a toggle means change whatever state is present, so any light that is already off flips back on: from a screen showing 3 lights on and 3 off, one pass of a toggle-everything action still leaves 3 lights lit.

A toggle button is the right object for one light and one operator: each press flips that lamp, and flipping is what the operator asked for. The shared button has the opposite job. It must land the screen in a defined state, every light off, no matter which starting pattern was on screen. Landing in a defined state is a write of a constant value, one per bit. Toggles can only flip, so a lamp that was already off comes back on and the demo shows the opposite of what the button promises. Keep the toggles on the individual buttons and give the shared button writes. Where the same object rule bites on real inputs is its own subject; why an HMI toggle cannot force a PLC physical input takes the hardware version of it.

Should the all-off action live in an event or a recipe object?

Either one works, because both can fire many writes from a single press, and the deciding test is identical for each: one explicit OFF write per light bit, all in one list, so a light added later gets one new entry and cannot be missed.

An event can trigger on a rising or falling edge and carry many actions, and writing a new value to a tag is one of the actions it supports. That is a direct fit for the all-off job: one event, triggered on the edge that matches a press, holding one OFF write per light bit. The same edge-and-many-actions pattern is what makes an event triggered screen change fire when a PLC alarm bit turns on, so the mechanism is a normal part of an HMI project, not a workaround.

A recipe object is the second route. It sits on the screen looking and acting like a pushbutton, and one press can change the value of a tag or of several tags at once. Configure the same write list inside it: one entry per light bit, each carrying the OFF constant, no toggles. Projects that already use recipes for setpoints often prefer this route because the writes live where the button is.

Recommendation: build the all-off action as one event that fires on the button's press edge and holds one OFF write per light bit; pick the recipe object when your project already keeps its multi-write actions in recipes, because both routes must pass the same check, an explicit OFF write for every bit in the inventory and no toggle anywhere in the list.

How do you wire one button press to a write on every light bit?

You build one action list with one entry per light and attach it to a single trigger: for a six-light screen that is 6 write actions and 0 toggles, each write aimed at one light's internal bit with the constant OFF.

1. Write the inventory first: one line per light, naming the indicator and the internal bit it reads.
2. Create the event and set its trigger to the edge that matches a press. An event can trigger on rising or falling edge, so choose the one your button produces and leave it there.
3. Add one write action per light: the target is that light's internal bit and the value is OFF, 0.
4. Reconcile the list against the inventory, entry by entry: every light present, no bit written twice, no entry aimed at a bit a different indicator reads.
5. Place the all-off pushbutton on the demo screen and point it at the event. If you went the recipe route, give the recipe button the same write list.
6. Keep every unrelated tag out of the list. The action touches the light bits and nothing else, so any misbehavior traces to a single line.
7. Save the project and start the simulator.

How do you test it in the simulator before the customer sees it?

Run two tests, not one: force a mixed pattern with at least one light already off, press once and expect every indicator to drop, then force all 6 bits on, press once and expect the same result.

1. Start the simulation. The Data View box opens with it.
2. Force a mixed starting pattern: set three of the light bits to 1 and the other three to 0, so at least one lamp is already off before you touch the button.
3. Press the all-off button once. Every indicator should go dark and all six bits should read 0 in the Data View.
4. Force the all-on state: set all six bits to 1, press once, and expect the same all-off result.
5. Then run the demo the way the customer will see it: toggle a few individual lamps, press all-off, then press one individual button again to show normal operation survives.

A bit that refuses to change has three suspects, checked in this order: the action targets a different internal bit than its indicator reads, the button was never tied to the event, or the action is a toggle dressed up as a write. Hand-forcing bits to 0 in the Data View shows the indicators work, but the button itself has to produce the all-off state from both starting patterns before the demo is ready.

What does a six-light example prove in numbers?

Six lights give 64 possible on-off patterns, the write method clears all 64 with exactly 1 press, and a toggle-everything action reaches all-off from only 2 of those 64 patterns, about 3%, which is the whole case for writing constants.

Set the screen up with six lights, each on its own internal bit. The six bits together hold 2^6 = 64 possible on-off patterns, and every one of them is a state the customer can create by pressing individual buttons before trying the shared one.

The write-based build answers all 64 patterns the same way: 1 press fires 6 write actions, each pinning one bit to OFF, and the screen ends dark. Count the presses from the mixed test state, lights 1, 2 and 3 on: the three ON writes hit lamps that were lit, the three OFF writes hit lamps that were already off, and the result is 0 lamps lit after exactly 1 press. The starting mix never changes the press count, because a write overwrites whatever it finds.

Now build the same button badly, as toggle-everything. Each press flips all six bits, so from any starting pattern the screen can only ever show that pattern or its complement, 2 reachable states. All-off sits in that pair only when the screen started all-on or already all-off: 2 of the 64 patterns, or 1 in 32, about 3%. From the mixed state the toggle button gives 3 lamps lit after press 1, back to the original 3 after press 2, and it cycles forever without reaching 0. That gap, 64 patterns cleared in 1 press against 2 patterns out of 64, is why the action list holds writes.

Which symptom points to which mistake?

Three symptoms cover most failed builds: a light that switches on when you wanted everything off means the action toggles, a light that stays lit means its bit is missing or wrong in the action list, and a dead button means the event never fires.

Work down the table in order; each row names a configuration check that takes under a minute.

What is still untested when the PLC arrives?

Everything downstream of the screen: the demo proves the event writes OFF to six internal bits, and the PLC logic, the output module, the field wiring and the lamps wait for hardware, checked one output at a time.

When the controller arrives, the event structure carries over unchanged. Repoint each write from its internal bit to the PLC tag its indicator reads, keep one entry per light, and the button keeps its meaning on real hardware. Then validate the machine layer on hardware, with the machine out of service while the first presses go through, because each press of the all-off button is now a command to real equipment. That is the safety note, and it is the only one this build needs.

A lamp that misbehaves at that stage is a hardware-layer hunt, and the screen demo has nothing to say about it. The page on troubleshooting a PLC light that will not turn off starts from the output side, and the one on a latched toggle switch that will not turn off with a master on covers the latch-logic version. If the customer review also produces a request for a board that plays notices or status slides elsewhere on the floor, that is a signage display playing its own offline content, a different product from the HMI, and our shop-floor signage is the side of the catalog that covers it.

Questions