Function key not working in a panel activate expression

Why a held input blocks the function key

A panel activates when its activate expression changes from false to true. The level alone does nothing; the change is the event. Pressing a key into an expression that already reads true adds one more true input to an OR that is already true, the result stays at true, and no event fires.

The expression behind this fault reads:

(\..Keyboard.f1) or (!buttonMaximizeOnStartup)

The startup term sits at true for the whole run, so the OR result is true from the moment the project starts. Keyboard.f1 is momentary: true while F1 is held, false after release. False or true is still true, so the combined result never falls, and a press can never produce the rising edge that fires activation. Remove the startup term and the key works again, because the keyboard input then makes its own transition.

Logic design gives this a name: level triggering acts on the state an input holds, edge triggering acts on the change. The page on level-triggered and edge-triggered logic covers the distinction in depth.

Grouping cannot help. Parentheses set the order terms combine in, not what any term reads, and an OR with one true term is true under any grouping. The stuck term has to go, or it has to end.

Symptoms and what each points to

Match your panel against these four:

• Startup maximize works, the function key does nothing, and deleting the startup term brings the key back. The startup term is holding the activate expression true. This is the fault this page fixes.
• The function key does nothing even with the startup term gone. The key input never changes state; watch its value while pressing and chase the input side. The stuck-bit version is covered in HMI function key bit stays on after a short press.
• The panel responds once after startup and then ignores later presses. A term that latches on after its first use stalls the expression the same way: the result needs to fall back to false between uses, and a latched term never does.
• The startup input blocks something else, such as the setup menu. That is a separate startup-button fault with its own fix, described in A startup ON button blocks the setup menu.

Two checks that confirm the cause

Run these before changing any configuration:

1. Read the activate expression and name every term. For each one, ask what it reads between events. Any term that is not false between events is the blocker.
2. Delete the startup term for one test and press the function key. In this fault, the key worked as soon as the term was gone, which pins the cause on the shared expression and clears the key itself.
3. Put the term back and watch the combined expression value through a press. It sits at true from before the press to after it. A value that never moves can never make an edge.

The second check takes under a minute and separates an expression fault from an input fault.

The fix: pulse the startup request through a One Shot

A One Shot object turns on immediately when its input turns on, holds for its timer delay, then turns off. The same bounded pulse has a long history in hardware: the design notes for a 555 timer edge-triggered one-shot show the same shape, one trigger in and one bounded pulse out. Fed a constant on-input, a One Shot makes one clean pulse at startup and then goes quiet. That pulse replaces the held term.

1. Add a One Shot object to the project. The configuration that cleared the fault named it Startup_OneShot.
2. Set On/off signal to 1. The constant input makes the timer fire as the project starts.
3. Set Timer delay to 00:02 and Display format to MM:SS. The pulse lasts 2 seconds.
4. Assign both members, with your panel name in place of Home_Pnl and your pushbutton object in place of GoTo_Home_Pnl_PB: Home_Pnl.activate = ..GoTo_Home_Pnl_PB or ..Startup_OneShot, then Home_Pnl.maximize = ..Startup_OneShot.
5. Drive .maximize from the one-shot alone, and keep the operator pushbutton and the function key as the only request terms on .activate.

During the 2 second pulse the OR reads true, so the panel activates and maximizes at startup. When the pulse ends the OR falls to false and the expression is armed. The next F1 press makes the false-to-true change and fires. Every term you leave on a shared expression needs a falling edge; the pushbutton has one because it returns false on release, the same momentary behavior behind why a panel pushbutton LED only stays on while pressed.

Worked example: one F1 press against a held startup term, then against a 2 s one-shot

The inputs:

• Keyboard.f1, false between presses and true while F1 is held. It appears in the fault expression above.
• !buttonMaximizeOnStartup, true for the whole run. The behavior shows it: startup maximize kept working and the key never fired while this term sat in the expression.
• The one-shot Startup_OneShot with On/off signal 1, Timer delay 00:02 in MM:SS, a 2 second pulse. These are the values that cleared the fault.

The rule in words: the panel fires activation only when the activate expression changes from false to true, and an OR returns true when any one input is true.

The arithmetic:

• Held startup term, between events: false or true = true.
• Held startup term, during an F1 press: true or true = true. Change across the press: none. Activations fired: 0.
• One-shot, project start, pulse on: false or true = true. The panel activates and maximizes.
• One-shot, 2 seconds in, pulse off: false or false = false. The expression is armed again.
• One-shot, first F1 press after startup: true or false = true. Change: false to true. Activations fired: 1.
• One-shot, key released: false or false = false. Ready for the next press.

Result: the held term delivered 0 activations per press. The 2 s one-shot delivered the startup activation plus 1 per press, and the expression sits at false between uses.

Decision: any term on the activate expression that is true at the moment a key is pressed blocks that key. A term is safe only when it reads false between uses, and a 2 second pulse is what turns a one-time startup request into that kind of term.

Test a real restart, then the key

1. Start the project the way operators do. The panel activates and maximizes during the pulse.
2. Confirm the one-shot returns off after its delay. A one-shot that never turns off rebuilds the original block.
3. Press F1 once after the pulse has ended. The panel activates.
4. Press and release F1 several times. Every press should fire, because the input returns false between presses.

If the startup maximize misses, check the one-shot wiring and the member references before lengthening the delay. If the key still does nothing, watch Keyboard.f1 while pressing it: a value that never moves is an input-side fault, not an expression fault.

The decision

Keep one-time startup requests off a shared activate expression as held levels. A pulse replaces a held term without losing the startup behavior: the panel maximizes during the pulse, the expression returns false when it ends, and the keys work for the rest of the run.

Recommendation: Route each one-time startup request through its own One Shot object, configured as in the steps above with a 2 second pulse. Drive .maximize from the one-shot alone, and leave operator inputs as the only terms on .activate. Lengthen the delay only if the panel misses the startup maximize, and confirm the result on a real restart with a key press after the pulse ends.

Questions