Fixing WinCC Logon Dialog That Opens Only Once at Runtime

Failure Signature and Scope

No error box, no entry in the message list, no script fault — and the button stays dead until the next activate cycle. That signature localizes the fault to state held inside the running process, not to a project configuration or an operator permission. The observed sequence on a PCS 7 OS is fixed: runtime starts, the SIMATIC Logon dialog is raised automatically, the operator presses Cancel, and from that moment the logon button in the overview area produces nothing. Only a full deactivate and reactivate of the WinCC project brings the dialog back.

Two terms, defined once. The logon area is the fixed screen region that the OS Project Editor generates in a Basic Process Control project; it carries the user display and the logon button. The logon dialog is the modal window supplied by SIMATIC Logon — it is not a WinCC picture. WinCC only requests it.

Bound the scope before touching anything. The same behavior showing up in several independently built projects that all use the OS Project Editor rules out one corrupted picture and points at the shared logon request path and the installed software state on the station.

Mechanism Behind the Single-Shot Dialog

Startup dialog and button share one path. The automatic dialog at activation and the dialog requested by the button both go through the same SIMATIC Logon component, which owns the window and permits one instance at a time. Two guards decide whether a second request produces a visible window.

The first guard is the component's internal "dialog already displayed" flag. Opening the window sets it; every close path — OK, Cancel, timeout — has to clear it. When the Cancel path leaves it set, each later request returns immediately and silently. Nothing is logged because, from the component's view, a dialog is already up.

The second guard applies when the logon area realizes the dialog through a picture window rather than a direct call. There the Display property is the flag. A button action that reopens the window by toggling a stored state, instead of writing Display = TRUE unconditionally, desynchronizes the moment the operator closes the window by any route other than the one the script expects.

Both flags live in the runtime process address space. Deactivating the project destroys the process and the flags with it, which is precisely why the only working workaround is an activate cycle and why the diagnostics stay empty. A third possibility produces the same visible result for a different reason: the button action never executes at all. Separating those two cases is the first branch in the check sequence.

Check Sequence

Check 5 catches the most common self-inflicted variant. A logon button that carries an operator authorization is unusable by a logged-off operator by definition; it will appear dead in exactly the situation it exists for. Check 6 is the one that decides whether you patch software or repair a picture, so do not skip it because the fault "is obviously a bug".

Version Baseline and Update Level

Resolve the baseline before selecting an update. A report that opens as "WinCC 7.5 OS Server" and is later restated as "PCS 7 V9.0 SP3 with WinCC V7.4 Update 14" describes two different software trains with two different update paths. Decide by reading the installed version on the station that shows the fault — WinCC Explorer Help > About plus the Siemens installed-software list — not from project documentation or memory.

Five cumulative update levels separate Update 14 from Update 19 on the PCS 7 V9.0 SP3 branch. Cumulative updates roll up corrections across the graphics, runtime and logon paths, so a station sitting five levels back is not a defensible starting point for a defect report. One hard rule applies on a PCS 7 station: install only WinCC updates that are released for that PCS 7 version, because PCS 7 carries its own compatibility approval independent of the WinCC update train.

Remediation Procedure and Recurring Pitfalls

1. Record version and update level on every station — engineering station, both servers of a redundant OS pair, and every OS client. Mixed levels are a fault source of their own.
2. Confirm in the Siemens compatibility documentation that Update 19 is released for PCS 7 V9.0 SP3 before you stage it.
3. Back up the multiproject on the ES and take a full backup of each OS station.
4. Deactivate runtime on all OS stations, taking the redundant partner second so the process stays observed as long as possible.
5. Install on the engineering station first, then the OS servers, then the OS clients. Reboot where the installer asks for it.
6. If the logon area picture was hand-modified after an earlier version migration, regenerate the standard area pictures with the OS Project Editor in a copy of the project, diff the generated button action against the customized one, and carry across only the deltas you actually need.
7. Download the OS to the servers — a full download when standard pictures changed — and reactivate.
8. Re-read version and update level on every station and confirm they are identical.

Pitfalls that keep recurring on this class of station: gating the logon button behind an operator authorization; copying @-prefixed standard pictures from an older project instead of regenerating them; leaving the OS clients one update level behind the servers; widening SIMATIC Logon group rights in the belief that a missing dialog is a permission failure; and patching before checking whether an always-on-top runtime window is simply covering a dialog that did open.

Verification Checks

1. Check 1 — Cancel loop. Cold-start runtime, cancel the startup dialog, click the logon button. Expect the dialog immediately. Repeat cancel-and-click five times in one runtime session; expect the dialog on every iteration.
2. Check 2 — Logon accounting. Log on with a valid account. Expect an operator logon message in the WinCC message list and a matching SIMATIC Logon entry in the Windows Application event log with the same timestamp.
3. Check 3 — Authorization effect. Operate an object that requires an authorization. Expect it operable while logged on and locked again after logoff, proving the dialog returned a real session rather than closing quietly.
4. Check 4 — Distribution. Repeat Check 1 on each OS client and on the redundant server after a manual switchover. Expect identical behavior on every node.
5. Check 5 — Automatic logoff path. Leave runtime up past the configured auto-logoff time; after the automatic logoff, click the logon button. Expect the dialog to open, which proves the instance flag clears on every close path and not only on Cancel.

FAQ