Overview
Siemens WinCC Flexible is the engineering environment used between roughly 2004 and 2011 to configure SIMATIC Panel runtimes ranging from the OP 73 micro operator panel up through the MP 377 multi-panel and the early Comfort-class TP panels that shipped with the legacy WinCC Flexible Runtime image. Although it has been superseded by TIA Portal WinCC (Comfort / Advanced / Professional), a very large installed base continues to run panel images built with WinCC Flexible 2008 SP2, SP3, SP4 and SP5, and field engineers still routinely add new screens, tags, and Scheduler logic to existing projects without migrating.
Displaying the currently logged-in user name on a screen is one of the most frequent small tasks in this environment: it is used for audit trails, role-based screen selection, electronic signature capture, and simple operator reassurance that the panel has accepted their credentials. The naïve approach — calling the GetUserName system function from a button's Click or Press event — only samples the user name at the instant the button is pressed. As soon as the operator logs out, logs in as a different account, or is auto-logged-out by an inactivity timer, the captured string remains static until somebody presses the button again. On panels that only show the user name on the entry screen, the symptom is usually reported as "the second login doesn't show up".
The field-proven pattern, documented in the WinCC Flexible help files and in the Siemens Knowledge Base entry FAQ 25430568, is to drive the read from a Scheduler job under Device Settings. The job is bound to the Change User system event, its action is the Get User Name system function, and the result is written into an internal tag of data type String (or WString on Unicode targets). Every screen that needs to display the user name binds an I/O field to this single internal tag. Because the Scheduler runs globally across the panel runtime, the tag is updated on every authentication transition regardless of which screen is active at the moment of login or logout.
Architecture and Runtime Flow
Understanding the runtime flow clarifies why the Scheduler-based approach is correct and why a button-driven approach fails. The panel runtime maintains a single authentication context that is independent of any screen object. When the operator invokes the system logon dialog (either via a configured button calling ShowLogonDialog or via the panel's system menu), the runtime authenticates the credentials against the user database that was downloaded with the project. On success, the runtime transitions the authentication context and fires the Change User event to any subscribed Scheduler job. The job executes its function list exactly once per transition, writes the user name into the internal tag, and the I/O field on the active screen picks up the new value through standard tag polling.
This is fundamentally different from a button event. A button's Press event executes only when the operator touches that specific button. If the authentication context changes through the system menu, an inactivity timer, or a PLC-triggered Logoff system function, no button event fires and the previously captured value stays in the tag until something else forces a refresh. Moving the read out of the button into the Scheduler decouples the display from operator action.
Prerequisites
- WinCC Flexible 2008 SP2, SP3, SP4, or SP5 installed on the engineering station. Earlier builds (2004, 2005, 2007) expose the same Scheduler and functions but with minor dialog differences.
- A WinCC Flexible project targeting a SIMATIC Panel runtime that supports user administration. Compatible panels include the OP 73, OP 77A, OP 77B, OP 170B, TP 170A, TP 170B, TP 177A, TP 177B, TP 177micro, TP 270, TP 277, OP 270, OP 277, MP 170, MP 177, MP 270, MP 277, MP 370, MP 377, and the C7-635 / C7-636 controllers with integrated panels. Mobile Panels 277 also support this pattern.
- A panel image that supports runtime user administration. Entry-level OP 73 and TP 170A panels require image version V6.0 or higher; older images simply ignore any user administration configuration.
- An installed ProSave or WinCC Flexible transfer utility matching the panel's transfer protocol (serial, MPI/PROFIBUS, Ethernet, or USB).
- The WinCC Flexible Runtime Simulator is strongly recommended for desk testing before going to the panel.
Configure Runtime User Administration
Open the WinCC Flexible project and expand the project tree on the left. Navigate to Runtime User Administration. The administration editor opens with two default empty lists: Groups and Users.
- Define groups first. Typical installations use a hierarchy such as
Operators(read-only screens, no parameter changes),Supervisors(setpoint changes allowed),Maintenance(recipe and I/O forcing allowed), andAdministrators(full access including user management). Group names become available as authorization selectors throughout the project, including in screen object Security properties. - Create user accounts and assign each to a group. The maximum number of users is panel-dependent: 32 on entry-level OP 73 and TP 170A, 100 on TP 177B / OP 277, and 999 on MP 277 / MP 377. Password policies include minimum length (1 to 24 characters), expiry (days), and reuse rules; configure these on the Settings tab of the editor.
- Set the runtime timeout in the same editor. The default inactivity logout is 5 minutes; production panels often use 15 to 30 minutes to balance security and operator convenience.
- Export the user list to a CSV or a removable media card if you plan to transfer the runtime user database independently of the project transfer. The import function is accessible from the panel's Control Panel > Security menu at runtime.
GetUserName function in this state returns an empty string or a localized default such as "PLC User". Always confirm the user database before troubleshooting empty displays.Create the Internal User Name Tag
Tags in WinCC Flexible are managed under Project > Communication > Tags. The internal tag that holds the current user name must use the Internal connection, which means it is stored in panel RAM and is never exchanged with the PLC.
| Property | Recommended Value | Notes |
|---|---|---|
| Name | CurrentUser |
Project-specific; avoid localized characters in tag names |
| Connection | Internal | Always internal for this use case; do not bind to a PLC tag |
| Data type |
String, length 24 |
Use WString, length 32 for MP 377 and Comfort retrofits |
| Acquisition cycle | On change | Reduces polling load on small panels |
| Initial value | Empty string | Runtime fills the tag after first authentication |
The string length must be at least as long as the longest permitted login name. WinCC Flexible restricts login names to 24 characters on ASCII panels and 32 characters on Unicode panels; matching the tag length avoids silent truncation that is hard to spot until somebody logs in with a 20-character username and the last four letters mysteriously disappear.
Configure the Scheduler Job
The Scheduler is reached via Project Tree > Device Settings > Scheduler. Right-click in the empty Scheduler list and choose New Job. The job editor opens with three tabs: General, Event, and Function List.
- On the General tab, set the job name to something descriptive such as
UpdateCurrentUser. Optionally enable Active if it is not enabled by default; without this, the job is saved but ignored at runtime. - Switch to the Event tab. The Event dropdown lists every available runtime trigger. Select Change User. This is the only event that needs to be selected for this use case. Do not also enable a cyclic trigger such as 1 s or 500 ms; a cyclic trigger would re-read the user name constantly without solving the original symptom and adds load that entry-level OP 73 panels cannot afford.
- Switch to the Function List tab. Add the Get User Name system function. In localized builds the function name varies: Obtener nombre de usuario (Spanish), BenutzerNameHolen or GetUserName (German), Obtenir le nom d'utilisateur (French). Browse the function tree under User Administration if it is not visible at the top level.
- Configure the function parameters: the source is implicit (the runtime's current authentication context) and the destination is the internal tag
CurrentUsercreated earlier. Some function variants also expose a Output parameter that lets you write to a script variable; for this pattern, writing directly to the tag is simpler and more reliable. - Save the job and confirm it appears in the Scheduler list with the small green checkmark indicating an active job.
Multiple Scheduler jobs can coexist. The runtime processes jobs in priority order on a fixed scheduler tick; this particular job should not interact with screen navigation, recipe, or logging jobs because its single function call completes in microseconds.
Display the User Name on the Screen
Place an I/O field on the desired screen. In the General properties of the I/O field, configure the following:
- Mode: Output (read-only). Do not use Input/Output because the operator should never be able to type into a field that is meant to display the authenticated user.
-
Tag: the internal tag
CurrentUser. - Field length: at least 24 characters on ASCII panels, 32 on Unicode panels.
- Display format: String.
- Appearance: disable border and background fill if the field is meant to look like a status label rather than an editable input.
Place a short static label such as "Logged in as:" immediately to the left of the I/O field. The static label can be a simple text element; the I/O field itself does not require a label.
Because the tag update is driven by the Scheduler rather than by a screen event, the same tag can be referenced from any number of screens, pop-ups, slide-in screens, and templates without re-engineering. On panel templates, the I/O field propagates automatically to every screen that inherits the template, which means a single tag change updates every screen that uses the template.
Separate Login from Screen Navigation
A common failure mode reported in field support cases is using a single physical button for three actions: Start Session (call ShowLogonDialog), Get User Name (call GetUserName), and Activate Screen (call ActivateScreen). The runtime processes button events in a defined order; mixing the screen-activation call with an explicit GetUserName can result in the I/O field briefly showing the previous user or remaining blank after a logout, because the screen activation can happen before the tag write completes. The robust practice is to dedicate one button to authentication and another to navigation.
| Button | Event | Action(s) | Notes |
|---|---|---|---|
| Login | Press | ShowLogonDialog |
Displays the system logon dialog; do not call GetUserName here, the Scheduler handles it |
| Logout | Press | Logoff |
Clears the authentication context; the tag will become empty on the next Scheduler tick |
| Enter Program | Press |
ActivateScreen to the start screen |
Pure navigation; no user-management calls |
| Change User | Press |
Logoff followed by ShowLogonDialog
|
Convenience button that combines the two authentication events |
This separation is what fixes the symptom where the I/O field stays blank after the user logs out: the Scheduler job picks up every authentication change automatically, so the navigation buttons no longer need any GetUserName call at all.
Audit Trail and PLC Handoff
Many production environments also need to forward the current user name to the PLC for electronic signature, batch record, or 21 CFR Part 11 audit purposes. Once the internal tag CurrentUser holds the user name, a small set of internal Text tags can be used to hand the value to the PLC through a normal Area Pointer or through a script-driven tag copy.
- Define an additional internal tag
CurrentUserToPLCwith the same data type and length, but with a connection assigned to the active PLC (for example S7-300/400 or S7-1200/1500). - On the Change User Scheduler job, add a second function: Set Value (or in VBScript,
SmartTags("CurrentUserToPLC") = SmartTags("CurrentUser")). The two-function job now both refreshes the display tag and writes the value to the PLC. - Alternatively, add a cyclic Scheduler job (for example 2 s) that copies the display tag to the PLC tag. Use this only when the PLC must observe every change, because the cyclic job runs regardless of whether anything changed.
- For audit logs, add a third internal tag of type
DateTimeand set it to the current date/time in the same Scheduler job. This produces a tight ("user", "timestamp") pair that the PLC or an external historian can correlate.
Troubleshooting Matrix
| Symptom | Likely Root Cause | Corrective Action |
|---|---|---|
| I/O field blank on first login | Scheduler trigger set to cyclic, or job pointing to a non-existent tag | Change trigger to Change User event and verify the tag assignment in the function list |
| User shows after first login, blank after user switch |
GetUserName called only from a button Click or Press event |
Move the call into a Scheduler job and bind it to Change User; remove the button event call |
| Display always shows "PLC User" or empty string | User administration not configured, or panel logged out | Define users in Runtime User Administration; confirm image supports it |
| Display truncates long user names | Tag length too small or I/O field length too small | Increase tag string length and I/O field length to at least 24 (32 for WString) |
| Event does not fire in simulation | WinCC Flexible Runtime Simulator not configured for user administration | Open Settings > User Administration in the simulator and load the same users as in the project |
| Spanish / German / French build: function not found | Searching by English name in a localized function list | Browse User Administration subtree; the function is sorted by localized name |
| Tag updates but I/O field does not refresh | I/O field bound to a different tag, or tag acquisition cycle set to Cyclic with a long interval | Re-bind the I/O field to CurrentUser; change acquisition cycle to On change
|
| Tag updates on screen A but not on screen B | I/O field on screen B bound to a local variable or to a tag of the wrong connection | Bind screen B's I/O field to the same internal tag; do not duplicate tags |
| Job exists in project but does not run on the panel | Job disabled, or panel image older than the project requires | Re-enable Active; reflash the panel image via ProSave |
| Job runs but tag stays empty after every logout | Function writes empty string and downstream logic does not handle it | This is expected behavior; an empty string after logout means "no user logged in" |
Verification Procedure
- Compile the project (Project > Compiler > Generate). The consistency check should report no warnings about the Scheduler job or the
CurrentUsertag. - Start the Runtime Simulator (Start > Runtime). The simulator loads the project with its user database; log in as a test user.
- Confirm the I/O field on the start screen displays the test user name immediately after the dialog closes. No button press is required.
- Press the Logout button. The I/O field should clear or display an empty string within one scheduler tick (effectively immediately).
- Press the Login button and authenticate as a second test user. The I/O field should now display the second user name without any further interaction.
- Navigate through every screen that contains the I/O field. Each should display the same current user, because the tag is global.
- Stop the simulator and transfer the project to the physical panel using ProSave. Repeat steps 3 to 6 on the panel to confirm production-runtime behavior.
- Trigger an inactivity logout by waiting longer than the configured timeout. The I/O field should clear automatically; logging back in should restore the display.
Performance and Memory Notes
WinCC Flexible targets a wide range of panel hardware, from the OP 73 micro panel (32 MB RAM, single-core ARM7-class CPU) to the MP 377 (256 MB RAM, XScale). The Scheduler-based pattern is deliberately lightweight: a single function call executed on a single event, writing a single short string into an internal tag. The runtime overhead is negligible even on the OP 73, and the pattern does not require any additional memory beyond the 24 to 32 bytes for the tag itself.
Where the overhead can grow is when engineers add a large number of cyclic Scheduler jobs to also forward the user name to the PLC, refresh a clock tag, log the change to a recipe, and so on. Each cyclic job wakes up on its configured interval regardless of whether anything changed. The recommended pattern is one Change User event-driven job for all user-related updates (display tag, PLC tag, timestamp tag, audit tag), and zero cyclic jobs for this purpose.
Security and Compliance Considerations
The pattern shown here is display-only: it shows the currently authenticated user on screen, which is the same information the runtime already exposes to the PLC and to other system functions. There is no security implication in displaying the user name on a panel that already enforces user-based access control. However, in regulated environments (21 CFR Part 11, EU GMP Annex 11), the display tag should be treated as audit data and not as the system of record. The system of record is the runtime user database and the corresponding PLC or historian log; the I/O field on the panel is for operator feedback only.
Passwords are never accessible through GetUserName or any related function. The function returns only the login name, never the password or the password hash. Engineers do not need to add any redaction logic to the I/O field configuration.
Migration Notes to TIA Portal WinCC
Projects that have been migrated from WinCC Flexible to TIA Portal WinCC (Comfort Panels, Advanced, or Professional Panels) follow the same architectural pattern but with a different navigation path. In TIA Portal the Scheduler lives under Device > Schedules > Tasks, and the GetUserName equivalent is exposed as a system function within the HMI tag management and scripts library. The corresponding Siemens Knowledge Base article FAQ 25430568 documents the older WinCC (not Flexible) implementation using C scripts; the same principle — drive the read from a Scheduler, not from a screen event — applies across all generations of SIMATIC HMI software.
When migrating, the internal tag is automatically translated to a TIA Portal HMI tag with the Internal connection. The Scheduler job is converted to a Schedule with the On user change trigger. Function names are stable across the migration. The I/O field binding is preserved. Most projects can be migrated with no manual rework on this particular feature.
FAQ
Why does my I/O field stay blank after switching users?
The most common cause is that GetUserName is being called only from a button's Click or Press event, so it does not re-execute when the user changes via the system logon dialog or an inactivity logout. Move the call into a Scheduler job triggered by the Change User event and write the result to an internal string tag; the I/O field will then update automatically on every login transition.
Which tag data type should I use for the current user name?
Use String with a length of at least 24 characters for ASCII panels, or WString with a length of at least 32 characters for Unicode panels such as the MP 377 or migrated Comfort Panels. Smaller lengths will truncate long login names without warning, which is hard to spot until somebody tries a 20-character username.
Can I use the same internal tag on every screen?
Yes. Internal tags in WinCC Flexible are global across the entire panel runtime. Defining the CurrentUser tag once and referencing it from every screen or screen template is the recommended approach and avoids the duplication that causes inconsistent displays.
Does the Scheduler job run when no user is logged in?
Yes. The Change User event fires on every authentication transition, including logoff. After a logoff the tag will contain an empty string or the runtime's default anonymous user name, which is the expected behavior. Bind the I/O field display to the empty string explicitly if the panel layout should show a placeholder text such as "—" instead of an empty field.
What is the difference between this pattern in WinCC and WinCC Flexible?
WinCC (the SCADA product, not Flexible) uses C scripting in the Global Script editor with the GetUserName function inside an event-driven project function bound to OnChangeUser; WinCC Flexible (the panel product) uses the Scheduler job with the Change User trigger and the Get User Name system function. Both achieve the same end state but live in different engineering environments and target different runtime hosts.