Choose image and video widgets for the actual HMI runtime and deployed client, not just the engineering preview. Establish playback with a fixed media reference first, then add controller-driven selection so delivery, rendering and binding faults remain separate.
Choose HMI image video widgets only after you identify the visualization runtime and the client that will display them. A widget available in one runtime may have no equivalent in another, even within the same engineering project. Image display, image selection and video playback are also separate capabilities.
Start with a fixed image or video reference on the intended client. Once that works, add controller-driven selection. This gives you a useful dividing line: a fixed-source failure points toward resource delivery, rendering or widget configuration; a failure introduced by dynamic selection points toward the binding or its resource mapping.
Identify the runtime before choosing a widget
Record the visualization runtime, its installed version and the target client. Do not choose from a widget library until you know that the library belongs to the deployed visualization.
A browser-based visualization and a native panel runtime can handle media differently. The browser-based version may request a file from a visualization server and decode it on the client. A native runtime may require an imported project resource or another documented deployment method. A file that opens on the engineering workstation does not establish support on either target.
Check the installed help for the exact runtime and widget version. You need answers to four questions:
- Does this runtime provide the required image or video element?
- Which formats and, for video, encoded streams does it support?
- How must the project package or expose the media?
- Which clients support the feature?
Also distinguish a missing feature from a missing configuration. If the native runtime does not document video playback for your target, changing a resource path will not add it. Confirm the supported implementation before committing to a visualization redesign.
Match the widget to the presentation
Select the element by what the screen needs to show, not just by the file extension. A static photograph, a machine-state symbol and an instructional clip have different selection and presentation requirements.
| Presentation requirement | Typical widget category | What to confirm before choosing it |
|---|---|---|
| One fixed photograph or diagram | Image | Supported image format, resource reference and scaling behavior |
| A symbol selected by a machine state | State image, image list or image selector | Whether the element selects one image, displays a collection, or requires an explicit value-to-image mapping |
| Several images visible together | Image collection or repeated image elements | Layout, scrolling and resource-loading behavior |
| A video clip | Video playback | Supported container and codecs, playback controls, client support and start behavior |
| A document with pages | Document viewer | Supported document format, navigation and client restrictions |
| A separately served web presentation | Embedded browser component, where supported | Supported browser features, access policy and integration requirements |
Widget names are not a specification. An element called an image list might show several images, select one image from an index, or expose another documented behavior. Read its properties before using it as a state indicator.
For a screen containing both a photograph and a video, separate image and video elements usually make the configuration easier to inspect. Do not assume that an image collection can play video or that a document viewer can substitute for an image widget.
Check media support on the intended client
A supported file extension is only the first check. JPG and JPEG commonly identify the same image-format family, so renaming one extension to the other is not a reliable repair for a blank image. Confirm the actual file format and the runtime's documented import or decoding requirements.
For video, check both the container and the encoded streams inside it. Two files with the same extension can contain different video or audio codecs. Frame dimensions, frame rate and decoding load can also affect whether the client presents a clip acceptably.
For browser-based clients, check playback behavior as well as decoding. Automatic playback with sound may require user interaction or an approved client policy. A visible video frame with no automatic start is a different symptom from a resource that never arrives.
Use a small, documented-compatible sample for the first check. It should have a known source and simple playback requirements. Do not start by troubleshooting a large production clip with several unknown encoding choices.
The deployed client is the deciding environment. A successful preview on the engineering workstation is useful, but it does not prove that the target client has the same resource access, decoder support or playback permissions.
Use fixed media to separate the fault layers
Before adding controller selection, configure a fixed resource reference through the widget's documented properties. Keep the widget visible, use an uncomplicated layout and deploy the required media with the visualization.
Change one layer at a time. Replacing the widget, moving the file and changing the binding together makes both success and failure difficult to explain.
| Observation | What it points toward | Useful next check |
|---|---|---|
| The fixed image is blank | Resource reference, deployment, visibility or decoding | Confirm the file is available to the target and the widget has a visible display area |
| The video controls appear but no picture plays | Resource delivery, codec support or playback policy | Check whether the resource arrives, then inspect decoding and start conditions |
| Fixed media works but dynamic selection fails | Binding value, mapping or generated reference | Compare the dynamic result with the fixed reference that worked |
| The workstation works but the deployed client fails | Client-specific access or rendering differences | Compare resource location, permissions and supported media features |
| Media appears but is cropped or distorted | Layout and scaling | Inspect aspect ratio, clipping and widget bounds |
On a browser-based client, authorized browser diagnostics can help separate an unsuccessful resource request from a file that arrives but cannot be decoded. On a native client, use the runtime's documented diagnostics and resource inspection tools.
If the media loads but its display area is wrong, treat that as a layout problem rather than a controller communications problem. The checks for kiosk browser sizing in an HMI window address that narrower issue.
Add controller selection after rendering works
A controller connection and a media resource are different parts of the application. A healthy connection does not prove that a generated filename is valid. A file that cannot be decoded does not, by itself, justify changing the communications driver.
Once fixed media works, trace dynamic selection through these points:
- Source value: Confirm the value that requests the media selection.
- Binding: Inspect its data type, update behavior and communication quality.
- Mapping: Check how an index, state or string becomes a resource reference.
- Resulting reference: Compare it exactly with a known working reference, including spelling and capitalization where relevant.
- Invalid selection: Define a clear fallback for missing, out-of-range or unavailable values.
Pay particular attention to type conversions. An integer state mapped to an image index is not the same interface as a string containing a resource path. Confirm which one the widget expects.
For video, inspect source selection separately from play, pause and stop controls. Repeated source updates can cause some implementations to reload a clip. Check the documented behavior before binding a frequently changing value to the source property.
Keep media presentation separate from control commands and safety functions. Do not use successful playback as evidence that a machine is ready or safe to operate.
Know when to choose another approach
Choose a native image widget when the runtime supports the required format and the screen needs a straightforward diagram, photograph or state symbol. It avoids adding another presentation layer solely to show an image.
Choose a video widget only when playback is documented for the actual runtime and client. If it is unsupported, use a manufacturer-supported alternative rather than assuming an embedded browser or custom component will solve the problem. Those alternatives introduce their own deployment and maintenance requirements.
A static diagram or short sequence of images can be a better choice when motion adds little information. It is also easier to keep an instruction visible than to require the screen to wait for a particular video frame.
If the requirement is only to present notices or instructions away from machine controls, reconsider whether the content belongs inside the HMI at all. The distinction between a factory status display and an operator HMI helps define that boundary. A separate information display is not a replacement for machine interaction.
What to ask for before committing
Ask the runtime supplier or application integrator for a capability check against the actual target, not a general statement that the platform supports media. Include:
- Runtime name, version and target client.
- The required presentation: fixed image, state-selected image, collection or video.
- A representative file with its format and, for video, container and codec details.
- The intended resource location and deployment method.
- Whether selection is fixed, local or controller-driven.
- Required scaling, playback controls, audio and start behavior.
- The expected response to missing media or invalid selection.
- Results from the fixed-media check on the intended client.
Request the documented configuration route and any client limitations with the proposed solution. If custom work is necessary, ask what must be maintained when the runtime or client changes.
The decision is straightforward once these boundaries are clear: choose the widget that the target actually supports, establish resource delivery and rendering with fixed media, then add selection logic without changing the working presentation layer.
Questions
Which HMI widget should display images and video?
Use the widget documented for the required presentation. A fixed photograph generally needs an image element; a video needs a playback element. An image list may select one image or display a collection, depending on the runtime. Confirm its behavior rather than relying on its name.
Why does media work in the engineering preview but not on the deployed client?
The deployed client may use a different resource location, access policy or decoder. A path on the engineering workstation is not automatically available to the target. Try a fixed, documented-compatible resource on the target before investigating controller-driven selection.
Will changing a JPG extension to JPEG fix a blank HMI image?
JPG and JPEG commonly identify the same image-format family. Renaming the extension does not change the encoded image or repair a missing resource. Check the actual format, deployment location, widget visibility and the runtime's documented requirements.
How can you distinguish a media fault from a binding fault?
First confirm that a fixed resource works on the intended client. Then inspect the source value, binding type and mapping that generates the media reference. Compare that result with the working fixed reference. This keeps communications faults separate from delivery and decoding faults.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.