Configuring KTP600 PN Login and Screen Change Actions

Overview

The SIMATIC KTP600 PN is a 6-inch PROFINET Basic Panel from the Siemens HMI portfolio, programmed with TIA Portal (Totally Integrated Automation Portal) using WinCC Basic or WinCC Comfort. A recurring field issue is the two-press requirement to access a password-protected screen: the operator presses a button, the logon dialog appears, the operator types credentials, and then the operator must press the same button again to navigate to the protected screen. The intuitive expectation is a single press that opens the dialog, validates the user, and navigates to the target screen in one step.

The single-step flow is achievable on a KTP600 PN, but only with the right runtime pattern. Basic Panels (KTP600 PN, KTP1000 Basic, TP1500 Basic, KP300 Basic) do not support user-authored VBScript; they execute system functions as atomic, synchronous calls within an event. The logon dialog is asynchronous — the dialog blocks the event until credentials are submitted — but the screen change attached to the same event does not re-execute on a Basic Panel. This article documents the supported system functions, the runtime event model, three field-proven workflow patterns, the user-administration configuration, and the migration path to a Comfort Panel when script-level control is required.

Applies to: TIA Portal V15.1, V16, V17, V18 (WinCC Basic V15-V18 and WinCC Comfort V15-V18 compiling for a Basic target). Hardware: 6AV6647-0AD11-3AX0 (legacy) and 6AV2 123-2MB03-0AX0 (current) KTP600 PN devices with firmware 16.0.0.0 or later.

KTP600 PN Hardware and Runtime Platform

The KTP600 PN is a 6-inch TFT color panel with resistive touch, six membrane function keys (F1-F6), and a single PROFINET interface at 100 Mbit/s. The display resolution is 640 x 480 pixels with 64K colors. The panel is positioned for small to mid-size machine operator interfaces where the full feature set of a Comfort Panel is not required.

Problem and Root Cause Analysis

The intuitive configuration in TIA Portal is to attach both Log on and ActivateScreen to a button's Click event in that order. The mental model is: open the logon dialog, wait for the operator to type credentials, validate, then jump to the protected screen. On a PC Runtime or a Comfort Panel with VBScript, this works. On a Basic Panel, the runtime executes Log on and immediately ActivateScreen within the same dispatch. The logon dialog appears, the protected screen does not change, and the operator must press the button again to navigate once the authentication state is updated.

What the runtime is doing internally

The WinCC runtime exposes the logon dialog through the ShowLogonDialog system function (also referred to as Log on in the function list editor). Internally, the function posts a modal dialog request to the HMI window manager and returns. The function does not return a status indicating whether authentication succeeded; the success or failure is observed indirectly through two system tags:

• @CurrentUser — a numeric tag (Integer) holding the authorization level of the current user. 0 means logged-out; 1-9 are the configured levels.
• @UserName — a WString tag holding the username of the current user. Empty when logged out.

Why the screen change fails on the first press

Each function in a function list is executed in sequence, but the runtime does not pause for modal dialogs. ActivateScreen fires before the operator has typed a password, so the screen change is performed as an unauthenticated action. The screen protection is enforced by the screen's Authorization check at activation, and the activation is rejected because the current user is still the default "logged-out" user with level 0. The runtime reports no error; the operator simply sees nothing happen. On the second press, the dialog is no longer modal (it was dismissed on the first press), ActivateScreen fires with a non-zero @CurrentUser, and the activation succeeds.

On a Comfort Panel, a VBScript handler can poll or subscribe to @CurrentUser and trigger ActivateScreen after a successful value change. The Basic Panel runtime lacks this scripting layer, so the synchronization must be built out of explicit runtime state — either through a second button press, a PLC handshake, or a tag-change event on a system tag.

Supported System Functions for Button Events

The following system functions are available on the KTP600 PN for the Click, Press, and Release events of a button. The same set applies to the KeyClick, KeyPress, and KeyRelease events of a function key.

Solution Pattern 1: Two-Press Workflow (Default)

This is the out-of-the-box behavior and is fully supported on every Basic Panel. It requires no scripting and no PLC coordination. Two distinct buttons — or two presses of the same button — perform the two operations.

1. Configure the button's Click event with the Log on system function only. Do not attach ActivateScreen in the same function list.
2. Configure a second button (or the same button, conditioned on a tag value) to call ActivateScreen for the protected screen. Set the protected screen's Authorization property to the required level (e.g., 5 for "Operator", 9 for "Administrator").
3. On the first press, the logon dialog opens. The operator enters credentials. On success, @CurrentUser is updated and the operator's authorization is granted.
4. The operator presses the navigation button a second time. ActivateScreen checks the current authorization; the protected screen opens.

This pattern is recommended in the WinCC Basic system manual for operators who need to navigate to restricted areas. The "second press" is a deliberate confirmation step and is preferred in safety-relevant installations where accidental navigation should not be possible.

Use case: Safety-relevant screens, SIL-rated applications, restricted-area access where the operator must explicitly confirm intent.

Solution Pattern 2: PLC-Coordinated Workflow

This pattern uses a single button on the HMI but distributes the synchronization logic to the PLC. The PLC becomes the state machine that handles the "logged on but not yet navigated" state. The HMI reflects state and follows the PLC's command tags.

1. Attach only SetBit("HMI_LoginRequest", 1) and Log on to the button's Click event.
2. In the PLC, on the rising edge of HMI_LoginRequest, write the target screen number to HMI_TargetScreen (e.g., 5 for Screen_5_Operator).
3. On the HMI, configure a Scheduled Task (Tasks -> Add new task) with trigger "Cyclic, 500 ms".
4. Wire the task's Update event to: SetTag("HMI_CurrentUserLevel", @CurrentUser) to mirror the live system tag to a project tag.
5. Wire the OnValueChange event of the HMI_CurrentUserLevel tag to ActivateScreenWithNumber(HMI_TargetScreen) and SetBit("HMI_NavConfirm", 1).

SCL Example for PLC Coordination

The PLC code that reacts to the HMI's HMI_LoginRequest signal can be implemented in SCL (Structured Control Language) in the TIA Portal PLC project. The block below demonstrates a simple state machine that tracks the login request, waits for the user to be logged in, and writes the target screen number.

// SCL block for Pattern 2 - PLC coordination of HMI login + screen change
// Tag declarations (PLC side):
//   "HMI_LoginRequest"     : Bool   // HMI -> PLC, set on button click
//   "HMI_TargetScreen"     : Int    // PLC -> HMI, screen number to activate
//   "HMI_NavConfirm"       : Bool   // HMI -> PLC, screen change processed
//   "HMI_CurrentUserLevel" : Int    // HMI -> PLC, mirrored @CurrentUser

IF "HMI_LoginRequest" AND ("HMI_TargetScreen" = 0) THEN
    "HMI_TargetScreen" := 5;          // Default: navigate to Screen_5
END_IF;

IF "HMI_NavConfirm" THEN
    "HMI_TargetScreen" := 0;          // Clear the target after navigation
    "HMI_LoginRequest" := FALSE;
END_IF;

The PLC state machine ensures that the HMI does not have to be reconfigured when the target screen changes: the PLC writes the target and the HMI follows. This pattern is the right choice when the navigation target depends on PLC state (recipe, mode selector, machine state).

Solution Pattern 3: Global Logon State with Polling Task

This pattern delivers the closest single-press UX on a Basic Panel. The HMI uses a scheduled task to detect the transition of @CurrentUser from 0 (logged-out) to non-zero (logged-in) and performs the screen change in the same cycle.

1. Create an internal HMI tag PendingNavToScreen of type WString, initial value "".
2. Create a project tag CurrentUserSnapshot of type Int, initial value 0.
3. Configure the button's Click event with the following function list (in order):
   1. SetTag("PendingNavToScreen", "Screen_5_Operator") — use the actual screen name.
   2. Log on — opens the logon dialog.
4. Create a Scheduled Task in the HMI project tree (Tasks -> Add new task) with trigger "Cyclic, 500 ms".
5. Wire the task's Update event to SetTag("CurrentUserSnapshot", @CurrentUser).
6. Wire the project tag CurrentUserSnapshot's OnValueChange event to a function list:
   1. ActivateScreen(PendingNavToScreen) — pass the screen name from the tag.
   2. SetTag("PendingNavToScreen", "") — clear the pending target to prevent re-trigger.

Pattern 3 latency between the successful logon and the screen change is one polling cycle (typically 500 ms). This is acceptable for operator-facing screens but not for high-speed applications. The 500 ms interval is also a reasonable balance between responsiveness and CPU load; reduce to 200 ms for faster response or increase to 1 s for lower overhead on heavily loaded panels.

Use case: Operator dashboards, settings screens, parameter editors where one-step access improves UX and the application is not safety-relevant.

Pattern Comparison and Selection Guide

The three patterns have different trade-offs. Use the table below to select the one that fits your application.

Configuring User Administration in TIA Portal

1. Open the HMI device configuration in TIA Portal. In the project tree, right-click the HMI device and select Properties, or double-click Runtime settings.
2. Navigate to Runtime settings -> User administration.
3. Enable User administration. The "Number of users" defaults to 0; raise it to the number of accounts you will create (KTP600 PN supports up to 50).
4. Set Logon timeout (default 5 minutes). The runtime automatically logs out the operator after the configured idle period. Range: 0 (no timeout) to 60 minutes.
5. Set Password aging and minimum length according to your security policy. KTP600 PN enforces a minimum of 1 character and a maximum of 24 characters per password.
6. Create users in the Users table. Assign each user an authorization level (0-9). Convention: 0 = logged-out, 1 = read-only, 5 = operator, 9 = administrator.
7. Compile the project (right-click HMI device -> Compile -> Software) and download to the panel. A full recompile is required after changes to user administration; incremental compilation may not propagate user table changes.

For the full reference on user administration property pages, see the TIA Portal Information System (Help -> Show help) installed with TIA Portal, or the Siemens Industry Online Support portal at support.industry.siemens.com.

Configuring Screen Change Protection

1. Open the screen editor and select the target screen (e.g., Screen_5_Operator).
2. In the Properties pane under Security, set the Authorization dropdown to the required level (e.g., 5).
3. When the runtime receives an ActivateScreen for that screen, it checks the current user's level. If the level is below the required level, the activation is rejected and the operator remains on the current screen.
4. For a screen that should always prompt the user, set Authorization to a level above 0. Level 1 is the typical minimum (read-only user).

Edge Cases and Failure Modes

The patterns above assume a successful first-try logon. The following edge cases must be handled explicitly in the design.

Operator cancels the logon dialog

If the operator presses Cancel on the logon dialog, @CurrentUser remains 0 and the polling task in Pattern 2/3 will not trigger ActivateScreen. The operator remains on the original screen, which is the correct behavior. No additional handling is required.

Operator enters wrong password

The runtime shows a "Logon failed" message inline in the dialog and clears the password field. The operator may retry. The Basic Panel does not enforce account lockout by default; for safety-relevant installations, implement lockout in the PLC by counting consecutive failures and disabling the navigation button via SetBit.

Panel restart during logon

If the panel is power-cycled or restarted while the logon dialog is open, the session ends and the operator is logged out on the next boot. The logon timeout does not persist across restarts.

Concurrent button presses

The Basic Panel runtime serializes events; two simultaneous button presses are queued and processed in the order received. The PendingNavToScreen pattern (Pattern 3) is robust against this: the last write wins, and the polling task fires only once per logon transition.

Verification Procedure

1. Download the project to the KTP600 PN. Power-cycle the panel if the runtime does not refresh automatically.
2. Press the navigation button once. The logon dialog should appear within 200 ms.
3. Enter a valid username and password. The dialog should close; @CurrentUser should update to a non-zero value.
4. If you implemented Pattern 1: press the navigation button a second time. The protected screen should open.
5. If you implemented Pattern 2 or 3: the screen change should occur within one polling cycle (500 ms - 1 s) of the successful logon.
6. Confirm the user is logged out after the configured idle period by reading @CurrentUser from the runtime diagnostics view.
7. Verify that an unauthorized user pressing the button sees the logon dialog and, after entering invalid credentials, remains on the original screen with no screen change.
8. Check the alarm log for any "Authorization check failed" entries; these are emitted when ActivateScreen is rejected.

Troubleshooting Matrix

For a related reference on authentication-timeout behavior in operating systems, see the Microsoft support page on Windows lock screen timeout. The mechanism is different on a Siemens HMI — there is no "lock screen" timeout in the Windows sense — but the principle of separating the dialog presentation from the navigation state applies to both.

Field Commissioning Checklist

• Verify the panel firmware matches the version assumed in the project (TIA Portal -> HMI device -> Properties -> Device Information).
• Confirm the user table was downloaded (read @UserName on the panel after a successful logon to confirm the database is loaded).
• Test the logon timeout by leaving the panel idle for the configured period and verifying automatic logoff.
• Test the screen rejection by logging in as a user with a lower authorization level than the screen requires, and verifying the screen does not open.
• Test the polling task (Pattern 2/3) by adding a temporary SetTag to a debug tag on each Update event, then removing it after verification.
• Document the chosen pattern in the project README so the next maintainer does not attempt to attach ActivateScreen to the Log on event by accident.

FAQ