Leave the multistate state that should hide the object with no graphic selected: the state stays null, the object draws nothing, and the panel background shows through. For states that each draw a graphic, build every file on one shared canvas size in pixels so alternate states land in the same place. Drop the panel-colored bitmap cover; it draws as bars, not a fill.
When an object on an HMI panel has no .visible data member, you can still make it disappear. Put its graphic in a multistate object, drive the states from a switch or a tag already on the panel, and leave the hiding state with no graphic selected. That state stays null, the object draws nothing, and the panel background shows through. Drop the panel-colored cover idea first: a BMP repainted one flat grey drew as a few grey bars and left the area uncovered, with its outer size matched to a graphic that worked.
What the color-matched cover does on a real panel
The cover plan looks right at first: show a bitmap the same color as the panel over the object, and the object seems gone. Two things break it. A repainted file drew only a few grey bars across the graphic's area, and matching its outer size to a stock graphic changed nothing, so file dimensions tell you nothing about what a recolored file draws inside. And the drawn symbol that suited the job, a pipe, offered no transparent selection to work with.
| What you see | What it points to | What to do |
|---|---|---|
| A repainted one-color BMP draws a few grey bars over part of the area | The file's drawn content fills its canvas differently than the panel needs | Switch to a null state |
| The object stays visible when the condition changes | The active state still has a graphic selected, or the condition value never moves | Read the tag value, then check which state that value selects |
| Alternate states jump or leave a stale edge | The state files have different canvas sizes | Rebuild every state on one shared canvas |
What you need
- A multistate object: an object whose displayed graphic is picked by the value of a tag or the position of a switch.
- A condition already on the panel: one discrete switch for show and hide, or one integer tag when each value picks a different drawing.
- Your artwork files, with the full canvas size of each one known in pixels before import.
- A way to run the panel and change that condition, so you can watch every state draw.
Set the hiding state to null
- Check the object for a visibility data member such as
.visible. If it has one, use it; that is the documented control and the shorter path. The multistate route is for objects without it, and text fields have their own route in hiding static text on an HMI panel with no visibility tag. - Never route an alarm or safety indication through this method; anything operators need in every state stays visible in every state.
- Replace the static graphic with a multistate object at the same position, sized to the artwork's canvas.
- Connect the state condition to something already on the panel: a switch for two states, or an integer tag where each value picks a state, the pattern in showing multiple color states on an HMI from one integer tag. For a single bit driving two states, showing two text states on an HMI from one PLC bit covers the same tag-side wiring.
- In the state that should show the graphic, select the graphic file.
- In the state that should hide it, select nothing. Leave the selection empty so the state reads null. Build no grey or panel-colored file for this state; empty is what does the work.
- Write down the two values: which condition value shows the graphic, and which leaves the state null. You test against those numbers.
Keep every visible state on the same canvas
When two or more states each draw a graphic, every file gets the same overall canvas. Build each state by copying one file and repainting inside it: where a state should look shorter or partly empty, repaint the unwanted linework in the panel background color and leave the canvas alone. Never crop a state file to its apparent shape; the cropped drawing lands somewhere new the moment the state changes.
Before import, compare the full pixel dimensions of every file in the set, width and height. They must match. A multistate that cycles frames can stall for reasons of its own; that fault and its counter are covered in multistate bitmap fan animation counter not cycling.
Example: one cylinder, three states, one canvas
A packaging machine cylinder shows rod position from an integer tag: 0 selects OUT, 1 selects mid, 2 selects IN. All three files are built on a 64 x 96 pixel canvas.
- OUT draws the barrel 64 px wide by 60 px tall, plus the extended rod 36 px tall. 60 + 36 = 96 px of drawn height, so the drawing fills the canvas exactly.
- IN starts as a copy of OUT. Repaint the rod's 36 px in the panel background color. The visible drawing shrinks to 64 x 60 px while the file stays 64 x 96 px, so the barrel sits where it sat in OUT.
- MID repaints 18 px of the rod, half of 36, and keeps 18 px drawn. Same 64 x 96 px canvas, and the rod reads as half extended.
The same panel hides a banner with the null method. A wash-cycle switch drives a two-state multistate: state 0 selects a 320 x 60 px wash banner, state 1 selects nothing. Closing the switch leaves the state null and the banner vanishes, panel background in its place. The whole job takes four files: three cylinder states at 64 x 96 px and one banner at 320 x 60 px, with no color-matched artwork anywhere.
How to check it worked
- Drive the cylinder tag 0, 1, 2, then back 2, 1, 0: four state changes, and every drawing stays put with no jump and no stale edge.
- At the null state, confirm the panel background shows where the banner was, with no border, frame or leftover drawing.
- Check the neighbors. A disappearing object uncovers whatever sat behind it; make sure that was meant to show.
- Compare each file's full pixel dimensions before import: the three cylinder files match at 64 x 96 px.
- Run the test on the operating panel with the real condition changing, where operators will see it, not only in the editor with a forced value.
Recommendation: use a null state whenever an object should vanish in one condition and return in another; it needs no artwork, no color match and no transparency option. Where several states each draw a graphic, build every file on one shared canvas, 64 x 96 px in the example, and repaint the differences inside it. Drop the panel-colored cover; it is the approach that draws as bars instead of a fill.
Questions
Why does leaving a state's graphic empty hide the object?
A multistate object draws only the graphic assigned to its active state. With no graphic selected the state is null, so there is nothing to draw and the panel background shows through. The object stays in place on the panel, so the moment the condition selects a state with a graphic, the drawing returns without any rebuild.
My repainted panel-colored bitmap shows as grey bars. Should I fix the file?
Replace the cover with a null state. The reported failure kept the file's outer size matched to a graphic that worked and still drew only bars, so file dimensions tell you nothing about what a recolored file draws inside. If a cover must stay for some other reason, verify its full coverage in the running panel and keep the original file so you can go back.
Do null states also need the same-size canvas rule?
No. The shared-canvas rule exists so drawings from several visible states land in the same place. A null state contributes no image, so there is nothing to align. Give every visible state one canvas size, in pixels, and leave the hiding state empty.
Can I hide any object this way?
Only the multistate object itself. The method swaps a static graphic for a multistate whose hiding state is null, so what you hide is that multistate's drawing. For a text field, use the static-text route. If the object exposes a `.visible` data member, use that member; it is the documented control.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.