A multistate bitmap that cycles on the seconds counter but freezes on your own count tag has a healthy display and an event sequence that never returns to its starting value. The Min/Max bounds sit in the steps of the Tag Event list in the Event Manager Database. Set the first count step to Min 0 and Max 1, end with a step that returns the count to 0, and the fan repeats.
A multistate bitmap fan that spins on the seconds counter but sits still on your own count tag has one fault: the count never returns to its starting value. The bitmap object and its images are fine. The fix lives in the Tag Event list in the Event Manager Database, where each step carries the Min/Max bounds that advance the count, and the last step has to write the start value back. On a four-frame fan that means a first step at Min 0 and Max 1 and a final step that returns the count to 0 with a Max of 3, which closes a 4-second loop at one advance per second. This page shows how to split the fault with the seconds counter, where the Min/Max settings sit, and the sequence that closes the loop.
Split the fault with the seconds counter
Name the two tags first. The bitmap in the failing setup read a count tag, count1, and it had been tested against the system second counter, the panel's own seconds value. That value advances once per second with no event configuration at all.
Point the bitmap at the seconds counter and run the project. Frames changing every second tell you the Multi-State Bitmap object, its image list and its tag connection all work.
Point it back at count1 and read the live value while the project runs. A value that sits still points to the event side. A value that changes while the image stays frozen points to the mapping side: the count is passing through values the bitmap has no state for, or the object reads a different tag than you intended.
Spinning on the seconds counter shows the display path can follow a changing value; it does not tell you the event list runs. Treat it as a test signal and move the animation back to the real count once the sequence works. A pulse that changes inside the project but never shows on screen fails the same way, as covered in why an R_TRIG pulse never shows on the HMI screen.
Symptoms and what each points to
Read this list against your project before you touch a setting.
- The seconds counter cycles the frames, count1 never moves. The bitmap works and the Tag Event list is not advancing. Go to the Event Manager Database.
- count1 changes but the image stays frozen. The count passes values with no matching bitmap state, or the object reads another tag. Compare the live values with the state list.
- The fan runs one pass and freezes on the last frame. No step returns the count to 0. Add the wraparound step.
- count1 never counts from a fresh start. The first step's Min/Max misses the tag's starting value. The known-good four-frame sequence began with Min 0 and Max 1.
- The demo import loaded but the fan still sits still. The imported sequence is connected to the demo's tag, so connect it to your own count tag.
Where Min/Max lives
Open the Event Manager Database and look in the steps of your Tag Event list. Min/Max is set per step, not on the list, which is why it is easy to miss. While you are there, confirm two things: the list acts on the same tag the bitmap reads, and its steps cover every value the bitmap shows.
If the count should tick from machine events instead of the panel's clock, the HMI can tally discrete inputs on its own, as shown in count discrete input events on an HMI without PLC edits.
Example: closing the count loop on a four-frame fan
Inputs. Four fan frames, one per bitmap state, numbered 0, 1, 2 and 3. The state count comes from the known-good setup this example is built from: its last Max was 3, which covers values 0 through 3, so four states and four frames. The first count step used Min 0 and Max 1. The final step returned the count to 0 with a Max of 3. The drive is the seconds counter, one tick per second.
Rule. A repeating animation needs a count that walks through every state value and a final step whose Max equals the top state and whose action writes the start value. With no write back, the count rests on the top state and the loop ends after one pass.
Arithmetic. The count walks 0, 1, 2, 3, then the final step writes 0, so the loop visits 4 states. At one tick per second each state lasts 1 s, so one full loop takes 4 x 1 s = 4 s, or 60 / 4 = 15 loops per minute. Drive the event at 2 ticks per second and the same loop takes 4 x 0.5 s = 2 s. That is the speed setting in practice: the event rate sets the fan speed, the Min/Max bounds set the route.
Result. count1 never rests on 3. The bitmap shows frame 1, frame 2, frame 3, frame 4, frame 1, and keeps cycling.
Decision. Close the loop whenever the bitmap has more than one frame: set the last step's Max to the top state, 3 for four frames, and write 0. A list that ends at Max 3 with no write gives one pass and a frozen last frame. Treat 0, 1 and 3 as the four-frame example's values; read your own bitmap's state list first and set the bounds from it.
Set the sequence so it returns to zero
- Record the bitmap's state values and the image on each, lowest to highest.
- Open the Tag Event list in the Event Manager Database and read every step's Min/Max.
- Set the first step to fire from the starting value: Min 0 and Max 1 when the count begins at 0.
- Set the final step's Max to the top state, 3 for four frames, and give it one action: write the start value, 0.
- Save, load the project to the panel and run it.
One warning worth its space here: the wraparound writes 0 into count1 every 4 seconds in the example, so anything else reading that tag sees it clear four times a minute. Keep the animation count separate from production totals; where a counter must be reset anyway, save the previous count before the reset so the history survives.
Recommendation: if the seconds counter spins the fan and count1 does not move, edit the event side first. Set the first Tag Event step to Min 0 and Max 1, end the list with a step whose Max is your top state, 3 for four frames, and whose action writes 0, then run at one advance per second until the 4-second loop repeats before you touch the speed.
Import the demo project as a recovery
The demo project in the design software, the running horse, holds a multistate sequence that works. When the event list cannot be rebuilt by hand, export the demo's project information and import it into your project. That path pulls a known-good sequence into the project when rebuilding it by hand stalls, and it carries the demo's speed settings with it.
Save a copy of your project before importing. Then open the imported bitmap and Tag Event list, read each Min/Max against your bitmap's states, and connect the sequence to your own count tag. Keep the imported objects that drive the animation and remove the rest so they never hide your logic. An import is a known-good starting point; it does not confirm that your tags and states match, so read the imported Min/Max values against your own bitmap before you rely on the animation.
Verify it at runtime
Run the project and watch count1, not just the picture. The tag should step through every state value and return to 0, and the image should follow it state for state. When the count advances but the image stays still, go back to the bitmap's state list. When the count never advances, go back to the Tag Event steps and their Min/Max windows.
Where the goal is the same spinning fan on a screen beside the machine instead of inside the HMI, an offline player that loops the exported frames from a memory card does the job; the shop-floor display section covers panels built for that spot.
Questions
Why does the fan follow the seconds counter but not my own tag?
The seconds counter is the panel's own clock value, so it advances every second without any event configuration. Your count tag moves only when a Tag Event step advances it and a later step returns it to the start. Following the seconds counter therefore shows the display path works and leaves the event list as the only suspect.
What happens if the count climbs past the top state?
The fan holds the last frame and the sequence stops, because no bitmap state matches a value above the top one and no step picks the count up again. That is the single-pass freeze: the list needs a final step whose Max equals the top state (3 for four frames) and whose action writes the start value, 0.
Can the animation count double as a production total?
No, not on the same tag. The wraparound writes 0 into the tag every cycle, so at one step per second with four states the tag clears every 4 seconds. Run the animation on its own count and keep totals on a separate tag; if a total must be reset anyway, save its previous value first so the record survives.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.