Creating Multiple Slide-In Screen Instances in TIA Portal HMI

Overview of the TIA Portal Slide-In Screen Function

The slide-in screen object is a runtime screen window in SIMATIC WinCC (TIA Portal) that animates onto the active screen from a configurable edge (top, bottom, left, or right). It is part of the Comfort Panel, Unified Comfort Panel, and WinCC Runtime Advanced / Professional screen object library, and it is intended for transient operator inputs that should not fully cover the process screen the way a modal popup does.

Out of the box, TIA Portal HMI engineering permits only a single configured slide-in screen object per HMI device. Operators that need a "swipe-in" effect for alarms, a recipe quick-editor, a maintenance dialog, and an operator login all at the same time must implement a workaround. The technique described in this article uses WinCC screen layers, per-object visibility animations, and PLC- or script-driven tag control to expose multiple logical slide-in instances from one physical slide-in object.

Screen Object Types: Popup vs. Slide-in vs. Screen Window

Before engineering a multi-instance solution, distinguish the three transient screen object types available in WinCC. Choosing the wrong one is the most common reason the workaround below appears more complex than it is.

Prerequisites

1. TIA Portal V15.1 or later (V17+ recommended for the most current screen object catalog).
2. An HMI device from the supported list:
   • SIMATIC Comfort Panels (TP700..TP2200, KP700..KP1500, KTP400..KTP1200)
   • SIMATIC Unified Comfort Panels (MTP700..MTP2200)
   • WinCC Runtime Advanced on a PC (SIMATIC HMI Panel PC or standard IPC)
   • WinCC Runtime Professional on a PC
3. A configured PLC connection (S7-1200/1500 preferred) or a local HMI tag if no PLC is in the loop.
4. The user must understand the difference between engineering layers (design-time stacking) and runtime visibility (animation triggered by tag state).
5. Optional but recommended: SIMATIC WinCC Engineering V19 - Programming and Operating Manual for the screen object reference.

Architecture of the Multi-Instance Slide-In

The single slide-in screen object has a fixed active state: when it is shown, the configured screen inside it is displayed. To emulate multiple instances, you embed several distinct screen layouts into a single master slide-in and toggle which layout is visible at runtime. Visibility is driven by a discrete tag (one bit per instance) and the engineering-time layer property keeps overlapping objects from interfering with the editor.

The diagram shows the runtime view: a single slide-in container that occupies one fixed region on the parent screen, with three visibility-animated layouts stacked at the engineering layer level. Whichever tag is active at runtime determines which instance the operator sees.

Step-by-Step Implementation

Step 1 - Add the master slide-in screen

1. Open the HMI device in the TIA Portal project tree.
2. Right-click Screens and add a new screen. Name it SlideIn_Master.
3. Size the screen to match the slide-in panel dimensions (typical: 380 x 220 px for a 7" Comfort Panel).
4. Insert the contents that you want to share across all instances (header bar, close button, slide direction). The close button writes 0 to all instance visibility tags via a single event.

Step 2 - Embed the slide-in screen object on the parent

1. Open the screen that should host the slide-in (for example Screen_Overview).
2. From the toolbox, expand Controls and drag a Slide-in screen object onto the workspace.
3. Configure the slide-in properties in the Properties window:

   Property	Recommended Value	Notes
   Slide-in direction	From right / from left	Pick one for the entire project; consistency improves operator usability.
   Animation duration	300 ms	Below 200 ms looks jittery on Unified Panels; above 600 ms feels sluggish.
   Process screen	SlideIn_Master	The master screen created in Step 1.
   Show tag	Leave empty for now	Engineered instance is sufficient for the multi-instance trick.

Step 3 - Create the instance layouts inside the master screen

1. Open SlideIn_Master.
2. Build the first instance, for example a recipe quick-edit panel, and place every object of that instance on Layer 1. Open the layer dialog via View > Layers in the WinCC editor menu.
3. Switch to Layer 2 (click the layer dropdown or use the layer dialog) and build the second instance, for example an alarm filter.
4. Switch to Layer 3 and build the third instance, for example a maintenance sign-in dialog.

Step 4 - Add the visibility tag structure

1. Create HMI tags in the HMI tag table. One Bool tag per instance keeps the logic simple and auditable. For a larger system you can pack all instance flags into a single Word or DWord and compare against constants, but the discrete tag approach is the easiest to troubleshoot.

Step 5 - Animate visibility of each instance

1. Select every object that belongs to Instance A in SlideIn_Master. Use Edit > Select All on Active Layer if you kept clean layer separation.
2. In the Properties window, expand Animations > Visibility.
3. Add a new visibility animation. The appearance model differs slightly between TIA Portal V15/V16 and V17+:

   TIA Version	Visibility configuration path	Condition
   V15 / V16	Properties > Animations > Display > Visibility	Tag HMI_bShowInstanceA = 1
   V17 / V18 / V19	Properties > Animations > Appearance > Visibility	Tag HMI_bShowInstanceA = 1

4. Repeat for Instance B with tag HMI_bShowInstanceB and for Instance C with tag HMI_bShowInstanceC.
5. Set the shared close button to write 0 to all three tags on the Press event.

Step 6 - Show the slide-in container from the trigger buttons

1. On the parent screen, place three buttons: Recipes, Alarms, Maintenance.
2. On the Press event of the Recipes button, configure two actions in this order:
   1. SetBit on HMI_bShowInstanceA = 1
   2. SetBit on HMI_bShowInstanceB = 0
   3. SetBit on HMI_bShowInstanceC = 0
   4. Activate the slide-in object: Edit Screen > Activate via the ActivateScreen system function on the slide-in object, or use the ShowSlideInScreen helper script described in Step 7.
3. Repeat for the Alarms button, setting only B high; and for the Maintenance button, setting only C high.

Step 7 - Optional: VBScript to keep state machine clean

For Unified Comfort Panels and PC Runtime, you can centralize the show logic into a script and call it from each button. This avoids forgetting to clear the other flags in the future.

' WinCC VBScript attached to a button's Click event
Sub ShowInstance(ByVal inst)
    ' inst is one of "A", "B", "C"
    SmartTags("HMI_bShowInstanceA") = False
    SmartTags("HMI_bShowInstanceB") = False
    SmartTags("HMI_bShowInstanceC") = False

    Select Case inst
        Case "A"
            SmartTags("HMI_bShowInstanceA") = True
        Case "B"
            SmartTags("HMI_bShowInstanceB") = True
        Case "C"
            SmartTags("HMI_bShowInstanceC") = True
    End Select

    ' Show the slide-in object (process function on the screen object)
    ShowSlideInScreen "SlideIn_Master"
End Sub

Call ShowInstance "A" from the Recipes button, ShowInstance "B" from Alarms, ShowInstance "C" from Maintenance. The script is editable in the HMI under Scripts > VB Scripts; it is not available on Classic Comfort Panels that target firmware V14 or earlier.

Tag Configuration and PLC Integration

The visibility tags can live entirely on the HMI side if the slide-in is a pure local UI function. If a PLC must know which instance is open (for example to suspend a recipe write while the maintenance dialog is open), the HMI writes the active instance index to a PLC tag. A typical mapping is:

On the PLC side, evaluate mutual exclusion in the OB1 cycle so the controller never reacts to more than one instance being open. The SCL example below can be placed in a function block for clean separation:

// SCL - FB_SlideInArbiter (S7-1500)
IF #bForceClose THEN
    #bShowA := FALSE;
    #bShowB := FALSE;
    #bShowC := FALSE;
    #byInstanceIndex := 0;
ELSE
    // Highest instance wins, prevents flicker if two bits arrive
    // in the same PLC cycle.
    IF #bShowA THEN
        #byInstanceIndex := 1;
    ELSIF #bShowB THEN
        #byInstanceIndex := 2;
    ELSIF #bShowC THEN
        #byInstanceIndex := 3;
    ELSE
        #byInstanceIndex := 0;
    END_IF;
END_IF;

Layer Management in Engineering vs. Runtime

WinCC TIA offers up to 32 layers per screen. By default, layers 0 through 15 are visible at design time, and 16 through 31 are reserved for runtime system screens. Keep the instance layouts on distinct low-numbered layers so they all stay editable in the same screen view. If an object refuses to be selected, the layer is probably hidden in the layer dialog; toggle the layer's eye icon in the upper toolbar of the editor.

At runtime, layer order does not determine which instance is shown. Only the visibility animation matters. A common confusion is to believe that placing Instance A on layer 1 and Instance B on layer 2 forces Instance A to draw on top; in fact the order of insertion into the screen defines the z-order, and you can rearrange it with Arrange > Bring to Front / Send to Back in the editor.

Animation Timing and Performance

Visibility animations are evaluated every WinCC cycle (default 100 ms). The slide-in container itself is animated by the runtime based on the configured duration. To prevent the slide-in from animating empty, the visibility animations should toggle in the same cycle as the slide-in is opened. Place all SetBit actions in a single configuration block, as shown in Step 6, and avoid setting the visibility tag from a delayed event such as a value-change of a job tag.

Verification Procedure

1. Compile the HMI and download to the target panel or PC runtime.
2. From the parent screen, press the Recipes button. The slide-in should animate in from the configured edge and only the recipe controls should be visible.
3. Press the close button. The slide-in should animate out, and all three instance tags should read 0 in the HMI tag diagnostics view.
4. Press the Alarms button. Only the alarm-filter content should be visible inside the slide-in region.
5. Switch rapidly between the three buttons. Confirm that no flicker occurs and that overlapping content never appears. If you see overlap, the visibility animation is not yet bound to its tag or the cycle time is too long.
6. In the PLC, monitor DB5.DBB1 and verify that it reads 1, 2, or 3 corresponding to the active instance, and 0 when closed.
7. Force-close from the PLC by setting HMI_bForceClose high. The slide-in should disappear and the PLC value should drop to 0.
8. Open the HMI diagnostics page (System > System Information > Performance) and verify that the screen complexity is below 80 percent of the device limit. Visibility-animated content still counts toward complexity even when hidden.

Troubleshooting Matrix

Field-Proven Caveats

• Visibility animations and the slide-in container's Show state are independent. Forgetting the Show action is the single most common reason this workaround fails on first deploy.
• Do not place a slide-in screen inside another slide-in screen. TIA Portal allows it at design time, but the runtime ignores the nested slide-in and only the outer one animates.
• The technique does not work for screens that must remain visible while the operator navigates to a different parent screen. The slide-in belongs to one parent and is destroyed when the parent is left. If you need a true global overlay, use a global screen with a permanent screen window instead.
• Visibility animation is not a substitute for hiding objects via authorization. If sensitive buttons are inside one of the instance layouts, configure the operator authorization separately on each button.
• On a Unified Comfort Panel running firmware V17 or earlier, JavaScript is not available. Use the VBScript variant in Step 7. From firmware V18 onward, JavaScript is fully supported and is preferred for new projects.

FAQ