A Toolchest motor symbol in Vijeo Designer rejects Color animation because it arrives as a group or an image, not as a single shape. Color animation belongs to basic drawing primitives. The fix is to break the symbol down to its primitives, animate only the shape that forms the motor body, and regroup it. You keep the rounded library geometry without redrawing it in the Vijeo editor. WinCC flexible lets you recolor a library object directly. Vijeo Designer expects you to work one level down, inside the symbol.
Work through the checks below in order. Each check gates the next one.
Check 1: Vector group or bitmap in the Toolchest symbol
Before you start, place one instance of the motor symbol on a scratch panel. Leave your production screens untouched until the method is proven.
- Select the placed symbol and read the object type in the Property Inspector.
- Right-click the symbol and look for an enabled
Ungroupcommand.
| Reading | Meaning | Next check |
|---|---|---|
| Object is a group and Ungroup is enabled | Vector symbol built from primitives such as polygons, ellipses, and rectangles. Each primitive can carry its own animation. | Check 2 |
| Object is an image or bitmap and Ungroup is unavailable | Raster symbol. Its pixel colors are fixed and cannot be recolored at runtime. | Bitmap branch below |
Bitmap branch. A raster symbol offers three options:
- Stack one colored copy per state and switch between them with Visibility animation. This is the approach the manuals push you toward.
- Lay a semi-transparent or outline shape over the bitmap and put the Color animation on that shape.
- Swap to a vector symbol from another Toolchest folder.
Stacking copies works, but it has costs. Every state adds another image to the screen, and the visibility conditions must be mutually exclusive. If they are not, two copies render at once.
Check 2: The primitive that carries the motor body color
You need Check 1 to confirm a vector group first. Then do the following:
- Ungroup the symbol. Nested groups are common, so repeat until every item selects as a single primitive.
- Click each primitive in turn and note its fill color, fill style (solid or gradient), and line color.
- Find the one or two shapes that form the visible body, usually the largest filled polygon or rectangle. Separate them from the highlight, shadow, shaft, and terminal-box shapes.
| Reading | Decision |
|---|---|
| One dominant body shape with a solid fill | Animate its fill color only. This is the cleanest result. |
| Body built from several shapes, all the same color | Apply the same Color animation to each body shape, bound to the same variable. |
| Body uses a gradient to fake a 3D effect | Animate the body shape and leave the highlight shapes alone. Expect the gradient to flatten if the animated color overrides the gradient start color. Check this on the target in the last section. |
| Shape looks right but only its outline changes color | You animated line color instead of fill color. Correct it in the animation settings. |
Leave highlights and shadows unanimated. They keep the depth cue that made the library symbol worth using. They also cut the number of animated objects the panel has to evaluate on every refresh.
Check 3: Status signals and state priority
A motor shown as green when running and red on alarm has at least three states: stopped, running, and faulted. It can also be running and faulted at once. Choose the color source before you bind anything.
| Signal set available | Binding method |
|---|---|
| One boolean (run only) | Discrete Color animation: one color for OFF, one for ON. |
| Separate run and fault booleans | Build a state integer in the PLC and use integer Color animation. Alternatively, stack a second body shape driven by the fault bit. |
| Existing status word or integer | Integer Color animation with one color per value or range. |
A state integer is the recommended method. It resolves priority in one place, so a fault always overrides run. The placeholder names below are examples; substitute your own tags:
Without the priority logic, two independent animations on the same shape fight each other. The color you see then depends on which condition the panel evaluates last, not on the process state.
Color animation procedure on the motor body shape
Complete Checks 1 to 3 first. You need a vector symbol, an identified body primitive, and a color variable (boolean or state integer) that already exists in the Vijeo variable list and is linked to the PLC.
- Select the body primitive only. Confirm that the Property Inspector shows a single shape, not a group.
- Open the object's Animation settings and go to the Color animation page.
- Bind the variable. For a boolean, choose discrete type and set OFF to grey and ON to green. For the state integer, choose integer type and add one condition per value:
0grey,1green,2red. - Set the animation to act on fill color. Leave line color static unless you want a colored outline too.
- Optional: enable blink on the fault condition only, so an alarm stands out from normal running.
- If the body is made of several shapes, repeat steps 2 to 4 on each one with the same variable.
- Select all the primitives and regroup them. Confirm the animation settings still show on the body primitive when you drill into the group.
- Save the finished symbol to a user Toolchest folder so later motors start from the animated version.
- For each placed instance, rebind the variable to that motor's own state tag. Confirm the binding in the instance's animation settings.
Step 9 is where most errors come from. Copies of an animated group keep the original variable binding. Every pasted motor then follows the first motor until you rebind it.
Run-state verification on the simulator and target panel
Build and download only after every instance shows its own variable binding. Force each state from the PLC or the simulator and check the result before moving to the next one.
- Force the stopped state (
0, or boolean OFF). Confirm the body shows grey and the highlights keep their original shading. - Force the running state (
1). Confirm only the body shape turns green and no stray primitive keeps the old color. - Force the faulted state (
2). Confirm it shows red, and that it blinks if you enabled blink. - Set run and fault at the same time. Confirm the symbol shows red. If it shows green, the priority logic is missing or the fault animation sits below the run animation.
- Change the state of one motor only. Confirm that no other motor symbol on the screen changes color. If one does, rebind that instance.
- Disconnect the PLC link and watch how the symbol behaves when communication is lost. The last color must not be read as a live running indication. If it could be, add a communication-status indication next to the motor group.
- On the target panel, check gradient-filled bodies at normal viewing distance. Confirm green and red are still distinct from the symbol's own shading, and increase the contrast of the animated colors if they are not.
FAQ
What happens if I apply Color animation to the whole Vijeo Designer symbol group?
The group does not accept Color animation, so the option stays unavailable or has no effect. Ungroup the symbol down to single primitives, animate the body shape's fill color, then regroup. The animation stays on the member shape inside the group.
What happens if the motor is running and faulted at the same time?
With two independent Color animations on one shape, the displayed color depends on evaluation order, not on the process state. Drive a single state integer from the PLC with fault taking priority (2 red over 1 green), and bind one integer Color animation to it.
What happens if the Toolchest motor is a bitmap instead of a vector symbol?
Its pixel colors cannot change at runtime. Stack one colored copy per state and switch them with mutually exclusive Visibility animation, or overlay an animated shape on the bitmap. Using a vector symbol from another Toolchest folder avoids the problem.