TP900 Comfort HMI Border Color Animation: TIA Portal V15.1 Workaround for PanelView Multistate Migration

When porting an Allen-Bradley PanelView (FactoryTalk View ME/SE) screen to a SIMATIC TP900 Comfort panel (catalog 6AV2 124-1JC01-0AX0) with TIA Portal V15.1, the WinCC Comfort/Advanced engineering system successfully animates the background fill and the text color of a screen object through the Appearance animation, but the border color, border style, and border width remain static design-time properties. This article documents the official TIA Portal V15.1 behavior, the field-proven visibility-layering technique used to replicate the AB Multistate Indicator border behavior, the Faceplate encapsulation variant, and the migration to Unified Comfort Panels where a JavaScript-based border color script becomes available.

1. Problem Definition: AB Multistate Indicator vs. WinCC Comfort

In FactoryTalk View Studio, the Multistate Indicator object exposes four independent animated properties per state: caption text, background fill color, border color, and border style (None, Raised, Sunken, Etched). A single tag value selects the active state and all four properties swap simultaneously inside a single HMI object instance.

In TIA Portal V15.1 (and V16, V17, V18, V19, V20) for WinCC Comfort/Advanced, the equivalent object — Symbolic I/O Field, Button, or Text Field — exposes the following animation categories in the object's Properties → Animations tab:

• Appearance (background fill color and foreground/text color only)
• Visibility
• Flashing
• Motion (X/Y position)
• Direct connection (for tag value display in Symbolic I/O Field)

Border properties (color, style, width) live in Properties → Appearance → Border. They are design-time constants. There is no border color entry in the Animations editor for Comfort Panels. This is consistent across all Comfort Panel SKUs (TP700, TP900, TP1200, TP1500, TP1900, TP2200 Comfort) and across all firmware revisions available for the TP900 Comfort at the time of writing.

2. Root Cause: Why Border Color Cannot Be Animated Natively

The Comfort Panel runtime image is generated by the WinCC Comfort compiler and stored in flash memory. Each screen object is serialized as a fixed object descriptor that includes a header, a property block, an animation block, and an event block. The property block is the static part and contains border color, border style, border width, font, alignment, and similar design-time attributes. The animation block contains a small, fixed set of trigger bindings for runtime-mutable properties: position (Motion), visibility (Visibility), and the two color channels exposed by the Appearance animation (background fill, foreground/text).

Border channels were never added to the Appearance animation block. The reason is the ARM Cortex-A8/A9 processor budget on the Comfort hardware: the appearance animation block is designed to handle a small fixed number of ARGB color channels and a tight update window between PLC tag acquisition cycles. Adding four more channels (top, right, bottom, left) would have increased per-object update latency on panels that already run at the edge of their scan budget. Consequently, the property block stores the border color as a 32-bit ARGB constant and the runtime update loop never touches it.

For comparison, design tools that target a graphics-rendering pipeline (Microsoft Publisher, web browsers) can swap border colors at runtime by mutating a single CSS-style property. See the Microsoft Publisher documentation on color fills, lines, and borders for a desktop-publishing analog. The conceptual structure — Format → Colors and Lines dialog, per-state border color — is similar to the Properties → Border panel in TIA Portal, but Publisher exposes per-state border color where WinCC Comfort does not. The CSS decomposition into border-top-color, border-right-color, border-bottom-color, and border-left-color shown in the MDN reference is exactly the kind of multi-channel model that the Comfort runtime update loop avoids.

3. Workaround 1: Visibility-Layered Objects (Recommended)

The most reliable, fully supported technique replicates the AB Multistate Indicator behavior by stacking N identical screen objects at the same X/Y coordinates and using a single Visibility animation per object to expose only the active state. The result is one visible object at any moment, with a static border color/style/width per state — functionally indistinguishable from a native multistate indicator.

3.1 Step-by-Step Procedure

1. Create N copies of the target object in the target screen. Position all copies at identical X and Y coordinates, with identical width, height, font, and text properties. In TIA Portal V15.1, use Ctrl+C / Ctrl+V or right-click → Duplicate on the screen canvas.
2. Configure each copy's border properties in Properties → Appearance → Border with the color, style (None / Solid / Dashed / 3D), and width (in pixels) required for its assigned state.
3. Open the Animations editor for each object. In TIA Portal V15.1, right-click the object → Properties → Animations.
4. Add a Visibility animation to each copy. Bind it to the source tag using a range or value comparison. For an INT HMI tag named StateTag driven by the PLC, the typical binding for four states is:

// Object 1 (state 0): visible only when StateTag == 0
StateTag >= 0 AND StateTag <= 0

// Object 2 (state 1): visible only when StateTag == 1
StateTag >= 1 AND StateTag <= 1

// Object 3 (state 2): visible only when StateTag == 2
StateTag >= 2 AND StateTag <= 2

// Object 4 (state 3): visible only when StateTag == 3
StateTag >= 3 AND StateTag <= 3

5. Set the default visibility of all but the first object to hidden (Properties → Appearance → Visibility = "hidden"). This ensures the screen renders correctly between project download and the first tag acquisition cycle.
6. Assign unique object names in Properties → Name (e.g., StateBtn_S0, StateBtn_S1, StateBtn_S2, StateBtn_S3). TIA Portal V15.1 emits a compiler warning when two objects on the same screen share a name, even if only one is visible at runtime.
7. Optionally bind the text of each copy to the same tag for state names, or to a separate string tag. The text animation runs on the symbolic I/O field's caption property and is independent of visibility.

3.2 Range Configuration Details

The Visibility animation in TIA Portal V15.1 supports both single-value matching and range matching. The single-value form (StateTag >= 0 AND StateTag <= 0) is more verbose than a direct equality test, but it is the form generated by the TIA Portal UI when the user clicks "Add range" with min = max = target value. Direct equality is internally optimized at compile time to the same machine code on the Comfort runtime.

For applications with more than eight states per indicator, consider using an integer with a negative "no state" sentinel value (e.g., -1) and binding all N visibility ranges to a single StateTag >= 0 AND StateTag <= N-1 check, with a fifth "off state" object that is visible when StateTag = -1 showing a generic gray border.

4. Workaround 2: Faceplate Encapsulation

For applications with many multistate indicators, encapsulating the visibility logic in a WinCC Comfort Faceplate reduces screen configuration time, centralizes the border color set, and enables per-instance configuration overrides through configurable Faceplate properties.

1. Create a new Faceplate in the TIA Portal project tree → Add new Faceplate. Name it MultistateIndicator.
2. Define the Faceplate tag interface: one INPUT tag of type INT named State (range 0..N-1).
3. Inside the Faceplate, place N stacked copies of the target object (Button, Text Field, Symbolic I/O Field) at identical coordinates within the Faceplate's local coordinate system.
4. Configure each copy's border color, style, and width as a static property inside the Faceplate.
5. Bind the Visibility of each copy to the State interface tag using the range grammar from Section 3.1.
6. Promote the border color of each copy as a Faceplate configurable property (right-click the border color field → "Create Faceplate property"). This exposes the color to the calling screen and allows the operator to override the default palette per instance.
7. Place instances of the Faceplate on each screen. The number of screen-level objects drops from N to 1 per indicator, regardless of state count.

Faceplates in TIA Portal V15.1 support up to 32 instances per screen, and the configurable property mechanism exposes border color to the screen-level configuration. For projects with more than 32 simultaneous indicators, multiple Faceplate variants with different state counts can coexist on the same screen.

5. Workaround 3: Migrate to Unified Comfort Panels (JavaScript)

If the project allows a hardware change, the SIMATIC HMI Unified Comfort line (e.g., MTP700 Unified 6AV2 130-7xxxxx-xxx2, TP900 Unified 6AV2 140-7xxxxx-xxx2) running TIA Portal V16+ with WinCC Unified engineering exposes a richer styling model based on the Unified JavaScript API. While the WinCC Unified Animations editor is still object-property-based and does not expose a dedicated "border color" animation, the scripting interface allows the following runtime approach on a single object:

// WinCC Unified – TP900 Unified firmware V16.0+
// Change border color of an SVG object at runtime
let shape = Screen.Items('MyButton');
shape.Style.BorderColor = 0xFF0000FF;  // ARGB: opaque red

This requires Unified firmware V16.0 or later and the panel variant must be the -xxx2 Unified SKU rather than the -xxx0 Comfort SKU. For installed bases with the TP900 Comfort (6AV2 124-1JC01-0AX0), the visibility-layering workaround remains the only TIA Portal V15.1-native path.

6. Comparison Table: AB Multistate Indicator vs. WinCC Comfort Equivalents

7. AB-to-Siemens Color Palette Mapping

FactoryTalk View Multistate Indicator border colors are typically defined in RGB or named-color terms. TIA Portal V15.1 uses a fixed palette of 32 standard colors plus a custom color picker. For projects where the AB color choice is critical, map common AB border colors to the closest TIA Portal standard palette entry:

8. Verification Procedure

1. Compile the project with Project → Compile → Software (TIA Portal V15.1 menu). Resolve any warnings about overlapping screen objects — TIA Portal warns when two objects occupy the same X/Y region. Suppress these in Options → Settings → Compile/Download → Suppress overlapping object warnings if the design is intentional.
2. Download to the TP900 Comfort via Ethernet (PROFINET) or PROFIBUS. Use the panel's transfer mode if the project is not yet running.
3. Start Runtime on the panel.
4. Force the source tag in the HMI tag table (Project → HMI tags → Tag table → right-click → Force) or via the connected PLC's watch table. Cycle the value 0, 1, 2, 3 for a four-state indicator.
5. Verify that only one copy of the object is visible at each value and that the border color, style, and width match the design intent for that state.
6. Toggle rapidly between states and observe the visibility transition. The Comfort Panel runtime updates visibility on the configured HMI tag acquisition cycle. The default is 1 second; lower it to 100 ms in the HMI tag's Properties → Acquisition cycle dialog for faster response if the source PLC updates the tag faster than 1 Hz.
7. Test edge cases: write a value outside the defined state range (e.g., 99) and confirm that all stacked objects are hidden, exposing the empty background. This is the default behavior when no visibility range matches.

9. Diagnostics and Troubleshooting Matrix

10. Performance and Memory Considerations

Each screen object in a TP900 Comfort project consumes flash memory for its compiled descriptor and a render-list slot at runtime. A four-state indicator built with four stacked buttons uses approximately 4× the screen-object budget of a single button. Key Comfort Panel resource limits to monitor:

• Flash budget for user program: TP900 Comfort firmware reserves approximately 4 MB for the compiled WinCC project (HMI tags, screens, logs, recipes, scripts). Stacked indicators multiply by N — plan accordingly.
• Max screen objects per screen: 400 objects per screen in firmware V15.x; the per-project limit is 4,000 objects total.
• Max animations per object: 50; no global project limit enforced in TIA Portal V15.1.
• Acquisition cycle resolution: minimum 100 ms; do not set lower than the source PLC's update rate or you generate redundant network traffic.

If project size approaches the per-screen or per-project object limit, consolidate multiple stacked indicators into a single Faceplate instance that is reused across screens with different instance property values. Faceplates collapse N stacked objects into 1 screen-level object, freeing the budget for additional screens.

11. Migration Checklist: PanelView Multistate Indicator → TP900 Comfort

1. Inventory all Multistate Indicator objects in the AB project. In FactoryTalk View Studio, right-click each screen → Properties → count indicators by tag and state count. Export to CSV for tracking.
2. Identify the tag data type and range for each indicator. PanelView Multistate Indicators accept BOOL (2 states), INT/DINT (up to 256 or 2^32 states), or STRING tags. The TIA Portal Visibility animation accepts comparison operators against INT, DINT, and REAL HMI tags. For STRING-based state selection, convert the STRING to a numeric lookup index using PLC logic before binding to the HMI tag.
3. Map AB border style enums (None, Raised, Sunken, Etched) to Siemens equivalents (None, 3D, Flat, static color). The AB "Raised" style maps best to the Siemens "3D" border style with width 2–6 pixels.
4. Map AB border colors to the TIA Portal color palette using the table in Section 7.
5. For each indicator, create N stacked objects on the destination screen with the static border color and style for each state, as described in Section 3.
6. Configure the Visibility animation on each, bound to the migrated HMI tag.
7. Validate the tag connection by forcing values from the PLC watch table or the HMI tag simulation table. Verify each state visually.
8. Document the workaround in the project documentation so that future maintainers understand the multi-instance pattern and do not mistake it for a duplicate-object bug.

12. Z-Order and Stacking Considerations

When N screen objects share identical X/Y coordinates, only the topmost object in the Z-order list is rendered. In TIA Portal V15.1, the Z-order is the order in which the objects were added to the screen, topmost last. Use Edit → Arrange → Bring to Front or Send to Back to reorder. Place the most frequently visible state on top to minimize runtime redraw cost.

If two or more stacked objects have visibility ranges that could simultaneously be true (e.g., a configuration error), the topmost object wins. This is a debugging tool: if the wrong state appears when a borderline tag value is set, check the Z-order and the range bounds for overlap.

13. FAQ