Use a small set of native rectangle objects and animate their geometry and visibility from pallet-pattern data; do not place all 190 images on the display. Size each pallet template for the maximum number of cartons simultaneously visible on its top layer, then let the selected recipe and placement state drive the objects. This changes the design from selecting among pre-rendered pictures to rendering the current pallet state.
How do the symptoms identify the bottleneck?
The FactoryTalk View ME version 11 application contains 19 recipes, five progress images per recipe, and two displayed pallets. That produces 95 images per pallet and 190 image objects across the display when every state is overlaid and controlled by visibility.
A long display-open time points to display construction and resource loading, not pallet-sequence logic. Hiding an object changes what the operator sees after evaluation; it does not remove that object from display initialization. Every embedded image still adds an object, a resource reference, and an animation expression that the PanelView Plus must process.
Confirm the diagnosis by copying the display and replacing the image stack with a few static rectangles. Compare display-open time using the same navigation path and running application. If the simplified display opens promptly, the image and object count is the controlling variable.
Why is geometry-driven animation faster?
A native rectangle represents a carton with a small set of changing properties: width, height, horizontal position, vertical position, rotation, and visibility. The controller or recipe data describes those properties, while FactoryTalk View ME draws the result. Changing a tag value updates an existing object instead of selecting another full pallet image.
Count objects by the maximum cartons visible at once, not by the number of recipes or saved pictures. The example progress states show 2, 4, 6, 8, and 10 cartons. If each robot placement adds two cartons, five placement events still require as many as ten visible rectangle objects per pallet. If one placement corresponds to one carton, five objects may be sufficient. Read the robot sequence and count the maximum simultaneous top-layer cartons before building the template.
Two pallets require two rendered object sets if both are visible together. Even at ten objects per pallet, the display contains 20 carton objects rather than 190 pre-rendered pallet states.
What data should drive the pallet display?
Follow the signal chain. The selected recipe chooses a pattern, the pallet sequence identifies the current layer and completed placements, and the pattern record supplies the geometry for each carton slot. Each display object consumes one slot record and becomes visible only when that slot is occupied.
| Signal | Source | Wrong-value symptom |
|---|---|---|
| Selected recipe | Machine recipe selection | Every carton follows the wrong layout even though the count advances correctly |
| Current layer | Palletizing sequence | Count appears correct, but the displayed arrangement belongs to another layer |
| Completed placement or occupied slots | Robot or PLC sequence state | Graphic leads, lags, or skips cartons |
| Width and height | Pattern data for each carton | Position is correct, but the carton footprint is wrong |
| X and Y position | Pattern data for each carton | Cartons overlap, shift, or appear outside the pallet |
| Rotation | Pattern data for each carton | Carton position is correct, but orientation is wrong |
| Pallet side | Robot sequence or pallet-state selection | One pallet displays the other pallet's progress |
On a 5000-class controller, a structured design can use a type such as Layer_Data for carton geometry and a type such as Box_Pattern for the layers belonging to a pattern. An array of patterns then lets the active recipe select the required geometry. These names are organizational examples; the important relationship is recipe to pattern, pattern to layer, and layer to carton slots.
If recipe data resides in the HMI, keep the same relationship and transfer the active pattern values into the animation tags. PLC ownership is preferable when the PLC already owns recipe selection and pallet progress because the graphic then reads one coherent machine state.
How should the animated template be built?
Record the maximum carton count on any visible top layer across all 19 recipes. Include both orientations and every layer-pattern change. Create that many rectangle objects for one pallet; reserve additional objects only when a defined future pattern requires them.
Choose one display coordinate system for the pallet area. Convert each carton's SolidWorks footprint into display width, height, X position, and Y position using the same scale and origin. Treat rotation as separate pattern data.
Bind every rectangle's width, height, horizontal position, vertical position, rotation, and visibility animations to its corresponding slot data. Use direct tags where practical. Expressions are useful for coordinate scaling, but keep conversion logic identical for every slot.
Drive visibility from actual occupancy. When the loading order never changes, a completed-placement count can expose slots in sequence. When placements can be retried, skipped, cleared, or completed out of order, use a separate occupied state for each slot so the graphic follows physical state rather than an assumed sequence.
Build and test one recipe and one pallet first. Validate all progress states and every layer before copying the template to the second pallet.
Duplicate the tested object set for the other pallet and change only its data reference. Keep the drawing scale, origin, and animation formulas identical so a graphical difference represents machine state rather than display construction.
How do you verify the result?
Look at the tag trend first. Observe recipe selection, current layer, placement count or slot occupancy, and the associated geometry while the palletizer advances. The displayed change must follow the controller state once per actual placement, with no transition caused solely by opening the display.
Test the smallest and largest patterns, both pallets, every carton orientation, and any recipe that alternates layer patterns. Compare the display with the saved SolidWorks views at empty, intermediate, and full-layer states. Check display-open time from another screen as well as animation response while the robot sequence is running.
For a wrong graphic, isolate the first incorrect point in the chain. Correct recipe with wrong geometry means the selected pattern record is wrong. Correct geometry with wrong visibility means the placement or occupancy state is wrong. Correct tags with a wrong drawing means the animation binding, scale, origin, or rotation mapping is wrong. Animation tuning does not repair an incorrect tag binding.
Which pitfalls recur on this design?
Do not equate five saved progress images with five required objects. The pictures represent five states, while the full state contains ten cartons in the stated example. Under-counting objects makes later progress impossible to draw without returning to composite images.
Avoid uncontrolled indirect addressing when the controller cannot use the proposed structured types. Flat registers can implement the same pattern, but validate every recipe, layer, slot, and pallet index at its boundaries. One incorrect index can produce a plausible graphic from the wrong pattern, which is harder to detect than an obviously invalid display.
Do not mix coordinate conventions between recipes. A center-based coordinate in one pattern and an edge-based coordinate in another creates repeatable offsets that resemble bad PLC data. Keep one origin, one unit conversion, and one rotation convention for the entire application.
Finally, do not make the HMI infer machine completion from the picture it has drawn. The controller remains the source of truth; the display only presents recipe, layer, and occupancy state.
FAQ
What happens if each robot placement adds two boxes?
Five placement states can produce ten visible cartons. Create objects for the maximum simultaneous carton count and use the placement state to reveal the appropriate pair.
What happens if recipes use different box sizes and orientations?
Store width, height, X position, Y position, rotation, and visibility data for every carton slot in each pattern. Recipe selection changes the geometry values; the same rectangle objects remain on the display.
What happens if boxes are not always loaded in the same order?
A cumulative box count can show the wrong slots. Drive each rectangle from an occupied-slot state so retries, skipped placements, and alternate sequences remain visible correctly.
What happens if the display is still slow after replacing the images?
Test a minimal display with the same animated objects and tags, then check navigation time, expression complexity, communications, and runtime diagnostics. Stop changing pallet logic when the minimal display is also slow or when valid controller values do not reach the animation properties. Escalate with the application, runtime diagnostics, terminal details, and repeatable test steps through official Rockwell Automation technical support.