Diagnose an HMI video playback freeze by testing inactivity timing, single-event navigation, touch handling and sustained playback separately. Keep optional video disabled if it compromises the operating interface, and collect a reproducible test case for the equipment vendor rather than assuming a timer change has fixed the runtime fault.
Disable the optional video screensaver if it makes the operator interface unreliable. Then separate four functions: inactivity detection, screen entry, touch handling and sustained video playback. A change that corrects one function does not establish that the others are sound.
Start with a controlled baseline, change one condition at a time and record what stops responding. Do not assume that a frozen display means the controller has stopped, or that a controller still executing means the machine is safe.
Identify what has stopped responding
The visible symptom determines the next check:
- Video stops, but navigation still works: investigate the media element, file, playback settings and documented runtime diagnostics first.
- Video keeps moving, but the return button fails: investigate touch routing, overlapping objects and the navigation action.
- The whole interface stops responding, while controller diagnostics remain available: investigate the display runtime without assuming the control program has stopped.
- Process values stop changing, but menus and buttons still work: distinguish a data-refresh problem from a frozen interface. The checks for factory screen update delay address that separate symptom.
- Both the interface and independent controller diagnostics become unavailable: broaden the investigation to controller status, communications and power. Video alone is not an adequate explanation.
Confirm controller status through an authorized engineering connection or existing independent diagnostics. Do not rely on the frozen screen to establish process state. Follow the site's safe-stop procedure if required controls, alarms or indications are unavailable.
Before attempting recovery, capture available diagnostics if doing so is safe. Use the equipment vendor's documented recovery procedure. Do not remove power from a combined controller and display while the process depends on it.
Establish a baseline without video
Save the current application and record the hardware model, engineering software version, runtime or firmware version, and media-file details. Keep each hardware configuration in a separate test record.
Use a bench setup, simulation environment or approved maintenance window that cannot cause hazardous machine movement. Make application changes only through the normal change-control process.
- Disable automatic entry to the video screen.
- Run the normal application without video for a representative period.
- Exercise the navigation and touch functions that normally precede the failure.
- Record whether the interface remains responsive and whether any diagnostic messages appear.
- Repeat with a static screen in place of the video screen, keeping the navigation sequence otherwise unchanged.
A stable baseline makes video-related testing more useful. It does not prove that video decoding is the root cause. Entering a different screen can also change scripts, communications, object activity or resource use.
If the application freezes without video, investigate that condition before tuning the screensaver.
Check inactivity detection separately
Temporarily disconnect the inactivity timeout from the screen-load action. Observe the touch indication and timer through the vendor's supported diagnostic tools.
Check the documented meaning of the touch signal. It may represent an event, a pulse or a maintained state. The timer logic must match that behavior rather than assume that every signal called “touch” behaves alike.
- Touch the operating screen and confirm that the inactivity interval restarts.
- Leave the screen untouched and confirm that the timeout occurs after the configured interval.
- Touch again and confirm that the timeout clears or rearms as intended.
- Repeat from each screen where automatic video entry is permitted.
Also decide what counts as activity. A screensaver should not hide information that must remain visible during a process, an alarm or an operator task. Follow the equipment's operating requirements rather than treating lack of touch as permission to obscure the interface.
Correct inconsistent timer behavior before reconnecting automatic navigation. A timer that works correctly still says nothing about long-duration playback stability.
Make screen entry a single event
A maintained timeout can remain true across many controller scans or runtime updates. Depending on how the screen action is configured, that condition may generate repeated requests to load the same screen.
Use the vendor's documented event mechanism, such as a rising-edge trigger or a state transition, when the requirement is one screen-entry request. Do not add an edge detector blindly if the action already responds only to a transition.
The intended sequence is simple:
- The operating screen waits for the permitted inactivity interval.
- One timeout event requests the media screen.
- The media state remains active without issuing repeated entry requests.
- A valid return action leaves the media state and starts a fresh inactivity interval.
Where supported, count or log navigation requests. The displayed picture cannot tell you whether the runtime has received one request or many. Check repeated entry and exit, including a touch close to the timeout boundary.
Removing repeated requests is a useful correction when they exist. It is not proof that a delayed video freeze has been fixed. Continue with playback testing after navigation behaves correctly.
Separate touch handling from video rendering
Open the media screen manually, without the inactivity timer. During commissioning, use a visible return control so its bounds and action are clear.
Do not assume that an invisible button placed over a video object will receive touches merely because it appears higher in the editor. Some runtimes render video on a separate surface or apply different input rules. Check the vendor's documentation for supported layering and touch behavior.
Test the return control while the video is playing, while it is stopped and after it reaches the end. Check several points within the intended touch area. Confirm both that the touch is detected and that the navigation action executes.
Also verify the return destination. Adding an intermediate information screen can change what “previous screen” means. Use an explicit destination or a deliberately retained operating-screen reference when the runtime supports it.
Do not let the touch used to dismiss optional media activate a process control on the destination screen. Check that behavior as part of the return sequence.
Build up the playback test in stages
Use media that meets the runtime vendor's documented format requirements. Keep the application, file and playback settings unchanged within each test so the result has a clear meaning.
| Test condition | What it helps separate | What to record |
|---|---|---|
| Static media screen, no video | Screen entry and screen-specific activity | Touch response and navigation requests |
| One finite clip, repeat disabled | Basic playback and end-of-media handling | Completion, return action and diagnostics |
| Repeated entry to one finite clip | Repeated creation and closure of the media element | Completed entries and elapsed time |
| Finite clip followed by a static interval | Playback lifecycle and transitions between media and static content | Clip completions, transitions and touch response |
| Intended repeating playback | The final operating sequence | Elapsed time, completed cycles and failure state |
A static interval is a diagnostic variation, not a confirmed remedy. It may change resource demand or exercise a different runtime path. A successful result does not identify the underlying defect by itself.
If the documented media requirements call for a different encoding, make a new file using those settings and change no other test variable. Keep the original file for comparison. Do not infer compatibility from a filename extension alone.
Run sustained tests beyond the longest previously observed failure interval where the approved test conditions allow it. A short demonstration cannot establish that an intermittent freeze is resolved. Record a test stopped early as incomplete, not successful.
Apply the correction supported by the evidence
Correct timer logic when the timer fails its isolated checks. Correct navigation when request counts show repeated entry. Correct touch routing or the return action when playback continues but input does not reach the intended control.
If the interface still freezes during manual playback in a minimal application, prepare a vendor support case rather than making unrelated controller changes. Check release notes and vendor guidance for the exact hardware and software combination. Obtain software and firmware only from the manufacturer or its authorized distributors, and follow the documented update and recovery procedures.
Do not assume heat, a memory leak or insufficient processing capacity without evidence. Record available temperatures, memory indicators and runtime logs using supported diagnostics. These observations can help the vendor distinguish causes; none is a diagnosis on its own.
If optional information video is the only reason to add media playback, consider whether a factory status display rather than an operator HMI is the better place for it. That separates the information task from the control interface without treating another display as a substitute for required machine indications.
Send a reproducible vendor support case
Include the details needed to repeat the failure:
- Configuration: exact hardware model, runtime or firmware version, engineering software version and application revision.
- Media: the original clip, its encoding details, playback settings and the vendor requirements used to prepare it.
- Sequence: starting screen, inactivity setting, navigation trigger, return action and repeat behavior.
- Results: baseline outcome, elapsed time to failure, completed cycles and which functions remained responsive.
- Evidence: permitted diagnostic exports, relevant event timestamps and a minimal reproduction project where practical.
- Recovery: the documented recovery action used and whether the same sequence reproduced the fault afterward.
After a correction, repeat the previously failing sequence under comparable conditions. Check touch response, return navigation, alarm visibility and the next inactivity cycle as well as video playback. Keep optional video disabled on the operating interface until the unresolved failure has an acceptable disposition through the site's engineering process.
Questions
Will a one-shot screen-entry trigger fix an HMI video freeze?
No. It can establish whether the navigation logic is repeatedly requesting the same screen, but it does not establish that sustained playback is stable. Verify the runtime's action semantics, confirm one request per entry, then repeat the playback test that previously produced the freeze.
What should I check if video plays but the return button does not work?
Check whether touch events reach the intended object and whether its navigation action executes. Video rendering can have runtime-specific layering and input behavior. Test a visible return control using the vendor's supported configuration before relying on an invisible button over the video.
Does a running controller mean it is safe to ignore a frozen HMI?
No. It is useful evidence that the failure may be display-side, but an unavailable interface can still remove required controls, alarms or indications. Establish process state independently and follow the site's safe-stop and recovery procedures. Do not treat continuing controller execution as permission to keep operating.
How long should a sustained playback test run?
Test beyond the longest previously observed failure interval under approved conditions, then repeat the important entry, exit and touch sequences. Record elapsed time and completed playback cycles. If the test ends before the previous failure interval, describe it as incomplete rather than proof that the fault is fixed.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.