Detecting Active Monitor in WinCC V11 Multi-Monitor Runtime

This engineering reference describes how to identify which physical display is currently receiving operator input in a Siemens WinCC V11 (TIA Portal V11) runtime configured across two PCs and eight physical monitors. The original requirement is to allow alarm acknowledgment from exactly one of the eight monitors while the remaining seven monitors remain read-only for alarm handling. The WinCC runtime API does not expose a direct "which-monitor-is-active" property at the VBScript or tag level, so the solution is built on the runtime's Screen Window object model, which uniquely identifies the sub-region of the start picture in which a faceplate or screen is currently shown. By giving each of the four base screen windows on a PC a unique, fixed name and querying that name from a VBScript that runs when the alarm view is opened or when an acknowledge button is clicked, you can determine which of the four physical displays the operator is currently using on that PC, and the same approach can be mirrored on the second PC to gate the function across all eight displays.

1. Overview of the Multi-Monitor Runtime Problem

WinCC V11 Runtime (in TIA Portal V11) is a Microsoft Windows-based HMI/SCADA runtime. Because it runs on Windows, it inherits the Windows display topology: the operating system presents a single virtual desktop whose horizontal/vertical extent spans every attached monitor. The WinCC runtime can be stretched across that virtual desktop so that the same start picture is rendered on every monitor, or it can open additional windowed runtime instances on the same PC to occupy individual monitors. Both modes are valid in TIA Portal V11 SP2 and later, and the choice of mode determines which runtime object you can query to learn the active monitor.

There is no single public WinCC property such as HMIruntime.ActiveMonitor or HMIruntime.MonitorIndex. The TIA Portal V11 WinCC Runtime Programming Reference documents the VBScript object model, and it does not contain a monitor handle. The cleanest supported way to gate a function on the active display is therefore to make the picture layout itself carry the identity, by giving every screen window a known name and reading the Parent context of the screen that is currently running on top of that window.

1.1 Two Approaches That Don't Work

• Reading the Windows monitor handle from VBScript. WinCC VBScript runs in a constrained runtime that does not have full access to the User32.dll and GDI32.dll APIs. Calls into MonitorFromWindow or EnumDisplayMonitors require Declare statements that the TIA Portal V11 VBScript editor does not honor at runtime. Even if a P/Invoke-style wrapper were added, the result would be unreliable because the runtime can render to monitors that are temporarily inactive (the operator has not touched the keyboard or mouse on them for some time).
• Reading the cursor position and mapping it to a monitor. This requires the GetCursorPos API and an arithmetic comparison against each MonitorInfo rectangle. The same restricted-API problem applies, and a 30-second idle period is enough for the OS to relocate the cursor to its previous position on focus restore, producing false positives.

2. Prerequisites

Before configuring the runtime, confirm the following:

1. TIA Portal V11 SP2 or later installed on the engineering station. The original system described in the source used V11; SP2 is recommended because it added a number of VBScript fixes and the ScreenItems enumeration is more robust.
2. WinCC V11 Runtime Advanced (for PC-based panels) or WinCC V11 Runtime Professional (for SCADA stations). The professional runtime is recommended for a multi-PC, multi-monitor installation because it supports named screen windows in the same project and exposes the full HMIruntime object model to VBScript.
3. Graphics card with enough outputs for four monitors per PC. In practice, two dual-head cards (NVIDIA NVS 510, AMD FirePro W4100, or Intel Arc Pro equivalent in newer releases) is the most common choice for control rooms.
4. Operating system: Windows 7 Professional/Ultimate/Enterprise (64-bit) or Windows Server 2008 R2, both of which are the supported OS list for TIA Portal V11. Multi-monitor topology is configured from Control Panel > Display > Screen Resolution. Use the Identify button to verify that Windows sees all four monitors; the Microsoft Windows multi-monitor API enumerates them as \.\DISPLAY1 through \.\DISPLAY4 in monitor handle order.
5. Network between the two PCs. Either a dedicated switch on a control-room VLAN, or a back-to-back cross-over for redundant mirrored operation. The two PCs must resolve each other by name if the second PC is going to read the acknowledge gate from the first PC (see section 9).

3. Multi-Monitor Runtime Architecture

Each PC runs its own WinCC V11 Runtime instance, started from a single WinCC project file. The same start picture is shown four times: once in each screen window on the start screen. The four screen windows are arranged on the Windows virtual desktop so that each screen window falls entirely within the bounds of one physical monitor.

3.1 Recommended Picture Layout

For a 2x2 grid of 1920x1080 monitors, use a single start picture at 3840x2160 pixels containing four Screen Window objects, each 1920x1080:

3.2 Cross-Monitor Coordinate Mapping

The Windows virtual desktop in a 2x2 monitor arrangement has its origin at the top-left of \.\DISPLAY1. The right edge of monitor 1 sits at x = 1920, the bottom edge at y = 1080. This is consistent with the Windows multi-monitor API contract, which reports monitor rectangles in virtual desktop coordinates. Do not enable "extend these displays" in the wrong direction (right-to-left or bottom-to-top) for the system described in the source, because the screen window positions above will no longer match.

4. Configuring the Screen Windows

1. In the TIA Portal project tree, expand Pictures and open the start picture (commonly named Start.pdl).
2. From the Tools task card, drag a Screen Window object onto the picture four times.
3. For each, open Properties > General and set a fixed name from the table in section 3.1.
4. For each, set the position and size properties exactly to the values in the table. Use the Properties window's pixel fields, not the drag handles, to avoid sub-pixel rounding.
5. Set the Adapt picture property to Fit to screen window so that sub-screens resize with the monitor if the operator later changes the resolution.
6. Set the Monitor property to Process screen for all four. The Monitor property here is the WinCC "monitor number" (start picture index) and is not the same as the physical monitor; leave it at the default of 1 for all four, because the four physical monitors are all rendering the same process screen, just in different screen windows of it.
7. Click Compile > Software (rebuild all) and download the project to the runtime PC.

5. Detecting the Active Monitor with VBScript

The core technique is to make the alarm view (or the acknowledge button) query its parent screen window by name. The runtime exposes this through the Parent property of the HMIruntime.Screens collection.

5.1 VBScript: Identify Which Screen Window Contains the Calling Screen

' VBScript attached to the "On Open" event of the alarm view screen
' Determines which of the four screen windows the alarm view has been opened in,
' and sets an internal tag that gates the acknowledge button.

Dim oScreen, oScreenWindow, sWindowName, sAuthorizedWindow

sAuthorizedWindow = "ScreenWindow_M4"   ' The only window that allows acknowledge

' Walk up from the current screen to its parent screen window
Set oScreen = HMIruntime.Screens(HMIruntime.ActualScreenName)

' The parent is a ScreenItem of the start picture
Set oScreenWindow = HMIruntime.Screens("Start").ScreenItems("ParentContainer")

sWindowName = ""
On Error Resume Next
sWindowName = oScreen.Parent.Name
On Error Goto 0

If sWindowName = sAuthorizedWindow Then
    HMIruntime.Tags("Auth_AcknowledgeAllowed").Write 1
Else
    HMIruntime.Tags("Auth_AcknowledgeAllowed").Write 0
End If

This pattern reads the Name of the parent Screen Window of the picture that is being shown. The same logic can be attached to the On Click event of the acknowledge button, which avoids the need to keep the tag continuously updated.

5.2 VBScript: Acknowledge Button Click Handler

' VBScript on the Click event of the acknowledge button
' More robust than the On Open approach because it always reflects the
' current state at the moment of the click, even if the user has
' dragged the screen window or the operator has been swapped.

Dim sAuthorizedWindow, sWindowName, oButton

sAuthorizedWindow = "ScreenWindow_M4"

' The button's Parent is the screen window the button is rendered in.
Set oButton = HMIruntime.Screens(HMIruntime.ActualScreenName).ScreenItems("BtnAcknowledge")
sWindowName = oButton.Parent.Name

If sWindowName = sAuthorizedWindow Then
    ' Permit the acknowledge. The actual acknowledge action is
    ' carried out by a function call or by writing the alarm
    ' acknowledgment tag set configured in the alarm control.
    HMIruntime.Tags("Ack_Trigger").Write 1
    HMIruntime.Tags("Ack_Trigger").Write 0   ' pulse; rising edge triggers
Else
    ' Notify the operator. The MsgBox in the source is a custom popup
    ' generated with the WinCC VBScript MsgBox function.
    MsgBox "Alarms can only be acknowledged from Monitor 4 (bottom-right)." & vbCrLf & _
           "Please use the keyboard at the bottom-right station.", _
           vbExclamation, "Acknowledge Denied"
End If

The field report explicitly states that the original author used a custom MsgBox popup to inform the user, and that a follow-up suggestion was to use a disabled button instead. Both patterns are valid; the disabled-button pattern is preferred for usability (see section 11).

6. Alarm Control Configuration

The WinCC Alarm Control is the screen-level object that displays the active and acknowledged alarms. Its toolbar contains the standard acknowledge button, but the source specifies that the toolbar is hidden and a custom button is used. To integrate the detection logic with the alarm control:

1. Open the picture that contains the alarm view (this is the picture that gets loaded into each Screen Window).
2. Set the alarm control's Toolbar property to Hide.
3. Add a regular Button object named BtnAcknowledge next to the alarm view.
4. Attach the VBScript from section 5.2 to the button's Click event.
5. Configure the Authorization property of the alarm control to None (or to a low-priority operator level) so that the runtime's built-in authorization popup does not double up with your custom one.

7. Verifying the Configuration

After downloading the project to the runtime PC, perform the following checks:

1. Startup check: the start picture should appear stretched across all four monitors. Each physical monitor should show a complete, non-overlapping copy of the start picture.
2. Screen window identity: open the alarm view on each of the four monitors in turn, by clicking the navigation button on each. The Auth_AcknowledgeAllowed internal tag should read 1 only on monitor 4 (bottom-right).
3. Click test: click the acknowledge button on monitor 1. The custom popup should appear, indicating that the click was detected on ScreenWindow_M1 and that authorization was denied.
4. Click test (positive): click the acknowledge button on monitor 4. The active alarm should be acknowledged, and the alarm view should reflect the change immediately.
5. Mirror test on the second PC: repeat steps 2 to 4 on the second PC. If the two PCs share the same Auth_AcknowledgeAllowed tag (e.g., via a shared PLC tag), both PCs should report 0 for the non-authorized monitor and 1 for monitor 4.

7.1 Quick Diagnostic Dump

Add the following script to a hidden maintenance button to dump the parent screen window of every alarm view in the runtime, useful for first-time commissioning:

Dim i, oScrn, sLine
sLine = ""
For i = 1 To HMIruntime.Screens.Count
    Set oScrn = HMIruntime.Screens(i)
    sLine = sLine & oScrn.Name & " -> parent=" & oScrn.Parent.Name & vbCrLf
Next
HMIruntime.Trace sLine   ' write to the WinCC trace viewer

8. Performance and Licensing Considerations

WinCC V11 Runtime is licensed per tag, per picture, and per archive. A multi-monitor runtime that uses four copies of the alarm view counts as four "alarm view" objects for licensing, but it is still a single project, so only one development license and one runtime license are required. The runtime tag count is the same regardless of how many physical monitors show the picture.

CPU and GPU load scales linearly with the number of monitors, but a modern dual-head card can drive four 1920x1080 monitors at 60 Hz without breaking a sweat for a typical HMI page. The bottleneck is usually the alarm refresh rate, not the rendering. If you see frame drops on monitor 4 but not on monitor 1, suspect a Windows compositor issue rather than a WinCC issue. Disable Windows Aero on the runtime PC to remove the compositor from the rendering path; TIA Portal V11 is not Aero-aware.

9. Coordinating the Two PCs

The source describes two PCs each driving four monitors, for a total of eight physical displays. There are two ways to coordinate the acknowledge authorization across both PCs:

9.1 Local-Only Authorization (Recommended for the Source Setup)

Each PC runs the same project, with the same ScreenWindow_M4 name as the authorized window. The acknowledge button on PC 1's monitor 4 works for alarms on PC 1, and the acknowledge button on PC 2's monitor 4 works for alarms on PC 2. There is no cross-PC coordination. The two PCs are effectively independent, which is the simplest configuration and matches the description in the source.

9.2 Shared-Authorization via a PLC Tag

If the two PCs must enforce the rule that only one of the eight monitors in the entire system can acknowledge alarms, add a shared PLC tag Auth_AcknowledgeAllowed that is set to 1 only on the authorized PC. Both PCs read this tag, and the VBScript in section 5.2 is extended to check the PC-level flag before the screen-window-level flag:

If HMIruntime.Tags("Auth_PC_AcknowledgeAllowed").Read = 1 And _
   sWindowName = sAuthorizedWindow Then
    HMIruntime.Tags("Ack_Trigger").Write 1
    HMIruntime.Tags("Ack_Trigger").Write 0
Else
    MsgBox "This PC is not authorized to acknowledge alarms.", vbExclamation, "Denied"
End If

10. Edge Cases and Failure Modes

11. Best Practices

• Disable rather than popup. As the follow-up comment in the field report recommends, set the acknowledge button's Enabled property to 0 on the non-authorized screen windows, and to 1 on the authorized one. This avoids a popup for the common case and keeps popups reserved for genuinely abnormal conditions.
• Use the On Click event, not the On Open event. The On Open event fires only when the screen is loaded. If the operator keeps the alarm view open and switches the project focus to another screen, the On Open event will not re-fire, and the authorization tag will be stale. The On Click event is always current.
• Name the screen windows before downloading. Renaming after a download sometimes does not propagate to the runtime, and the runtime will keep the original names. Always re-download the entire project after a rename.
• Lock the screen window sizes. If the screen windows are resizable at runtime, the VBScript will not detect the new monitor, because the size has no bearing on the screen window's name. Lock the size to the values in section 3.1.
• Use a single source of truth for the authorized window name. Define sAuthorizedWindow = "ScreenWindow_M4" in a single script file (a VBScript include) and reference it from every other script. Hard-coding the name in multiple places leads to silent breakage when the project is reorganized.
• Test with the monitor on the second physical output, not the first. Many technicians do their first test on the primary output because the secondary is harder to reach. The first monitor is always \.\DISPLAY1 in Windows; the screen window name is the WinCC name, not the Windows monitor handle. Do not confuse the two.

12. Troubleshooting Matrix

13. Adapting the Pattern to Other Versions

The same pattern works in TIA Portal V13, V15, V16, and V17 with the same VBScript syntax. In TIA Portal V17 and later, you can also use C# scripting, which exposes HmiScreen.ParentScreenWindow directly and avoids the On Error Resume Next guard in the VBScript. For WinCC Unified (V18+), the object model is different: the equivalent property is this.parent in the screen code-behind, and the screen window concept is replaced by Sliding panels in the unified faceplate model. The naming and lookup pattern, however, is identical: every screen window has a fixed name, and the script queries the parent to find out which one is currently active.

14. Standards and Reference Material

Multi-monitor operator stations in process control are not a formally standardized architecture; the closest standards documents are:

• IEC 62443-3-3 — system security requirements, which apply when the two PCs are on the same network as the controller.
• ISA-101.01-2015 — Human-Machine Interfaces for Process Automation Systems. Defines high-performance HMI principles, including the "abnormal situation management" guidance that recommends single-point acknowledgment from a dedicated operator station, which is exactly what the source's eight-monitor setup is implementing.
• Microsoft Windows Hardware Certification — multi-monitor support — defines the behavior of EnumDisplayMonitors and the MONITORINFO structure that the WinCC runtime indirectly relies on.

Verify the specific values in the standards against the current edition; do not assume that the 2015 editions of the documents above are the latest when commissioning a new project.