Multiplexing Siemens TIA Faceplates for Multiple Valves

Overview

Siemens TIA Portal faceplates are reusable HMI display objects that bind to a single PLC data block (DB) instance. By default, every time you drop a valve Function Block (FB) into a network, the compiler creates a unique instance DB, and a faceplate dropped on a screen binds to that DB. In a plant with 40 identical valves, this forces the engineer to create 40 faceplate instances on the HMI, each pre-bound to a different DB, and to open a different popup screen for each one. The result is a large, hard-to-maintain HMI project.

Faceplate multiplexing replaces that 1:1 binding with a 1:N binding. A single popup screen hosts one faceplate. A runtime-mutable HMI tag points the faceplate at whichever valve's instance DB the operator has selected. When the operator taps valve 27, the multiplexing tag is loaded with the DB number of valve 27, the faceplate re-reads its tags from that DB, and the popup shows valve 27's data. No recompile, no duplicate faceplates.

Multiplexing has been available on WinCC Comfort/Advanced on and off since the original TIA Portal releases. It was not supported in some intermediate versions, was reintroduced in TIA V14, and remains a documented feature through TIA V20. The mechanism is firmware-dependent: the HMI panel or PC Runtime must support the multiplex tag type, and the PLC block holding the valve data must be accessible by absolute address (non-optimized, or the multiplex tag must point to a non-optimized wrapper).

Prerequisites

Verify the installed TIA Portal version under Help > Installed Software. Identify the HMI panel firmware under Devices & Networks > [HMI] > Device Information > Diagnostics after going online. Identify the PLC firmware under Online & Diagnostics > CPU Information.

Faceplate Concept and Architecture

A faceplate in TIA Portal is a screen fragment (a self-contained group of HMI objects) that exposes a typed interface. When you add the faceplate to a screen, TIA instantiates the interface and asks you to bind the interface tags to real PLC tags. In the standard (non-multiplexed) flow, you bind once at design time and the binding is fixed in the compiled HMI project.

The official Siemens documentation describes the intent of faceplates: "Ideally, you should use faceplates for plant objects that exist several times and have identical data structures, such as valves, motors, tanks." See the Siemens TIA Portal V20 WinCC Unified faceplate basics for the Unified variant; the underlying principle is identical on Comfort/Advanced.

The key engineering difference between the standard and multiplexed pattern is when the binding is resolved:

Standard Instance-DB Approach (Baseline)

Establish a baseline project before introducing multiplexing. The following steps reproduce the "FB creates an instance DB every time" behavior from the field report.

1. Create a project with an S7-1500 CPU and a Comfort Panel (e.g. KTP1200 or TP1500).
2. Add a new FB called ValveCtrl_DB with the following interface tags:
   • Input OpenCmd : Bool
   • Input CloseCmd : Bool
   • Output Opened : Bool
   • Output Closed : Bool
   • Output Fault : Bool
   • Static PositionFB : Int (0..100)
3. Drop the FB into OB1 (or a cyclic OB) three times. The compiler automatically creates DB10 ValveCtrl_DB_1, DB11 ValveCtrl_DB_2, DB12 ValveCtrl_DB_3.
4. Open the HMI, add a screen called ValveOverview. Add three button objects representing the three valves.
5. Create three separate popup screens (Popup_Valve1, Popup_Valve2, Popup_Valve3), each containing a copy of the valve faceplate bound to the matching DB.

This baseline is functional but is the pattern multiplexing exists to replace.

Multiplexing Architecture

Multiplexing introduces an extra HMI tag of type Int (or DInt for large DB counts) that holds the DB number. The faceplate's interface tags are bound not directly to DB10.OpenCmd, but to "<MultiplexTag>".OpenCmd using the tag prefix syntax. At runtime, the HMI engine dereferences the prefix against the actual DB number and reads/writes the matching offset.

The diagram shows one faceplate in the popup reading from whichever DB the MultiplexTag currently holds. The button events in the overview screen change that tag to switch the binding.

Step-by-Step: Multiplexing a Single Faceplate Popup

Step 1 — Convert the valve DBs to non-optimized (or expose them for HMI access)

Open each instance DB in the project tree. Right-click → Properties > Attributes. Uncheck Optimized block access. If the project uses an S7-1200/1500 and you must keep optimization, instead enable Accessible from HMI in the same attributes tab and note that the multiplex tag must still be configured against an absolute DB number.

Step 2 — Add the multiplex HMI tag

In the HMI project tree, open HMI Tags > Default Tag Table (or a new table). Add a tag with the following properties:

Step 3 — Create one faceplate that references the multiplex tag

1. Right-click the HMI → Add New Faceplate. Name it ValveFaceplate.
2. Open the faceplate and add the valve-specific graphics: two push buttons (Open, Close), four indicators (Opened, Closed, Position, Fault).
3. Open the faceplate's interface (right-click → Interface). Add interface tags that match the PLC DB layout: OpenCmd (Bool), CloseCmd (Bool), Opened (Bool), Closed (Bool), Fault (Bool), PositionFB (Int).

Step 4 — Bind the faceplate interface tags using the multiplex prefix

When you drop the faceplate on the popup screen, TIA prompts for tag bindings. Instead of binding to a fixed DB, use the prefix syntax:

OpenCmd     := "<ValveDB>".OpenCmd
CloseCmd    := "<ValveDB>".CloseCmd
Opened      := "<ValveDB>".Opened
Closed      := "<ValveDB>".Closed
Fault       := "<ValveDB>".Fault
PositionFB  := "<ValveDB>".PositionFB

The literal <ValveDB> is the placeholder. At runtime, the HMI substitutes the current integer value of the ValveDB tag (e.g. 11) and the binding becomes DB11.OpenCmd.

Step 5 — Wire the overview buttons to write the DB number

On the overview screen, configure each valve button. Under Events > Click, add the function SetTag:

Use the DB number that TIA assigned when the FB was instantiated. The numbers are visible in Project Tree > PLC > Program Blocks > System Blocks > Program Resources, or via the cross-reference.

Step 6 — Open the popup on button event

On the same Click event of each overview button, append the function ActivateScreen:

ActivateScreen
  Screen name : "Popup_ValveFaceplate"
  Mode        : "On"
  Number      : 0

The popup opens, the faceplate inside it reads from the DB whose number was just written into ValveDB, and the operator sees the correct valve.

UDT Constraints and Optimized Block Access

The field report flagged a specific compile error: "TIA Portal says that multiplexing is not possible because I'm using a UDT." This is a real, documented constraint, not a misunderstanding.

UDT (User-Defined Type) instance DBs in TIA V14+ are optimized by default. The compiler embeds the UDT layout in the symbol table but hides the absolute byte offsets from the rest of the project. The multiplex prefix syntax <Tag>.Member requires the engine to compute DB<n>.Byte<offset>.Bit<bit> at runtime. With optimization, the offset is opaque, and the compiler rejects the binding.

Workarounds, in order of preference

1. Disable optimized block access on the UDT instance DB. This is the most direct fix. Open the DB → Properties > Attributes > Optimized block access → uncheck. The DB now exposes absolute offsets and the multiplex binding compiles.
2. Create a non-optimized "shadow" DB per valve that mirrors the UDT structure using simple Bool/Int tags. The PLC code copies UDT → shadow DB on each cycle. The HMI multiplexes against the shadow DBs. This keeps the UDT optimized for code quality while giving the HMI what it needs.
3. Drop the UDT for the HMI-relevant tags. Some teams split the valve data: control-loop state in a UDT, HMI-facing tags in flat non-optimized DBs. This is more work but survives future TIA upgrades.

Alternative Approaches

Manual popup swap (no multiplexing)

The faceplate paradigm still works if you accept a different visualization: instead of one popup that swaps its data, you create N popups (one per valve) and the overview button opens the matching one. The cost is N faceplate instances in the HMI project; the benefit is zero multiplexing complexity and no UDT/optimization conflict. This is the right choice for plants with <10 valves.

VB script tag redirection

On WinCC Professional / WinCC RT Advanced, a button click can trigger a VBScript that changes multiple HMI tags at once. This is more flexible than SetTag but heavier to maintain.

' Button click handler for Valve_27
Sub OnClick(ByVal Item)
    Dim tagObj
    Set tagObj = HMIRuntime.Tags("ValveDB")
    tagObj.Write 27
    HMIRuntime.Screens("Popup_ValveFaceplate").Activate
End Sub

The pattern is the same as the SetTag approach; the only difference is that you can add pre-conditions (e.g. permission checks, interlock logic) in the script before writing the multiplex tag.

Stack of popups

For a more polished UX, the overview button click can: (a) write the DB number to ValveDB, (b) clear the previously visible faceplate container, (c) place a fresh faceplate instance at the container coordinates. From the operator's perspective the popup looks identical, but the underlying object is a fresh instance. This is closer to the suggestion in the field report: "You probably want something that isn't a faceplate, but instead looks like a faceplate and calls up the correct faceplate and places it over top of the one being displayed." Implementation requires VBScript and a faceplate container with dynamic instantiation.

Verification

After configuring, validate the result on the HMI before deploying to the plant.

1. Compile the project. Confirm no errors. A typical multiplexing error reads: "The tag '<ValveDB>.OpenCmd' cannot be resolved because the referenced block uses optimized access."
2. Download to the PLC. Verify the instance DBs are present at the expected numbers (10, 11, 12, 13) using the online block list.
3. Start the HMI runtime on the engineering station (RT simulation).
4. On the overview screen, click the button for valve 1. Confirm the popup opens, the indicators show the values from DB10, and pressing Open writes a True into DB10.OpenCmd (verify with a watch table).
5. Close the popup, click the button for valve 3, and verify the same faceplate now shows DB12 data. A quick way to confirm the binding swapped is to put a distinct value into DB10.PositionFB and a different one into DB12.PositionFB; the faceplate should track the active DB.
6. Force a value into ValveDB that is outside the valid range (e.g. 0). The faceplate should display no data or a configured error state, confirming that the runtime is actually dereferencing the tag and not caching the previous binding.

Troubleshooting Matrix

Field-Proven Caveats

• Multiplexing introduces a runtime dependency on the HMI tag's value. If the value is corrupted (e.g. written from a non-engineered source), the faceplate silently binds to the wrong DB. Add a startup initialization in the HMI Schedules to set ValveDB to a sentinel value (e.g. 0) on RT start.
• On Comfort panels, the multiplex tag type must be Int (not DInt). Int covers 0..32767, well beyond any practical DB count.
• Downloading a new HMI project while the panel is in runtime does not always reset the multiplex tag. If a valve appears to be "stuck" on a different valve's data after a download, navigate away from the popup and back.
• Cross-reference the multiplex tag in the HMI cross-reference. If the cross-reference is empty, the tag is not actually bound to any faceplate interface, and the runtime will not update the binding.
• If the project later migrates to TIA V18+ and the HMI to WinCC Unified, the multiplexing prefix syntax is replaced by the Interface Instance model. Plan a porting step; the PLC side can stay identical.