Use a separate confirmation step before writing C0; opening a prompt and changing the control bit are distinct actions. The operator’s first press should request confirmation, while only Yes commits the intended state change and Cancel dismisses the prompt without changing the control bit.
Skip quick fixes that blur the confirmation and command
A password keypad is not a substitute for a Yes-or-Cancel decision. It asks for credentials, not confirmation of a requested machine-state change. Likewise, making the original pushbutton write C0 and then opening a popup is too late: the command has already reached the PLC before the operator answers.
A full-screen change is a workable fallback, but it is not the first choice when the project has a popup-window facility. The full-screen method needs a separate confirmation screen and a return path; the implementation described for this project also introduced some screen-transition latency. A visibility-controlled text box can work, but only if the popup’s controls remain visible and selectable above the underlying screen objects.
| Quick fix | Why it fails or costs more | Use instead |
|---|---|---|
| Use a password prompt for Yes/Cancel | A credential keypad does not represent the requested decision. | Build a prompt with explicit Yes and Cancel actions. |
Let the initiating button write C0 immediately |
The command changes before confirmation. | Make the initiating button open the prompt only. |
| Change to a full-screen confirmation page by default | It needs explicit navigation back and can add transition latency. | Use a popup-window object if available in the project. |
| Show a text box without checking object order | Underlying objects may cover or intercept the prompt’s controls. | Put the message above normal objects and its buttons above the message. |
Separate the request from the state change
The HMI should present an intermediate decision, not directly operate the control bit on the first press. Keep the actions distinct: the request opens the confirmation UI; Yes writes the intended value to C0; Cancel closes the UI and leaves C0 unchanged. The popup’s dismissal is not itself a PLC command.
Decide what Yes means for both current states before configuring the buttons. The initial request describes turning C0 on from off; it also mentions behavior from the on state without fully specifying whether Yes should turn it off or leave it on. Do not silently implement a toggle. If the desired behavior is “turn on” from either state, Yes should request on. If the intent is “toggle,” define that behavior explicitly and ensure the decision uses the actual current state rather than a stale HMI display value.
Keep machine permissives and interlocks in PLC logic. An HMI confirmation reduces accidental operation; it does not replace PLC validation of whether the requested state is allowed. A Cancel action must not reset or otherwise write the machine-control bit as a side effect.
Choose the popup method already available in C-more
The described project ultimately used Event Manager and the result worked. The available implementation options differ in how much navigation and object management they require:
- Popup Window Frame: Check for this object first. It was specifically identified as an available C-more option for a popup-window implementation.
- Event Manager: The project used Event Manager successfully. Configure the initiating action to present the confirmation and the response actions to implement the defined Yes or Cancel behavior. Verify the actual event triggers and actions in the project rather than assuming an event has the desired bit-write semantics.
-
Separate confirmation screen: Use a Change Screen object on the original button to navigate to the confirmation page. Provide Okay/Yes and Cancel controls. Cancel returns to the original screen without changing
C0; Yes causes the PLC to recognize the commit, after which the HMI returns. - Visibility-controlled overlay: A triggered text box and popup buttons can form an overlay. The initial press sets visibility; the response buttons clear it. Set layering so normal screen objects sit behind the message and the popup buttons sit in front of the message.
Do not mix these patterns without a reason. Extra navigation, visibility bits, and event actions create more paths to test and more ways for the popup to remain open or close at the wrong time.
Configure the request, Yes, and Cancel paths
- Record the required outcome for Yes when
C0is off and when it is on. Choose explicit set/clear behavior or an intentional toggle before building the HMI objects. - Configure the original pushbutton to open the confirmation UI only. Confirm that this first action does not write
C0. - Add separate Yes and Cancel controls. Bind Yes to the agreed commit action. Bind Cancel only to dismissing the popup or returning to the prior screen.
- Set the popup’s presentation and layering. For a separate screen, provide a return path from both responses. For a visibility overlay, verify that both response controls are above the message and accessible.
- Make the HMI show the resulting state from the PLC-controlled
C0value rather than treating popup visibility as proof that the command succeeded. - Download or run the project using the normal project workflow, then test both current states and both response paths before returning the control to operators.
For a screen-based implementation, preserve the screen to return to if the project requires returning to the caller rather than a fixed page. The described approach stores the current screen number before changing to the popup screen. Avoid hard-coding a return destination unless the application always uses the same originating screen.
Keep the control bit authoritative in PLC logic
The HMI response is an operator request; the PLC’s control bit is the machine state. For the described installation, C0 is the named bit to be turned on after Yes. The project can have the HMI set the bit directly or have the HMI signal a request that PLC logic validates and applies. In either case, use one clear commit path and prevent the Cancel path from reaching it.
For an explicit set-on command, verify that repeated Yes actions do not create unintended toggling. If a toggle is actually required, the logic must account for the current state at the time of the command. If the operator can issue another command while a prior request is pending, define how the PLC and HMI handle that condition; do not let the displayed button state substitute for PLC state.
Confirmation is an operator-interface feature, not a safety function. Keep any safety-rated stop, guard, or permissive behavior in its designed control system. Do not use a popup to bypass an existing PLC interlock.
Verify each branch before releasing the screen
Test from both initial states. Watch C0 online in the PLC or through an equivalent live diagnostic while operating the HMI. Confirm the displayed button state follows the resulting bit state after the popup closes.
| Starting state | Operator response | Expected result |
|---|---|---|
C0 off |
Open prompt, then Cancel | Prompt closes; C0 remains off. |
C0 off |
Open prompt, then Yes | Prompt closes; C0 takes the defined Yes state, described as on in the request. |
C0 on |
Open prompt, then Cancel | Prompt closes; C0 remains on. |
C0 on |
Open prompt, then Yes | Prompt closes; C0 follows the explicitly selected on-state behavior. |
Also test repeated presses, popup closure, and returning from the confirmation screen if that method is used. For a full-screen approach, observe whether navigation lag is acceptable for the application. For an overlay, test that no underlying button can be activated through or around the popup.
Trace a failed confirmation by its visible effect
| Observed symptom | Likely cause to check | Check |
|---|---|---|
| Popup opens but Yes has no effect | Yes does not invoke the configured commit path, or the PLC does not accept the request. | Monitor the Yes action and C0 in the project/PLC; check applicable PLC conditions. |
| Cancel changes the machine state | Cancel is bound to a write or shares the Yes action. | Inspect Cancel’s action and remove any control-bit write. |
| Popup appears behind objects or controls cannot be pressed | Overlay layering or object visibility is wrong. | Place the text/message above normal objects and the popup buttons above the message. |
| Confirmation page works but return is wrong or slow | Return destination is fixed incorrectly or screen navigation adds latency. | Check the stored/current screen return path or use the popup facility available in the project. |
| Button display disagrees with the actual bit | The HMI display is not following current PLC state. | Compare the HMI indication with the live C0 value and correct the state indication binding. |
FAQ
How do I make a C-more pushbutton ask before turning on C0?
Make the initial press open the confirmation UI without writing C0. Configure Yes as the commit action and Cancel as dismissal only.
How do I make Cancel leave the PLC bit unchanged?
Give Cancel only a popup-close or return-screen action. Test from both on and off states while monitoring C0.
Can I use a C-more Popup Window Frame for confirmation?
Yes, the Popup Window Frame object was identified as an available approach. Configure distinct Yes and Cancel actions, then verify the bit and dismissal behavior in the running project.
How do I troubleshoot a C-more confirmation popup that will not work?
Check whether the prompt opens, whether Yes reaches its commit path, whether Cancel writes anything, and whether the HMI indication tracks live C0. Stop commissioning if the popup can trigger a command without confirmation, Cancel changes machine state, or PLC state and HMI indication disagree; place the machine in its approved safe condition and escalate to official AutomationDirect support or the responsible controls engineer.