Building WinCC 7.0 Faceplates for STEP 7 Multi-Instance Motor DBs

Overview

When fifteen SIMATIC S7-300/S7-400 motors are implemented as multi-instances of a single Function Block (FB), the entire dataset of all fifteen drives lives in one Instance Data Block — typically DB4. The engineering challenge is to expose this consolidated dataset in SIMATIC WinCC V7.0 through a single reusable faceplate rather than fifteen hand-wired motor screens. The pattern that solves this problem is the combination of STEP 7 multi-instance programming on the controller side and the Picture Window Tag Prefix mechanism on the HMI side.

This article walks through the full build, from the FB interface declaration in STEP 7 (Classic) to the Graphics Designer picture window configuration in WinCC 7.0. The result is one MotorFaceplate.PDL that is instantiated fifteen times, each instance reading its own slice of DB4 by virtue of a different tag prefix.

Architecture: Multi-Instance FBs and Picture Window Faceplates

The reusable-faceplate architecture is built from three layers:

1. Controller layer (STEP 7 V5.x / Classic): A child FB (FB_Motor) encapsulates the logic and I/O of a single motor. A parent FB (FB_15Motors) is called once in OB1 and contains fifteen multi-instance calls of FB_Motor. The instance DB of the parent FB (DB4) is the only data block needed in the user program; it holds all fifteen instance datasets in contiguous offsets.
2. Tag layer (WinCC Tag Management): One WinCC structure tag (built on a WinCC UDT, User-Defined Structure) mirrors the FB_Motor interface. Fifteen instances of that structure are created, each pointing to a different starting address in DB4.
3. Visualization layer (Graphics Designer): A single picture file MotorFaceplate.PDL contains all the animations, IO-fields, bars, and buttons of a motor overview. The picture is referenced from a Picture Window object on the process screen. The Tag Prefix property of the picture window rewrites every internal tag reference, so a single picture can display fifteen different motors.

The Tag Prefix property is the pivot of the technique. WinCC prepends the configured prefix string to every tag name queried from inside the picture at runtime. By changing the prefix from Motor1. to Motor15., the engineer switches the faceplate's data source without duplicating graphics.

Prerequisites

• STEP 7 V5.5 or V5.6 with a valid license for S7-300/S7-400 programming.
• SIMATIC WinCC V7.0 SP3 (or later SP) installed on the engineering/runtime station.
• An established S7 HMI connection (MPI/PROFIBUS/TCP) between the WinCC station and the PLC. The S7ONLINE driver must be online in WinCC Tag Management.
• STEP 7 project with hardware configuration downloaded to the AS, including a free DB number for the instance DB (DB4 in the example).
• WinCC 7.0 Information System installed locally (Start → SIMATIC → WinCC → Information System). The Faceplate topic references Tag Prefix and Picture Window objects.

STEP 7 Multi-Instance Configuration for Fifteen Motors

A multi-instance is a call of an FB inside another FB where no separate instance DB is generated for the called FB; the called FB reuses the instance data area of the calling FB. The benefit is a dramatic reduction in DB count: fifteen motors require only one instance DB (DB4) instead of fifteen separate instance DBs. Multi-instance creation is described in detail in the SIMATIC STEP 7 documentation: Multi-instances — Programming Basics, Block Calls and the S7-1500/TIA equivalent at Creating multi-instances (STEP 7 V18). The classic S7-300/S7-400 mechanism is functionally identical.

Build the Child FB (FB_Motor)

1. In the STEP 7 SIMATIC Manager, insert a new Function Block named FB_Motor (for example number 100). Declare the following interface (all symbols are example-only — match them to the project):

2. Implement the body of FB_Motor in LAD/FBD/ST. Compile the FB. Because the FB is called only as a multi-instance, do not assign an instance DB at this stage.

Build the Parent FB and Create the Multi-Instances

1. Insert a new FB named FB_15Motors (for example number 1). In its interface section, declare a STAT variable for each multi-instance. STEP 7 will auto-create the data area when the FB is compiled:

STAT
  Motor : ARRAY[1..15] OF FB_Motor;   // multi-instance array

2. In the code body of FB_15Motors, call FB_Motor fifteen times, one call per network, with explicit instance assignment. In STEP 7 V5.x the dialog is Edit → Call → Multi-Instance; in TIA Portal it is the "Call options" dialog described in multi-instance creation. The instance symbol auto-completes to #Motor[1], #Motor[2], … #Motor[15].
3. Wire each call to physical I/O or shared inputs (e.g., i_Start_1, i_Start_2…). Pass the outputs to global DBs, M flags, or leave them exposed via the parent FB interface for WinCC to read.
4. Call FB_15Motors once in OB1. When FB_15Motors is saved, STEP 7 asks for the instance DB: select DB4. Compile and download the program.

DB4 Structure and Per-Motor Offsets

DB4 contains fifteen repetitions of the FB_Motor instance data. The byte offset for motor n (1-based) is (n-1) * sizeof(FB_Motor instance data). For the example interface above, the offsets look like:

The instance size of 24 bytes assumes the FB_Motor layout shown. The exact size must be verified in STEP 7 by selecting DB4 and reading the Instance-DB / Length property. If the FB interface changes, all offsets downstream shift and the WinCC structure tags must be re-mapped.

WinCC 7.0 Tag Configuration

The faceplate reads from a WinCC structure tag, which is composed of elementary tags. The structure tag gives the faceplate a single, named data context (e.g., Motor1) that maps onto one motor's slice of DB4.

Create a User-Defined Structure (UDT)

1. In WinCC Explorer, open Tag Management → [your S7 connection] → Structures.
2. Right-click → New Structure. Name it MotorUDT. Add the following elements matching the FB_Motor interface:

Offset values are illustrative; confirm against the compiled DB4 layout in STEP 7.

Create Fifteen Structure Tag Instances

1. Right-click the S7 connection → New Tag → Tag of Structure Type. Name it Motor1, select MotorUDT as the structure type. Set the base address of the structure to DB4, byte 0.
2. Repeat for Motor2 through Motor15, advancing the base address by 24 bytes each time (DB4.DBoffset).
3. For symbolic access (strongly recommended), right-click the S7 connection → Properties → Symbolic, point to the STEP 7 source file. The structure elements then resolve as Motor_1.Running, Motor_2.Running, etc. — the FB instance name from STEP 7 is used as the structure root, which fits the multi-instance model cleanly.

Creating the Faceplate in WinCC 7.0

The faceplate is a normal WinCC picture, but it is designed to operate against a relative tag namespace that the Tag Prefix rewrites at runtime.

Step-by-Step Faceplate Construction

1. Open the Graphics Designer. Create a new picture, save as MotorFaceplate.PDL in the project Grafic directory.
2. Set the picture's Properties → Geometry to a 320 × 240 window (or the size of one motor tile on the process screen).
3. Insert the visual elements, all of which must reference tags without the motor index — the index is supplied by the picture window's Tag Prefix:
   • An IO field bound to Speed (output).
   • An IO field bound to Current with one decimal place.
   • A Bar object animated 0–100 % from Current.
   • A Round button for Start, configured with the event Press Left → Set Tag → Start = 1; release sets it back to 0.
   • A Round button for Stop, similar, writing Stop.
   • A Status indicator showing Running green / Fault red.
   • A Text field for run-time hours: Hours.
4. Save the picture. The faceplate itself is generic — never reference a specific motor index here.

Configuring the Picture Window Tag Prefix

The Picture Window is the runtime vehicle that loads the faceplate picture and rewrites its tag references. The Tag Prefix is the property that makes the rewriting work.

Step-by-Step Picture Window Configuration

1. In the main process picture (e.g., Main.pdl), open the Graphics Designer. From the Standard palette, drag a Picture Window object onto the canvas.
2. Open Properties → Miscellaneous and configure:

3. With Tag Prefix set to Motor1., an internal tag Running resolves to Motor1.Running, which is the structure element at DB4, byte 2.0.
4. Copy the picture window fourteen times. For each copy, set the Tag Prefix to Motor2., Motor3., …, Motor15.. The Picture Name stays the same; the geometry can be tiled or arrayed in the process picture.
5. Alternatively, drive the Tag Prefix dynamically. WinCC 7.0 supports a script-based approach: in the picture window's Tag Prefix property, use a tag-prefix expression or assign it from a C-script on the Open Picture event. A common pattern is to use a script that picks the prefix from an internal MotorSelect tag, allowing one faceplate to "follow" a clicked motor icon.

char* prefix = NULL;
int idx = GetTagWord("SelectedMotor");   // 1..15
if (idx >= 1 && idx <= 15)
{
    sprintf(prefix_buf, "Motor%d.", idx);
    prefix = prefix_buf;
}
return prefix;

Calling the Faceplate from the Process Picture

There are two common invocation patterns in WinCC 7.0:

Pattern A: Persistent Mosaic of Fifteen Faceplates

Fifteen Picture Windows placed on the overview screen, one per motor, each with a hard-coded Tag Prefix. Use this when the operator always needs to see all fifteen motors simultaneously (typical for a motor control room screen).

Pattern B: Single Popup Faceplate (Drill-Down)

1. Place a single Picture Window at a fixed position on the process screen, with Picture Name = MotorFaceplate.PDL and Tag Prefix left empty initially.
2. On each motor icon, configure a C-script on the Mouse Click Left → Open Picture event that sets a tag SelectedMotor to the motor index, then triggers the faceplate display. Many sites use a Set Tag action followed by a Picture Window → Set Property → Tag Prefix direct connection.
3. Bind the faceplate's Tag Prefix to the dynamic expression above. The faceplate now follows the operator's click without any screen navigation.

Verification and Acceptance Test

After build, perform this sequence in the WinCC Runtime (RT) with the PLC online:

1. Tag visibility test: In RT, right-click on the faceplate → Properties → Diagnostics. Confirm that all tags resolve (no red "quality bad" markers). The Tag Prefix value is shown in the picture window's property dialog at runtime.
2. Per-motor mapping test: In STEP 7, force Motor[1].o_Running = TRUE in VAT. Verify the first faceplate shows the running indicator; the other fourteen do not. Repeat for motors 2–15.
3. Command path test: Click Start on faceplate 1. The Motor1.Start tag in DB4 must toggle for 1 PLC scan; the Motor[1].o_Running output must latch true.
4. Fault propagation test: Force Motor[3].o_Fault = TRUE. Faceplate 3 must turn red; faceplates 1, 2, 4–15 must remain unaffected.
5. Dynamic Tag Prefix test (if used): Click motor 7's icon. The popup faceplate must show the data of motor 7; the status display on the overview must still show motor 7's data in its own picture window.
6. Performance test: Open WinCC Performance Watcher. With all fifteen faceplates updating 250 ms, the tag load must remain within the licensed tag-power limit of the WinCC station. Each structure tag counts as multiple elementary tags in licensing.

Troubleshooting Matrix

Best Practices for Scaling Beyond Fifteen Motors

• Use an ARRAY of multi-instances inside the parent FB. This keeps the multi-instance naming self-consistent and lets the WinCC tag prefix loop with an index, simplifying maintenance.
• Always export the STEP 7 symbols and import the .sdf file into WinCC. The faceplate will survive future FB interface changes without manual address patching.
• Limit tag update rates to 1 second for non-critical data. A bar object updating at 100 ms for fifteen motors creates noticeable RT load.
• Use Picture Windows (not static copies of the picture) for all reusable visuals; they load the picture by reference and consume far less memory than embedded duplicates.
• When the project moves to TIA Portal in the future, the same principle applies but the faceplate authoring moves to the TIA "Faceplate" editor, and the tag prefix is replaced by a PLC tag interface on the faceplate type.

FAQ