A drawing of a valve on a screen is only useful if it can show whether the valve is open or closed, and a tank outline means little unless it shows how full the tank actually is. That living quality comes from dynamic graphic objects: symbols bound to live process data so their appearance changes as the process changes. This guide explains what a dynamic graphic object is, how it differs from a static drawing, the common animations it performs, and how its data bindings and animation links are set up.
Dynamic graphic object in one line: A dynamic graphic object on an HMI is a graphic element bound to live tags so that its appearance changes with the process, for example changing colour with a state, filling with a level, rotating with a position, or appearing and disappearing with a condition. It differs from a static object, which is a fixed drawing that never changes, in that its look is driven by real-time data through configured bindings called animation links.
Every HMI screen contains a mix of two kinds of graphic. Static objects are fixed drawings that never change once the screen is built: the pipe outlines, the vessel shapes, the labels, the frames, and the background schematic that give the screen its structure. They orient the operator and show how the equipment is connected, but they carry no live information because nothing about them responds to the process. They are, in effect, the map on which the live data is drawn.
Dynamic objects are the parts of that map that come alive. A dynamic object is bound to one or more tags, and some aspect of its appearance is driven by the values of those tags, so as the process changes the object changes with it. The valve symbol that turns to show it has opened, the tank that fills as its level rises, the motor that changes colour when it starts, and the pressure readout that updates its digits are all dynamic objects. Without them a screen would be a static diagram; with them it becomes a live window onto the plant.
The distinction is not always obvious to look at, because a dynamic object sitting in its default state can look identical to a static one. The difference is in the wiring behind it: a dynamic object has bindings that connect its properties to live data, so it will respond when the data changes, while a static object has none and will look the same forever. A well-built screen uses static graphics for structure and reserves dynamic behaviour for the elements that genuinely carry process information, so that movement and colour on the screen always mean something.
The most common dynamic behaviour is state colour. An object is bound to a discrete state, such as running or stopped, open or closed, or normal or faulted, and it changes colour to reflect that state, so an operator reads the equipment's condition from its hue. In high-performance HMI practice this is used carefully, with quiet colours for normal states and strong colour reserved for abnormal ones, so that a coloured object draws the eye only when something needs attention. This single animation carries much of the situational awareness a screen provides.
Fill animations tie an object's appearance to an analog value. The classic example is a tank whose fill level rises and falls with the measured level, giving an immediate picture of how full it is, but the same idea applies to bar-style fills for any analog reading. Rotation and position animations map a value to movement: a valve stem, an actuator, or a rotor can turn to reflect a position, and a needle or pointer can move to reflect a reading. These animations work because the shape or motion directly mirrors the physical quantity, so the operator reads the value as geometry.
Visibility and blinking are two more common behaviours, used with restraint. Visibility animation shows or hides an object depending on a condition, so a warning symbol appears only when it is relevant or a piece of equipment is shown only in the mode where it matters, which keeps the screen uncluttered. Blinking or flashing is a strong attention cue usually reserved for unacknowledged alarms, because anything that flashes constantly quickly becomes noise. Text and value animations, where an object shows a live numeric or textual value, round out the common set, and most real symbols combine several of these behaviours at once.
A dynamic object comes alive through bindings, sometimes called animation links, which connect a property of the object to a source of data. Configuring one means choosing which property to animate, such as fill colour, fill level, rotation angle, or visibility, then choosing the tag or expression that drives it, and finally defining how the data maps to the property. For a colour animation that mapping is a set of rules, such as this state gives grey and that state gives red; for a fill it is a scaling from the value's range to a fill percentage; for a rotation it is a mapping from a value to an angle.
In most HMI tools these bindings are configured rather than programmed, through dialogs that let a builder pick the property, the tag, and the mapping, so building a dynamic object is a matter of setup rather than writing code. When dynamic objects are combined with a symbol library, the bindings are usually defined once on the master symbol against placeholder tags, and each instance simply supplies its own real tags, so the animation logic is written once and reused across every copy. This is what lets a single well-built pump symbol behave correctly everywhere it is placed.
A cloud SCADA platform such as Merobix drives dynamic objects from the live tag values it collects from each remote site, so a valve, tank, or motor on a screen reflects the real state of equipment that may be far away. Because the data flows through one central system, the same dynamic symbol shows the same behaviour whether an operator views a site from a control room or from a phone in the field, and the bindings defined on a standard symbol apply consistently across every site in the fleet. For a distributed operation, that means the living, data-driven screens that make an HMI useful extend uniformly to sites nobody is standing next to, driven by the same central data and the same reusable animation logic.
A static object is a fixed drawing, such as a pipe outline or a label, that never changes once the screen is built and carries no live information. A dynamic object is bound to live tags so some aspect of its appearance, such as colour, fill, rotation, or visibility, changes with the process data. The difference is in the bindings behind the object rather than always in how it looks at rest.
Common ones are state colour, where the object changes hue to show running or stopped, open or closed, or normal or faulted; fill, where a tank or bar fills with an analog value; rotation and position, where movement mirrors a physical position; and visibility and blinking, which show, hide, or flash an object under a condition. Most real symbols combine several of these at once, along with live text or numeric values.
In most HMI tools bindings are configured rather than coded, by choosing the property to animate, the tag or expression that drives it, and how the data maps to the property, such as which states give which colours or how a value scales to a fill. When dynamic objects are part of a symbol library, the bindings are defined once on the master symbol against placeholder tags, and each instance supplies its own real tags.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.