When function keys work only from the startup screen, check whether their navigation actions are screen-local rather than global. Then verify the triggering event, destination and active project, and test every required key from every source screen.
If HMI function keys change screens from the startup page but stop working after the first change, check the scope of their assignments first. A key configured on one screen may have no navigation action on the next. Then check the triggering event, destination and project actually running on the panel. This pattern points toward configuration, but it does not prove that scope is the only fault.
Before testing, put the equipment in the state required by your site's maintenance procedure. A navigation change must not bypass an interlock, alter access permissions or replace a safety function.
Match the symptom to the likely cause
Record which screen is active before each key press. A report that a key “does not work” is less useful than a record showing that it works from one screen and fails from another.
- Navigation works only from the startup screen: inspect screen-local assignments. The startup screen may be the only place where the keys have navigation actions.
- One key fails from every screen: inspect that key's event, action, destination and any enable condition. Hardware input remains a possibility.
- The same key behaves differently on different screens: look for local overrides, duplicate definitions or context-dependent actions.
- The key opens the wrong screen: compare the configured destination with the intended navigation map. Similar screen names can hide a selection mistake.
- The editor looks correct but runtime behaves as before: confirm that the revised project reached the intended panel and became active.
- Keys fail only while a dialog or input field is active: investigate focus and input handling before changing navigation scope.
A screen appearing at startup proves only that the configured startup screen can load. It does not demonstrate that any function-key event is configured correctly.
Decide whether the keys are local or global
Scope means where a key assignment applies. On an HMI that supports screen-local function keys, an assignment belongs to the screen where it is configured. Opening another screen can remove that assignment from the active input configuration.
A global assignment is intended to make a key action available across screens. The editor might place these assignments in a global screen, template or runtime-wide key configuration. Use the terminology and scope rules in your HMI's documentation.
For fixed direct navigation, write down a simple map before editing:
| Key | Intended destination | Where it should work |
|---|---|---|
| F1 | Screen A | Every required process screen |
| F2 | Screen B | Every required process screen |
| F3 | Screen C | Every required process screen |
| F4 | Screen D | Every required process screen |
Use global definitions if the platform supports them and the destinations should stay constant. Otherwise, configure the required actions on every source screen.
Local definitions are useful when a key deliberately changes meaning with the active screen. They are a poor fit for fixed navigation unless you maintain the same mapping everywhere it is needed.
Do not assume how a local definition interacts with a global one. Depending on the runtime, one may override the other or the combination may have another documented effect. Remove unintended duplicates and document deliberate exceptions.
Check the event as well as the action
A destination selected in the editor is not enough. The navigation action must be attached to an event that the intended key operation actually generates.
Inspect the complete chain:
- Select the function key in the scope that should be active.
- Open its event configuration.
- Confirm which event invokes navigation, such as press or release.
- Confirm that the action is the platform's documented screen-change function.
- Confirm the destination using the actual project screen name or identifier.
- Check any documented conditions or permissions that can prevent the action.
A press action and a release action are not interchangeable assumptions. Test the event you configured. Also inspect both events for conflicting actions, such as opening one screen on press and another on release.
If input focus appears relevant, use the platform's documented diagnostics or a suitable simulator to distinguish a missing key event from an event that runs the wrong action. Do not add a machine-output command merely to prove that a key is detected.
Apply the smallest configuration fix
Back up the current project and record the original assignments before changing them. Keep the repair limited to navigation unless another fault is clearly established.
For a fixed mapping, use one of these approaches:
- Global mapping: place each navigation action in the supported global key configuration, then inspect the process screens for conflicting local definitions.
- Repeated local mapping: add the required key actions to every screen from which navigation must work. Check each event and destination rather than assuming a copied assignment is correct.
Keep direct selection separate from next, previous and back functions. A key assigned to Screen A always has an explicit destination. A back action may depend on navigation history, while next and previous actions need a defined screen order and boundary behavior.
Changing the navigation model during troubleshooting adds another variable. First restore the intended direct mapping. Consider a different navigation design only after that mapping works consistently.
Confirm that the revised project is active
An offline edit cannot change the running panel until the updated configuration is transferred and activated through the supported workflow.
Compile or validate the project and resolve navigation-related errors. Confirm the target device before transfer. Follow the documented transfer procedure, including any required runtime stop or restart, during an approved maintenance window.
Where the platform provides project identification or transfer records, use them to confirm which revision is running. Do not rely only on the editor showing the latest change.
If the engineering environment requires project conversion, retain the original backup and follow the manufacturer's supported migration path. Obtain software and documentation from the manufacturer or its distributors. An unrelated example project is not evidence that your active configuration has been corrected.
Test navigation from every source screen
Testing only from startup can reproduce the original blind spot. Check each required key from each source screen and record the observed destination.
For the four-screen example, the expected results are:
| Starting screen | F1 target | F2 target | F3 target | F4 target |
|---|---|---|---|---|
| Screen A | A | B | C | D |
| Screen B | A | B | C | D |
| Screen C | A | B | C | D |
| Screen D | A | B | C | D |
Selecting the screen already displayed may produce no visible change. Do not count that alone as a failure. Check the documented same-screen behavior and use supported diagnostics if you need to confirm event execution.
Include a return transition and a nonadjacent transition. For example, check A to B to A, then A to D to C. After an approved runtime restart, repeat enough checks to confirm that startup has not hidden a different active project or configuration.
Failures confined to one source screen point back toward that screen's assignments or overrides. Failures following one key across all screens point toward its event, action or input path. Failures appearing only with a dialog open point toward focus or modal input handling.
Keep the navigation repair within the HMI
Screen navigation belongs to the HMI application. A separate information display is not a substitute for repairing control-interface behavior. Keep the distinction between a factory status display and an operator HMI clear when deciding which interface owns navigation and machine interaction.
The repair is complete when the intended project is active, every required source-to-destination transition behaves as documented, and access restrictions remain intact. Keep the final key map with the project so future screen additions do not reintroduce a local-scope omission.
Questions
Why do HMI function keys work only on the startup screen?
The key actions may be configured only on the startup screen. When another screen becomes active, those local assignments may no longer apply. Check the assignments on the destination screen and any supported global key configuration before assuming the physical keys are faulty.
Should fixed navigation keys be local or global?
Use a supported global configuration when a key should select the same destination across screens. Use local assignments when its meaning intentionally changes with the screen. Check the runtime's documented precedence rules before combining local and global definitions.
What should I check if the screen-change action is already configured?
Confirm that the action is attached to the event generated during your test. Then inspect its destination, conditions, permissions and possible conflicting actions. Finally, confirm that the revised project was transferred to the correct panel and is the configuration currently running.
How do I verify an HMI navigation repair?
Test every required key from every source screen, including return and nonadjacent transitions. Record the starting screen, key and observed destination. Selecting the current screen may have no visible effect, so interpret that result using the platform's documented behavior.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.