WinCC TIA VBScript Dynamic Object Creation Limits on TP1200

Overview

On Siemens TP1200 Comfort panels and other TIA Portal-based HMIs, the question of whether VBScript can dynamically create new screen objects at Runtime is one of the most common scripting limitations engineers encounter. The short answer is no: WinCC Runtime VBScript cannot instantiate a brand-new Rectangle (or any other ScreenItem) at Runtime. The HMI engineering contract exposes an object model where existing objects can have their properties read and written, but the object set itself is fixed at compile time inside the loaded screen. New objects cannot be added to a screen once the project is compiled and downloaded.

This article documents the technical reasons behind that limitation, separates the three WinCC scripting surfaces (Runtime VBS, Graphics Designer VBA, and legacy C-Script), and provides five production-tested workarounds for TP1200 Comfort panels running TIA Portal WinCC Comfort/Advanced V16 or later. Each workaround is rated for memory overhead, screen-update latency, and revision-management risk. The TP1200 Comfort firmware generation covered by the article is V16.0.x through V19.0.x; project-specific behavior on V20 panels is also noted.

WinCC Scripting Architecture: VBS, VBA, and C

WinCC TIA Portal exposes three distinct scripting surfaces, each with a different execution model and object access scope. Misunderstanding the boundaries is the most common reason engineers attempt impossible runtime operations, especially when coming from a WinCC V7 background where VBA and VBS scripts are both visible in the project tree.

The decisive row is VBS. The WinCC Runtime VBS engine loads the compiled screen at panel startup, parses the screen's ScreenItems collection, and binds it into a fixed in-memory tree. The VBS interpreter exposes that tree through the ScreenItems and HMIRuntime namespaces, but no API exists to insert a new node into the tree after the screen is loaded.

VBA, by contrast, runs inside the Graphics Designer COM automation host on the engineering station. It has full document-object-model access and can call HMIGO-style Objects.Add methods, but it only executes during engineering on the developer PC. The compiled panel project (.tia archive or HSP file) does not carry the VBA host; VBA cannot be invoked from Runtime and is never present in the runtime image downloaded to the panel.

Official reference: see the TIA Portal Help section "Examples of VBS (RT Professional)" and the WinCC Engineering Manual page Example of writing object properties (RT Professional) for the supported property surface.

WinCC V7 vs TIA Portal: Scripting Migration Notes

Engineers who maintain legacy WinCC V7 projects and migrate them to TIA Portal frequently hit this Runtime constraint, because in WinCC V7 the Graphics Designer ran inside a more VBA-friendly COM container. Three concrete differences are worth highlighting before diagnosing a "why does this not work" complaint:

1. VBA moved out of Runtime. In WinCC V7, VBA macros could be scheduled to run from within the Runtime via the "VBA Actions" scheduler. In TIA Portal, the scheduler exists but only VBS and C are valid targets; VBA is rejected with a configuration error at compile time.
2. The ScreenItems collection was tightened. In WinCC V7, the collection was a regular COM collection and a determined engineer could rebuild parts of it. In TIA Portal WinCC Comfort/Advanced, the collection is exposed through a managed wrapper that omits mutating methods entirely.
3. Faceplates replaced pop-up screens. Dynamic faceplate instantiation covers many use cases that V7 engineers solved with pop-up screens containing hand-built objects. Faceplates are still pre-compiled, but the pop-up count is variable.

If your team is migrating a V7 application that relies on dynamic Rectangle generation, plan the TIA Portal rewrite around a faceplate- or PictureWindow-based pool, not a VBS rewrite.

Why VBScript Cannot Create New Screen Objects at Runtime

The technical reasons span three layers: the screen compilation pipeline, the runtime object model, and the event-handler registration table.

1. Screen compilation. WinCC compiles each screen into an internal representation that includes the full ScreenItems hierarchy, property defaults, event bindings, and animation timelines. This representation is stored inside the HMI runtime database and pushed to the panel image at download time. The Runtime kernel uses the representation to instantiate widget objects when the screen is opened.
2. Runtime object model. The ScreenItems collection is exposed as a read-only enumerable. ScreenItems.Count and ScreenItems.Item(...) are supported, but Add, Remove, and Insert methods do not exist on the Runtime collection. Attempting to call them through reflection or COM dispatch returns E_NOTIMPL at best, or causes the VBS interpreter to raise a "Subscript out of range" or "Object doesn't support this property or method" error.
3. Event-handler registration. Each ScreenItem has pre-registered event triggers (e.g. OnClick, OnValueChanged, OnPress, OnRelease) that point to compiled VBScript function IDs in the project database. Dynamically inserting a new object would require registering a new event handler, which requires writing to the project database. The Runtime deliberately blocks this write because the database is loaded read-only into memory.

Runtime Object Model: What VBS Can and Cannot Do

The VBS Runtime object model does support a substantial subset of object manipulation. Understanding what is permitted is essential to designing efficient workarounds. The exact matrix varies slightly between firmware versions; the table below reflects TIA Portal V18 / V19 behavior on TP1200 Comfort.

The TIA Portal Help section "Working with System Functions and Runtime Scripting" lists all writable ScreenItem properties per firmware version. Always verify the matrix for the specific firmware image installed on your panel; older TIA Portal versions (V13, V14) ship a smaller writable property set and reject Transparency writes silently.

Firmware Differences: Comfort vs Unified

Because the same "can I add an object?" question arrives on multiple panel generations, here is the firmware-by-firmware answer.

For engineers committed to the TP1200 Comfort family, the answer on every shipped firmware revision is "no, use a pool". If a project genuinely requires dozens of dynamically generated widgets, migrate to a Unified Comfort panel (MTP1500 or MTP1900) and target the V19+ Unified API.

Workaround 1: Pre-Placed Object Pool with Visibility Toggling

The most reliable Runtime-only approach. The engineer pre-places a pool of Rectangle objects (or other widgets) on the screen at design time, then a VBS function toggles their visibility, position, and styling as required. This pattern preserves the Runtime object-model contract while giving the operator an arbitrary count of "new" rectangles, each instantiated from a pre-existing pool.

Design pattern

1. Estimate the maximum number of rectangles the operator could ever need and create that many in the screen. A reasonable cap is 32 or 64; beyond 128, screen-open time degrades noticeably on Comfort panels.
2. Give each rectangle a meaningful Name property: Rect_01, Rect_02, ... Rect_NN. Numeric suffix padding ensures lexicographic ordering matches numeric ordering.
3. Place them at a fixed coordinate off-screen (e.g. Left = -1000) with Visible = False as their initial state.
4. Add an internal HMI tag of type Int, e.g. RectCount, holding the active rectangle count.
5. On a button click event, increment RectCount, look up the corresponding rectangle by index, set its position, size, and Visible = True.

Sample VBScript

' VBS - Add a new rectangle from the pool
' Trigger: Button "btnAddRect", Event: Click
Sub btnAddRect_OnClick(ByVal Item)
    Dim iCount, iIndex, oRect
    iCount = SmartTags("RectCount").Value

    ' Hard cap: never exceed the pre-placed pool size
    If iCount >= 32 Then
        ShowSystemAlarm("Maximum of 32 rectangles reached")
        Exit Sub
    End If

    iIndex = iCount + 1
    Set oRect = ScreenItems("Rect_" & Format(iIndex, "00"))

    With oRect
        .Left   = 200 + (iCount * 110)
        .Top    = 150
        .Width  = 100
        .Height = 60
        .BackColor = RGB(64, 128, 200)
        .BorderColor = RGB(0, 0, 0)
        .Visible = True
    End With

    SmartTags("RectCount").Value = iCount + 1
End Sub

The With block batches all property writes so the Runtime triggers a single redraw rather than one per property. This is important because the first version of this script (a Set per property) produces a noticeable flicker on TP1200 Comfort panels.

Workaround 2: Layer-Based Rectangle Group Control

When the rectangle count is variable but the visual style and behavior are uniform, a layer-based approach reduces script complexity and improves Runtime performance.

1. Create a custom screen layer named, for example, Layer_UserRectangles in the Graphics Designer (right-click the layer panel → Add layer).
2. Place all pre-placed rectangles on that layer with Visible = False at startup.
3. From VBS, toggle the entire layer's visibility using Screen.Layers("Layer_UserRectangles").Visible = True. The layer's active state is also reachable through a property binding.
4. Use a single visibility tag (LayerActive) to control the layer as a unit; bind the layer's Visible property to that tag for fully script-free control.

This approach is cheaper on screen redraws because the Runtime can treat all layer objects as a single draw batch. It is recommended for "show all annotations" toggles rather than per-rectangle dynamization. The trade-off is loss of per-rectangle control: once the layer is visible, every rectangle on it is visible.

Workaround 3: PictureWindow with Embedded Screens

The PictureWindow ScreenItem loads a separate screen at a defined position and supports a configurable picture-change tag. This is the most powerful Runtime-only substitution for dynamic object creation, because it gives you a new screen with its own pre-placed pool, swapped at Runtime.

Why PictureWindow helps

Instead of creating N rectangles inside the parent screen, the engineer creates a separate screen RectTemplate.scrn containing the maximum number of rectangles, then loads it into a PictureWindow. The PictureWindow supports property reads and writes through VBS, including PictureName swaps. Operators perceive each loaded instance as a "new" rectangle, although the underlying ScreenItems are pre-compiled inside the embedded screen.

PictureWindow script

' VBS - Toggle a PictureWindow
' Reference: Siemens WinCC Comfort Scripting sample VBS302
If lId = 1001 Then
    ScreenItems("PictureWindow1").Visible = True
    ScreenItems("PictureWindow1").PictureName = "RectTemplate"
End If

The PictureName property accepts the name of any screen in the project. By cycling through several template screens (each with different rectangle layouts), the operator effectively gets the impression of dynamic object generation. The PictureWindow approach is also documented in the Siemens WinCC V7.x scripting manual entry ID 37572697, which contains additional sample code for picture-change scenarios.

PictureWindow pool sizing

Each PictureWindow reserves a screen-load slot in the Runtime's screen cache. TP1200 Comfort can keep four to six PictureWindows loaded concurrently before screen-change latency exceeds 500 ms. For larger pools, free the slot by setting PictureName = "" before swapping in a new template.

Workaround 4: VBA in Graphics Designer (Configuration-Time Only)

If the genuine requirement is to generate objects at engineering time — for example, building a screen with 200 tag-driven rectangles based on a tag list exported from the PLC project — VBA is the correct tool. VBA is not a Runtime alternative but an engineering-time automation surface.

Where VBA fits

• Bulk-generating ScreenItems from a tag export CSV.
• Renaming objects following a corporate naming scheme.
• Adjusting properties of every I/O field in a multi-language project.
• Building screen templates programmatically before the project is downloaded to panels.
• Generating a visibility pool of 200 rectangles whose labels match tag names imported from STEP 7.

Important boundaries

• VBA executes only inside the Graphics Designer COM host on the engineering station.
• VBA code is not transferred to the panel; the panel receives only the compiled screen output.
• Calling VBA functions from Runtime VBS is not supported. The Runtime kernel has no VBA host.
• Macro security settings must be enabled in TIA Portal Options → Scripting → Enable VBA macros.

For PC-based WinCC Runtime (V7.x or Professional), the situation is similar: VBA adds objects inside the Graphics Designer at engineering time; the Runtime cannot invoke VBA. Reference the official Siemens WinCC forum response for VBA scope at Siemens Industry Online Support — VBS vs VBA in WinCC Graphics Designer.

Workaround 5: Faceplate-Based Pooling

For complex reusable widgets (a rectangle with a label, a status LED, and a tag value), the engineering effort to pre-place 64 instances is significant. The standard TIA Portal solution is a faceplate.

1. Build a faceplate FP_Rect containing a Rectangle, a TextField, and an LED indicator.
2. Expose faceplate tags for Visible, Left, Top, and Caption.
3. Drop the faceplate onto the screen as many times as needed; each instance has its own tag namespace.
4. From VBS, address each instance by its compound name: ScreenItems("FP_Rect_1").Visible = True.

Faceplates count against the screen's ScreenItems budget like any other object, so the same pool sizing rules apply. The win is engineering efficiency: changes to the faceplate propagate to every instance, so the visibility pool can be resized from 32 to 64 by simply copying the faceplate 32 more times, not by re-drawing 32 rectangles.

Complete VBScript Example: Visibility Pool on TP1200 Comfort

The following end-to-end snippet demonstrates a visibility pool with add, remove, and clear operations, plus a hot-key handler for batch activation. It is suitable for a TP1200 Comfort running TIA Portal V18 or V19.

' ==========================================================================
' WinCC Comfort VBS - Rectangle pool manager
' Tested on: TP1200 Comfort, firmware V18.0.0.1, TIA Portal V18 Update 4
' Pool size: 32 rectangles, indexed Rect_01 .. Rect_32
' ==========================================================================

' ---- Configuration tag list (HMI tags) -----------------------------------
' RectCount : Int, current active rectangle count, initial value = 0
' RectX_01..RectX_32 : Int, X position of each rectangle (optional)
' RectY_01..RectY_32 : Int, Y position of each rectangle (optional)

Const POOL_SIZE = 32
Const RECT_W   = 100
Const RECT_H   = 60
Const START_X  = 100
Const START_Y  = 100
Const STEP_X   = 110
Const PARK_X   = -1000

' ---- Helper: format a 1-based index into a zero-padded 2-digit suffix
Function RectName(ByVal iIndex)
    RectName = "Rect_" & Right("0" & iIndex, 2)
End Function

' ---- Add a new rectangle -------------------------------------------------
Sub btnAddRect_OnClick(ByVal Item)
    Dim iCount
    iCount = SmartTags("RectCount").Value

    If iCount >= POOL_SIZE Then
        ShowSystemAlarm("Pool exhausted (" & POOL_SIZE & ")")
        Exit Sub
    End If

    Dim sName
    sName = RectName(iCount + 1)
    ScreenItems(sName).Left   = START_X + (iCount * STEP_X)
    ScreenItems(sName).Top    = START_Y
    ScreenItems(sName).Width  = RECT_W
    ScreenItems(sName).Height = RECT_H
    ScreenItems(sName).Visible = True
    SmartTags("RectCount").Value = iCount + 1
End Sub

' ---- Remove the last rectangle ------------------------------------------
Sub btnRemoveRect_OnClick(ByVal Item)
    Dim iCount
    iCount = SmartTags("RectCount").Value
    If iCount <= 0 Then Exit Sub

    Dim sName
    sName = RectName(iCount)
    ScreenItems(sName).Visible = False
    ScreenItems(sName).Left = PARK_X   ' park off-screen
    SmartTags("RectCount").Value = iCount - 1
End Sub

' ---- Clear all rectangles -----------------------------------------------
Sub btnClearRect_OnClick(ByVal Item)
    Dim i
    For i = 1 To POOL_SIZE
        ScreenItems(RectName(i)).Visible = False
        ScreenItems(RectName(i)).Left = PARK_X
    Next
    SmartTags("RectCount").Value = 0
End Sub

' ---- Insert at arbitrary index (shift right) ----------------------------
Sub btnInsertAt_OnClick(ByVal Item)
    Dim iCount, iInsert, i
    iCount  = SmartTags("RectCount").Value
    iInsert = SmartTags("InsertIndex").Value

    If iCount >= POOL_SIZE Then
        ShowSystemAlarm("Pool exhausted")
        Exit Sub
    End If
    If iInsert < 1 Or iInsert > iCount + 1 Then
        ShowSystemAlarm("Insert index out of range")
        Exit Sub
    End If

    ' Shift existing rectangles one slot to the right
    For i = iCount To iInsert Step -1
        ScreenItems(RectName(i)).Left = ScreenItems(RectName(i)).Left + STEP_X
    Next

    ' Place the new rectangle at the insertion slot
    ScreenItems(RectName(iInsert)).Left   = START_X + ((iInsert - 1) * STEP_X)
    ScreenItems(RectName(iInsert)).Top    = START_Y
    ScreenItems(RectName(iInsert)).Width  = RECT_W
    ScreenItems(RectName(iInsert)).Height = RECT_H
    ScreenItems(RectName(iInsert)).Visible = True

    SmartTags("RectCount").Value = iCount + 1
End Sub

Notes on the snippet:

• The pool is bounded; the script never allocates beyond POOL_SIZE. Operators cannot exhaust the engine.
• Parking rectangles at Left = -1000 is a defensive measure so an accidental visibility flag flip does not show stale geometry inside the visible area.
• ShowSystemAlarm writes to the WinCC alarm system; replace it with a status-line tag update if your panel does not have alarm logging enabled.
• The shift loop in btnInsertAt demonstrates a limitation of the pool approach: insertion in the middle of an ordered list requires a shift, which is O(n) but linear in n and therefore acceptable for pools up to 64.

Tag System Integration

The pool pattern depends on a small set of HMI tags that mirror the Runtime state. On TP1200 Comfort, define these tags in the HMI tag table before writing the VBS:

Persistent tag storage is useful if the operator can power-cycle the panel and expect the rectangles to reappear. Without persistent storage, the pool reverts to its parked state on every restart. To enable persistence, set the tag's "Persistency" property to "Retain" in the HMI tag editor.

Event-Handler Architecture

Every ScreenItem in the pool can carry its own event handlers, registered at compile time. A common pattern is to give each Rectangle a OnClick handler that runs the same shared function and uses the rectangle's Name property to identify which one was clicked:

' Shared click handler for all Rect_NN objects
Sub Rect_OnClick(ByVal Item)
    Dim sName
    sName = Item.Name       ' e.g. "Rect_05"
    SmartTags("LastClickedRect").Value = sName
    ShowSystemAlarm("Clicked " & sName)
End Sub

To bind the same function to every Rect_NN in the pool, open the project's event-handler table in TIA Portal and either manually assign the handler or use the TIA Portal "Select all rectangles → Assign event" tool. Avoid creating 32 separate handlers; the shared handler pattern keeps the project compact and easier to maintain.

Performance and Memory Considerations on TP1200 Comfort

TP1200 Comfort panels ship with a 512 MB to 1 GB DRAM budget depending on firmware generation. Each ScreenItem carries a small fixed footprint (typically 1 to 4 KB including its property table and event registrations). Pool sizes of 32 to 128 rectangles are safe; pools of 512 or larger start to compete with faceplate memory.

Screen-redraw budget: WinCC Comfort targets 100 ms for a typical 1280×800 screen update. Each visible rectangle adds roughly 0.5 ms to a full-screen redraw on TP1200. At 64 visible rectangles, redraw overhead is therefore ~32 ms, still well within budget. If you combine many pools on the same screen, profile with the TIA Portal Performance Viewer before shipping.

Edge Cases and Field-Proven Caveats

Object-name collisions in faceplates

If the engineer reuses the same faceplate across multiple instances, each faceplate instance carries its own ScreenItems scope. ScreenItems("Rect_01") inside faceplate instance A does not collide with the same name inside instance B because the Runtime prefixes faceplate objects with their instance ID at load time.

Property writes during screen transition

Writes issued in the OnDestroy event of a screen or in the brief interval between Open and the first redraw can be lost. Always set visibility in OnClick, OnValueChanged, or a scheduled VBS trigger, never in screen-close logic.

Tag type mismatch

SmartTags(...).Value raises a runtime script error if the tag is undefined or its type does not match the assignment. Wrap reads in IsEmpty checks when scripting around optional tags. The same applies to SmartTags(...).Value = ... when the tag is read-only because of PLC connection direction.

Color overflow on older panels

TP1200 Comfort firmware V13 and V14 silently truncate 24-bit color values to 16-bit. If you assign BackColor = RGB(64, 128, 200) on a V13 panel and notice banding, the color is being quantized. Upgrade to V16 or later where 24-bit colors are preserved.

Sub-tag access on faceplates

To read a tag exposed by a faceplate instance, address it through the faceplate's tag interface: SmartTags("FP_Rect_1").Caption. Direct screen-items access to internal faceplate children is rejected.

Hot-key handlers and pooling

If a global hot key on the panel must add a rectangle regardless of which screen is currently active, define the hot key on the global screen (the screen that never unloads) and have the script locate the active screen with HMIruntime.ActiveScreen before issuing the ScreenItems call. This pattern works because ScreenItems resolves to the active screen's collection by default.

Performance Profiling Procedure

Before shipping a large pool, profile the actual redraw cost on the target panel:

1. Open the project in TIA Portal with the target panel image (e.g. TP1200 Comfort, 6AV2 124-1MC01-0AX0).
2. Connect the engineering PC to the panel via Ethernet and start Runtime on the panel.
3. Start the TIA Portal Performance Viewer (Project → Diagnostics → Performance).
4. Trigger a full pool activation (32 to 128 rectangles) and record the redraw histogram.
5. Verify the 95th-percentile redraw time stays under 100 ms; the maximum under 200 ms.
6. If timings exceed the budget, split the pool across multiple screens and use tab navigation rather than a single crowded screen.

Performance Viewer records include per-screen redraw cost, per-property animation cost, and tag-acquisition latency. On TP1200 Comfort, the most common budget breach is per-property animation cost: animating a tag-bound property on every rectangle in a 128-pool can multiply CPU cost by 64×.

Troubleshooting Matrix

Verification Checklist

Before shipping the panel image, validate the following:

1. Compile and download the project to a TP1200 Comfort with the same firmware image as production.
2. Open the screen with all rectangles parked at Left = -1000; verify the screen shows none of them.
3. Click btnAddRect in Runtime; verify the first rectangle appears at (100, 100), the second at (210, 100), and so on.
4. Click btnRemoveRect; verify the last rectangle disappears and RectCount decrements.
5. Click btnClearRect; verify all rectangles are hidden and RectCount = 0.
6. Stress test by clicking btnAddRect 32 times in quick succession; verify no script errors appear in the Runtime alarm window.
7. Restart simulation in TIA Portal with the PLCSIM Advanced simulator; verify the same behavior in offline simulation.
8. Cycle power on the panel; if persistence is enabled, verify the rectangles reappear at their stored positions.
9. Export diagnostic trace via TIA Portal → Online → HMI diagnostics; check that no script-error events were logged during the run.

Summary

VBScript on TP1200 Comfort cannot create brand-new ScreenItems at Runtime. The constraint is part of the WinCC Runtime object model, present in every Comfort firmware revision from V13 to V20. The five supported workarounds, in increasing engineering complexity, are: pre-placed visibility pool, layer toggling, PictureWindow with screen templates, VBA at engineering time, and faceplate-based pooling. Each preserves the Runtime contract and avoids the unfixable limitations of trying to mutate the screen object model. For projects that genuinely require dozens of dynamically generated widgets, the only path forward is a Unified Comfort panel (MTP1500 / MTP1900) on TIA Portal V19 or later, where the JavaScript-based runtime exposes a more flexible element tree.