Fixing Stacked Button Positions in WinCC Unified SCADA

Problem Summary

Operators report that an icon-style button on a Siemens WinCC Unified runtime screen is visually overlapping another control, making the upper button unreadable or un-clickable. The button is not visible in the WinCC Explorer project tree, and search-by-name in the screen editor returns no result. Process inspection (Task Manager, tasklist) shows the visual is owned by a separate executable — commonly OPL.EXE — that is launched together with the WinCC Runtime and is automatically terminated when WinCC closes.

This pattern is a classic indicator that the on-screen element is rendered by an external / 3rd-party application integrated with WinCC, not by a native WinCC screen object. Moving a native WinCC button is a one-property change; moving an externally hosted overlay requires a different workflow because the geometry, z-order, and ownership belong to the parent process.

WinCC Screen Object Hierarchy and Z-Order

Every visible element on a WinCC Unified screen belongs to a single owner process. Native elements (buttons, I/O fields, graphic views, trend controls) are children of the WinCC Runtime process. Their stacking order is governed by:

1. Object creation order — later-created objects render on top of earlier ones by default.
2. Explicit layer / plane — TIA Portal V17+ exposes the Layers pane (0–31) under screen properties; higher layer numbers render above lower ones.
3. Z-order override — Bring to Front / Send to Back context-menu commands manipulate the runtime z-index of a single object inside its layer.

When a button is not a native object, none of the three mechanisms apply. The WinCC Runtime has no knowledge of its position. The only way to move the overlay is to modify the source application that draws it — usually through its own configuration file, registry entry, or screen-coordinate parameters — or to change the WinCC side so the foreign window is reparented, resized, or hidden.

Identifying External or 3rd-Party Processes in WinCC

WinCC supports launching additional executables in three documented patterns. Confirming which pattern is in use is the first diagnostic step.

For the case at hand, the file is named OPL.EXE. The name strongly suggests an OPC Layer wrapper or a vendor-specific OPL (Operator Panel Link / Open Process Layer) application. Verifying the binary origin is mandatory before any modification.

Step-by-step file identification

1. Open Task Manager → Details tab → right-click the OPL.EXE row → Properties.
2. On the General tab, read Location — record the full path (e.g. C:\Program Files\Vendor\OPL\OPL.EXE or D:\SCADA\AddOns\OPL.EXE).
3. On the Details tab, capture Product name, Product version, Original filename, Company, and File version.
4. Switch to the Compatibility tab and confirm the Run this program as an administrator state if UAC is in play.
5. Click Change settings for all users if present, then close.
6. From an elevated command prompt run wmic process where "name='OPL.EXE'" get ProcessId,CommandLine,ExecutablePath to capture the launch arguments. The arguments usually encode the target WinCC project, screen number, or tag namespace.
7. Open the parent directory and inspect siblings: OPL.INI, OPL.CFG, config.xml, *.json, or a sub-folder named Config / Layout are typical sources of geometry data.

Locating OPL.EXE Origin and Configuration

Once the path is known, the configuration file is almost always co-located. Search the directory tree for files modified within the last 12 months:

cd /d "C:\Program Files\<Vendor>\OPL"
dir /s /od *.ini *.cfg *.xml *.json

Open each candidate and search for the keywords position, x, y, left, top, width, height, screen, window, and the literal project or screen identifier. A typical Siemens-era external program block looks like:

[Window]
X=1280
Y=720
W=160
H=160
AlwaysOnTop=1
Layer=TOP
Project=MyPlant
Screen=Overview_01

Editable values are normally integers in pixels relative to the primary monitor's top-left (0,0). Save the file, restart the WinCC Runtime, and verify the new coordinates.

WinCC Unified Button Properties Reference

For comparison, the native button is configured entirely inside TIA Portal. The TIA Portal V21 documentation enumerates the Type field under Properties → General → Content for a Unified button (see Button (RT Unified) – WinCC Unified, TIA Portal V21):

For a native icon button, the geometry is set under Properties → Position & Size:

• X / Y — top-left corner in screen pixels (or % if Adapt to screen size is enabled).
• Width / Height — bounding box.
• Rotation angle — 0 / 90 / 180 / 270 degrees.
• Layer — explicit 0–31 stacking plane.
• Bring to front / Send to back — context menu in the editor.

If the button is not in the screen object list, none of these properties apply. Jumping straight to coordinate editing in WinCC will not work — the edit must happen in the host application.

Moving Buttons in WinCC Unified — Standard Methods

Use this checklist first; if it solves the problem, the button was a native object all along (the OPL process may be unrelated overlay graphics such as a soft keyboard, alarm banner, or vendor logo):

1. Open the project in TIA Portal V18 / V19 / V20 / V21.
2. Expand Project tree → <PLC or HMI device> → Screens → <TargetScreen>.
3. Open the screen. The button should appear in the Outline view (top-right of the editor by default). If absent, right-click in the editor and enable Show → All objects.
4. Click the button once. If the icon is a stacked target, use Tab repeatedly in the editor — TIA cycles through overlapping objects in z-order.
5. Drag the button to the new location, or edit Properties → Position & Size → X / Y numerically.
6. If the button is anchored to screen percent (Adapt mode), use 0–100 values; if in pixels, use the runtime monitor's native resolution minus button width/height.
7. Compile → Download to the HMI / Runtime PC.
8. Verify on the target monitor: open WinCC Runtime, navigate to the screen, and confirm the icon is no longer stacked.

Resolving a Button Owned by OPL.EXE

When the file inspection in the previous section confirms the button is rendered by OPL.EXE, the resolution path is:

Option A — Edit the OPL configuration

1. Locate the OPL configuration file (steps above).
2. Edit the X, Y, W, H fields to clear the overlap. Use the runtime monitor's coordinate system (0,0 = top-left of primary monitor).
3. If a Layer or ZOrder field exists, reduce it below that of the native control so the WinCC button renders on top.
4. Save. Stop the WinCC Runtime. Stop OPL.EXE from Task Manager. Restart the WinCC Runtime — OPL will relaunch and read the new coordinates.

Option B — Re-anchor OPL via startup arguments

Many OPL-style utilities accept CLI switches for window placement:

OPL.EXE /project:MyPlant /screen:Overview_01 /x:1280 /y:720 /w:160 /h:160 /topmost:0

These switches can be edited in:

• WinCC Unified V18+: Project tree → Runtime settings → Services → External runtime windows — though this UI may not be present in all versions; if absent, the OPL launch is controlled by the OS-level auto-start.
• OS auto-start: shell:startup folder, the HKLM\Software\Microsoft\Windows\CurrentVersion\Run registry key, or a scheduled task named with the OPL vendor prefix.
• Siemens legacy path: WinCC\bin\WinCC.ini → [StartUp] → Programs= — older WinCC V7 projects launch external programs here.

Option C — Replace OPL with a native WinCC Unified control

If the OPL-hosted button duplicates functionality that is available as a native Unified control (graphic button, SVG button, custom web control), migrate it:

1. Inventory all functions the OPL button triggers (acknowledge alarm, page change, set tag value).
2. Recreate as a native Button (RT Unified) using the Graphic or Graphic with text type (see TIA Portal V21 Unified button reference).
3. Wire the Click event to the same tag write / screen change / script call.
4. Disable or remove the OPL auto-start entry once the native control is verified.

External Program Integration in WinCC Unified

WinCC Unified can host non-native windows through several documented channels. Knowing which is in use is essential to selecting the right diagnostic.

For Unified V18+ projects the supported external-window concept is the Custom Web Control. Any .exe-level overlay is therefore a legacy or third-party construct; verify with the project's Functional Specification which mechanism was specified at design time.

Step-by-Step Resolution Procedure

Use this consolidated procedure when the button is confirmed to be hosted by OPL.EXE.

1. Capture state. Screenshot the current overlap. Export the WinCC project archive from TIA Portal. Export the OPL configuration directory.
2. Identify the binary. Use Task Manager → Details → OPL.EXE → Properties → Details to capture the full path, product name, version, and company.
3. Read launch arguments. Run wmic process where "name='OPL.EXE'" get CommandLine to determine the WinCC project and screen the overlay is bound to.
4. Locate the configuration file. In the binary's parent directory, sort by modification date and open .ini, .cfg, .xml, and .json candidates. Identify the file containing the X/Y/Width/Height keys.
5. Plan the new geometry. Open the WinCC Unified screen in the TIA editor; read the X / Y / Width / Height of the button that is being overlapped. Set the OPL overlay's X and Y to a non-overlapping coordinate. For a 1920×1080 monitor, a 160×160 button placed at (1700, 880) sits in the bottom-right corner clear of most layouts.
6. Back up the configuration. Copy the original .ini / .xml / .json to <OriginalFileName>.<YYYYMMDD>.bak before editing.
7. Apply the edit. Update the coordinates. If the file supports a Layer or TopMost field, set it so the OPL button does not cover interactive WinCC controls. Save.
8. Restart in controlled order. Stop the WinCC Runtime. Wait for OPL.EXE to exit. Restart the WinCC Runtime. Verify OPL relaunches with the new coordinates.
9. Verify on the runtime monitor. Navigate to the affected screen. Confirm the button is no longer stacked. Click the formerly overlapped WinCC control and confirm it now responds.
10. Document the change. Update the project's SCADA change log with: file edited, before/after coordinates, person responsible, date, and verification screenshot path.

Verification and Regression Checks

After the move, run a short regression set to confirm the fix did not introduce a new fault:

• Click test: Click the formerly overlapped button 10 times. Each click must register (event visible in WinCC tag logging or status display).
• Z-order sweep: Open every screen in the same navigation tree and confirm the OPL overlay does not cover any alarm acknowledgement, emergency stop, or operator-input controls.
• Resolution test: Change the runtime monitor's resolution (e.g. 1920×1080 → 1680×1050) and confirm the OPL overlay remains inside the visible area. Pixel-anchored overlays frequently fall off-screen when the monitor changes.
• Multi-monitor test: If the runtime spans more than one monitor, confirm the OPL overlay appears on the intended monitor and not on the secondary one.
• Process lifecycle test: Close the WinCC Runtime. Confirm OPL.EXE terminates. Re-launch the WinCC Runtime. Confirm OPL.EXE restarts and the new geometry is applied.
• Permission test: Sign out and back in as the operator user (not administrator). Confirm the overlay still launches and the new geometry persists — some OPL binaries re-write configuration files on every launch.

Troubleshooting Matrix

Safety and Operational Notes

Buttons that overlap safety-relevant controls (emergency stop, alarm acknowledge, mode selector) require a formal hazard analysis before any geometry change. The fix must be applied in a test environment first; production deployment must follow the site's Management of Change (MOC) procedure, including:

• Documented risk assessment for the operator's ability to identify and actuate the formerly overlapped control.
• Visual management review at multiple monitor resolutions and brightness settings.
• Operator training update if the button's screen position changes from the trained location.
• Backup of the prior OPL configuration archived for the retention period defined by the site's quality system.