Resolving WinCC 7.2 Faceplate Tag Interface Read/Write Issues

Problem: Faceplate Tag Direction Mismatch in WinCC 7.2

A common configuration error in WinCC V7.2 (and the broader WinCC V7.x family through V7.5 SP2) is that internal faceplate tags appear to communicate only one way with the surrounding process picture. An operator sets an external WinCC tag (for example, tagBool2 or PLC4_GR.GRM1.M1_Start), the value passes through a faceplate instance, and the embedded button changes state — but writing the value from inside the faceplate (for instance, via a script setting tagButtonStart = 1) does not propagate back to the external tag. WinCC Explorer logs no error, the Graphics Designer shows no red exclamation mark on the connection, and the link appears valid in every dialog, yet the data flow is effectively unidirectional.

This is not a bug. It is a direct consequence of the way faceplate type properties are defined, exposed, and connected to WinCC tags. The link only fires in the direction permitted by the property's access mode. A property defined as Read only (or one that is never "pulled out" of the faceplate type) cannot accept a write from inside the instance, regardless of how the external tag is configured.

This article documents the architectural cause, the exact property configuration required for bidirectional exchange, the script-based I/O Field workaround, and the verification procedure for confirming two-way data flow in WinCC V7.2 SP1 / SP2 and equivalent versions.

WinCC 7.2 Faceplate Architecture Overview

A faceplate type in WinCC is a reusable, encapsulated picture that contains its own internal tags, scripts, animations, and graphic objects. An instance of that faceplate is placed inside a process picture (the "base picture"). The faceplate instance communicates with the surrounding base picture through a strictly defined property interface — not through direct tag access.

Three distinct tag domains exist inside a WinCC 7.2 project:

The crucial point — and the source of most confusion — is that faceplate internal tags (smart tags) are not the same object as faceplate interface properties, even though they can share the same name in different dialogs. A smart tag is a private variable inside the faceplate. A property is the formal read/write contract exposed to the outside world. No implicit link exists between a smart tag named tagButtonStart and a similarly named WinCC tag tagBool2 in the base picture; the only way to bridge them is by binding the internal element to an interface property and then connecting that property to an external WinCC tag.

Root Cause Analysis: Why the Link Only Works One Way

The classic symptom in WinCC 7.2 is asymmetry between the two directions of data flow. Setting the external tag tagBool2 = 1 in the base picture causes the external rectangle and the embedded startButton inside the faceplate to both flash — meaning the property is being driven from outside and read inside. However, executing a C script inside the faceplate that sets the internal smart tag tagButtonStart = 1 does not update the external tagBool2, even though both tags are linked through the same faceplate property in the dialog.

This asymmetry is produced by one of three root causes, each of which must be ruled out in turn:

The diagnostic flash pattern in the symptom described — red rectangle flashes when external is written, internal button only — confirms cause 1 or 2: the link from outside to inside is valid (read direction works), but the link from inside to outside is blocked because the property was not declared writable.

Solution: Configuring Read/Write Interface Properties

The interface property is the only legal channel between the faceplate and the base picture. Configuring it correctly is the entire fix.

1. Open Graphics Designer and load the faceplate type (.fpt) that contains the faceplate body.
2. Right-click in an empty area of the faceplate body and choose Configure Faceplate Type.
3. Switch to the Interface tab. This tab lists every property exposed by this faceplate type to its instances.
4. Click New to add a property (or select an existing one to edit). Set:

5. Click Apply and close the dialog. The property is now part of the faceplate type contract.

Step-by-Step: Pulling Out a Property for External Linking

Once the property is declared in the faceplate type, it must be exposed on the instance in the process picture.

1. Open the base picture containing the faceplate instance.
2. Select the faceplate instance on the canvas.
3. Right-click and choose Faceplate Instance Properties (or open the Object Properties dialog, section Properties).
4. The dialog lists every property declared on the faceplate type. Each row has a small icon to the left — a closed folder means the property is hidden (only used internally), an open plug means it is pulled out and available for external connection.
5. Click the closed folder icon next to ButtonStart. The icon toggles to the plug symbol and the property is now exposed.
6. Click in the Static value column of the row. A small selection arrow appears.
7. Choose the target WinCC tag — for example PLC4_GR.GRM1.M1_Start or tagBool2. The selection uses the standard tag picker dialog.
8. Click Apply and save the picture.

Repeat the pull-out step for every property that must be accessible from outside. For a typical motor faceplate this is usually 4–12 properties (Start, Stop, Feedback Running, Feedback Fault, Speed SP, Speed PV, Mode, Local/Remote, etc.).

Wiring the Property Inside the Faceplate Body

The external connection alone does not move data. Inside the faceplate body, every graphic element that should read or write the property must be wired to it explicitly.

For a button whose state should follow the property value:

1. Select the button (e.g. startButton) inside the faceplate body.
2. Open Object Properties → Events → Mouse → Press left.
3. Add a C action:

For reading the property into the button's appearance (background flash), use a dynamic dialog on the Background color property:

1. Select startButton → Object Properties → Properties → Appearance → Background Color.
2. Right-click → Dynamic Dialog.
3. Expression: GetLinkedProperty("ButtonStart")
4. Configure the value range mapping (0 = gray, 1 = red) and the trigger (1 s cyclic is typical).

For a tag mirror that should propagate inside-to-outside continuously, bind the dynamic dialog target to the property, not to a local smart tag:

Expression: ButtonStart
Trigger: 1 s cyclic
Result: drives tagBool2 / PLC4_GR.GRM1.M1_Start via the pulled-out property

Script-Based Workaround Using I/O Field Output

If for any reason the property cannot be marked Read/Write (e.g. locked template, change-control freeze on the faceplate type), WinCC 7.2 supports an alternate pattern using an I/O Field whose Output Value is wired to the faceplate interface.

1. Place an I/O Field inside the faceplate body. Make it invisible (zero size or transparent) if it is not intended for operator display.
2. Open Object Properties → Properties → Output/Input → Output Value.
3. Right-click → Tag connection. Select the pulled-out interface property (for example ButtonStart).
4. In a C action on the source element (e.g. on the button's click event), write to the I/O Field's Output Value attribute:

// On Mouse Press of startButton inside the faceplate
SetPropBOOL(lpszPictureName, "IO_Field_1", "OutputValue", 1);
// The Output Value attribute is linked to the faceplate property ButtonStart,
// which in turn is linked to the external WinCC tag tagBool2.

This workaround is functionally equivalent to a Read/Write property but adds one indirection layer. It is useful when the faceplate type is shipped by a third party and cannot be modified, or when only a small subset of internal values must be exposed without rebuilding the type.

Configuring Bidirectional Logic in Dynamic Dialogs and C Scripts

Bidirectional data flow requires the property to be wired in two places — one for the inside-to-outside direction and one for the outside-to-inside direction. The cleanest implementation uses two dynamic dialogs on two different attributes:

A common C-script pattern for inside-to-outside propagation uses SetTagXxx on the button event and GetLinkedProperty for read-back:

// On the click event of startButton inside the faceplate
BOOL bState = GetLinkedProperty("ButtonStart");
bState = !bState;
SetLinkedProperty("ButtonStart", bState, TRUE);
// On the same script's return, the dynamic dialog bound to ButtonStart
// refreshes and the external tag tagBool2 follows.

The TRUE parameter on SetLinkedProperty forces immediate propagation rather than waiting for the next trigger cycle. Use it sparingly — on every cycle it can cause unnecessary traffic to the AS.

WinCC 7.x vs WinCC Unified: Faceplate Interface Differences

The architectural principle (interface properties are the only legal channel) is identical in WinCC V7.2 and in WinCC Unified (TIA Portal V16 through V20). The dialogs and concept names differ.

The Unified documentation describes the same mechanism under the term "tag interface": "The tag interface for faceplates is used as a standardized communications interface between the faceplate and the automation system. The interface tags of a faceplate type define the data points available to the faceplate instance." See the Siemens TIA Portal V20 documentation — Configuring interface tags in the faceplate type for the Unified reference.

The V7.x reference is in the WinCC Information System under Working with WinCC → Creating Faceplates → Configuring the Faceplate Type, part of the WinCC V7.5 SP2 manual set (which covers the same mechanics as V7.2). It is also mirrored in the Siemens support entry for WinCC V7.4/V7.5.

Verification and Test Procedure

After applying the fix, validate both directions explicitly. Do not rely on Runtime flashing alone — it can mask direction issues if the trigger rate is high.

1. Save the faceplate type and re-open the base picture. WinCC Graphics Designer must refresh the faceplate instance — close and reopen the picture if the icon set is stale.
2. In Tag Management, open WinCC Tag Simulator (or use the AS-side forcing tool) and create two forced test tags: tagBool2 and a mirror tag tagBool2_Mirror.
3. Direction 1 — Outside → Inside: Force tagBool2 = 1. The startButton background inside the faceplate must change within one trigger cycle (1 s default).
4. Direction 2 — Inside → Outside: Click startButton in Runtime. The external tag tagBool2 (visible in Tag Simulator or the diagnostics window of the AS) must change to 1 within one trigger cycle. The mirror tag tagBool2_Mirror connected in the same base picture must follow.
5. Repeat the cycle: tagBool2 = 0 from outside, then click startButton from inside. Both directions must respond symmetrically.
6. Check the WinCC diagnosis files (WinCC_Sys_.log in the project \diagnose directory) for "Tag connection error" or "Faceplate property not found" messages. Neither should appear.

Troubleshooting Matrix for Faceplate Tag Linking

Best Practices for Faceplate Interface Design

• Default every property to Read/Write at creation time. Tightening to Read only later is trivial; loosening requires touching every instance.
• Document the property name and access mode in the faceplate type header comment. The dialog in WinCC 7.2 does not show "Read/Write" once the type is instantiated.
• Pull out only what the instance needs. An over-pulled interface forces the user to wire empty tags and creates clutter in the Object Properties dialog.
• Avoid using the same name for a smart tag and a property. Although legal, it creates exactly the diagnostic confusion described in this article — the symptom looks like a bug but is a naming collision.
• Use a consistent naming convention for properties: prefix by domain (Cmd_Start, Sts_Running, Sts_Fault, Set_Speed, Act_Speed) so the direction is obvious from the name alone.
• Prefer dynamic dialogs with explicit triggers over free-running C actions for inside-to-outside propagation. They are easier to audit and load less on the WinCC server.
• Lock the faceplate type once approved. In WinCC 7.5 SP2, use the faceplate type versioning feature so subsequent edits do not silently change the contract.

FAQ