Confirm that your installed display editor and runtime provide a documented local animation mechanism. Start with a supplied sample or supported basic symbols, identify every dependency, and check the behavior in an isolated project without treating decorative motion as machine status.
Standalone display animation is possible when the display application provides its own documented animation mechanism, without needing a PLC tag to advance it. Check that capability in the documentation for your installed editor and runtime before changing controller logic. An image object that supports changing appearance from a tag is not necessarily a locally animated object. The distinction is where the animation gets its timing and state.
What standalone animation means
A standalone animation gets the information needed to progress from the display application itself. Depending on the software, that might involve a local timer, an internal variable, a supplied animated object or a supported media file. These are possible implementations, not features you should assume every application includes.
A PLC-driven animation is different. The display reads controller values and uses them to change an object's position, visibility, color or image. Even if all drawing happens on the display, the behavior still depends on the controller supplying those values.
There is also a mixed case. A controller value might start an animation while the display handles its subsequent movement locally. That reduces the controller's involvement, but it is not independent of the controller for its starting condition.
Write down which behavior you need:
- A decorative loop that starts when a page opens.
- A local demonstration that runs without a controller connection.
- An animation started by a local button.
- A visual response to an actual machine condition.
The first three may suit standalone behavior if the application supports them. The last requires a trustworthy source for the condition, even when the motion itself is generated locally.
How to confirm support in your installed software
Check the editor version and the runtime version separately. A feature described in a newer manual does not establish support in an older installation. Likewise, an editor preview does not establish that the deployed runtime supports the same object.
Use the manufacturer's documentation for the exact release. Search for terms such as standalone animated objects, local animation, internal variables, animation timers and sample objects. Download manuals and examples only from the manufacturer or its authorized distributors.
The useful evidence is a documented object or mechanism that supplies both the animation behavior and its required inputs locally.
| What the documentation shows | What it establishes | What still needs checking |
|---|---|---|
| A standalone animated object | An intended local animation feature | Supported runtime versions and required settings |
| Animation linked to controller tags | Appearance can follow external values | Whether a local input can replace those tags |
| An internal timer or variable | A possible local source of changing values | Whether the chosen object's properties accept that source |
| A supplied animation example | A concrete implementation to inspect | External references, scripts and dependencies |
| An animated-media object | A way to play supported animated content | File support, looping and start behavior |
Do not infer support from a similarly named feature in another application. Object names can look familiar while their timing, triggers and runtime requirements differ.
Where sample objects help
A supplied sample is often the clearest starting point because it shows how the application's own objects fit together. Choose an example for its behavior, not just its appearance.
Inspect the sample before copying it into a production project. Look for controller addresses, communication drivers, internal variables, scripts and references to other pages. A sample that moves on screen might still rely on a changing value supplied elsewhere.
Keep the original example unchanged and work on a copy. First establish the documented behavior with as few modifications as possible. Then change the artwork, dimensions or other supported properties one at a time. This separates a capability problem from a customization problem.
A useful sample should help answer three questions: what starts the animation, what advances it and what stops or resets it? If any answer is unclear, return to the documentation before treating the object as standalone.
When basic symbols are a better fit
Basic symbols can be useful when a supplied example has the right mechanism but the wrong appearance. You might combine simple shapes into a grouped symbol, or use supported visibility changes to represent successive visual states.
However, drawing several shapes does not create animation by itself. The application still needs a documented way to change their properties over time. Confirm that the relevant properties can use local values rather than requiring controller tags.
Keep the first custom symbol simple. Use a small set of clearly distinguishable states and check their order before adding visual detail. Also confirm how grouping affects the animation. Some applications expose properties on individual elements; others attach behavior to the group or to a dedicated object.
If the requirement is only a repeating illustration on a notice board, a supported video or animated-media object may be more appropriate than constructing a symbol from many elements. That is a content-playback decision, not evidence that the application supports animated control objects. For the separate question of how smooth that content needs to look, use the guide to signage animation frame rate.
How to check that the behavior is local
Use a separate bench project or the manufacturer's documented offline or simulation environment. Do not interrupt communications on a running machine merely to investigate an animation feature.
Inspect configuration as well as visible movement. The absence of a PLC connection is useful evidence, but it does not explain whether a cached value, simulated tag or local script is driving the object.
Check these points in the intended runtime:
- Starting condition: Does the object start from a page event, a local action or an external value?
- Progression: What changes the state or position on each update?
- External references: Does the object reference any controller addresses or communication-dependent scripts?
- Page changes: Does leaving and reopening the page restart, resume or reset it?
- Application launch: Is the initial state documented and suitable for the intended use?
- Deployment: Are all required objects, files and runtime features included?
Record the application versions, object type, local inputs and observed behavior. This gives you a repeatable acceptance check after later project changes. If the runtime differs from the development environment, repeat the check there rather than relying only on the editor preview.
Keep local movement separate from machine status
A rotating shape or moving flow arrow can look like evidence that equipment is operating. Standalone animation provides no such evidence unless a separate, valid status source controls its meaning.
Use local loops for demonstrations, instructions or decoration. Label a demonstration clearly, and avoid making decorative movement look like a live process indication. A locally animated pump symbol, for example, must not imply that a physical pump has started.
Where motion represents equipment status, define what happens when that status is unavailable. A neutral or unavailable indication is more informative than an apparently healthy animation with no current data. None of these visual choices replaces a machine safety function.
If the real requirement is to show machine conditions or accept control actions, the distinction between a factory status display and an operator HMI matters more than the choice of animated symbol.
The practical decision is straightforward: confirm a documented local mechanism, identify every dependency, and prove the intended behavior in an isolated project. Use a supplied sample when it matches the job. Build from basic symbols only when the application documents how to animate them without controller inputs.
Questions
Can a display animate an object without PLC logic?
Yes, if the display application provides a documented local animation mechanism. That might be a standalone object, a local timer or another supported feature. Confirm support for the installed editor and runtime versions, then inspect the object's inputs to establish whether any controller values are required.
Does an animated image object always support standalone operation?
No. An object may support animation only through properties linked to controller tags. To operate independently, it needs a supported local source for the values that advance the animation. Check the documented triggers, timing mechanism and runtime requirements rather than relying on the object's name.
Should I use a sample object or build an animation from basic symbols?
Start with a supplied sample when its documented behavior matches the requirement. Inspect its dependencies before adapting it. Basic symbols are useful for a custom appearance, but they still need a supported local mechanism to change position, visibility or other properties over time.
Can standalone animation be used as proof that a machine is running?
Not by itself. Locally generated motion does not establish the condition of physical equipment. A machine-status indication needs a valid status source and a defined response when that information is unavailable. Keep decorative or demonstration animation visibly separate from operational indications.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.