ProTool Recipe View Per-Button Password Level Workaround

Problem: Single Global Password Level on a ProTool Recipe View

The Recipe View control in ProTool RT and ProTool/Pro 6.x exposes exactly one Password Level property on the view itself (Properties dialog, General tab, field Operator Control > Password Level). There is no property to assign a different level to the bundled buttons (Download, Save, Delete, New, Rename) or to individual value-entry fields inside the same view. Any operator authenticating at the configured level gets every action the view exposes; everyone below the level sees the view as read-only and cannot reach the value-entry fields at all.

The behaviour most projects actually need is a matrix, for example:

• Password level 9 (operator) may press Download only.
• Password level 8 (supervisor) may additionally edit value entries and Save them.
• Password level 1 (administrator) may additionally Delete or Rename recipe records.

The native Recipe View control cannot express this matrix. One of the three workarounds below must be applied. The same limitation is carried forward by every ProTool-based runtime that uses the bundled view, including WinCC flexible 2004 through 2008 SP3.

Root Cause: How the Recipe View Control Is Implemented

The Recipe View is a compound control that wraps the underlying Recipe Manager API into a single HMI object. Its permission interface is the single Password Level property bound to the view itself, not to its child elements. Inside the control, the download/save/delete/new buttons, the data-record list, and the variable grid are treated as one security domain. The full Recipe Manager script API is, however, available to the project engineer; that is exactly what the custom-screen workaround exploits.

Affected Versions and Migration Context

The limitation is independent of the connected PLC. S7-200 PPI, S7-300/400 MPI/Profibus, S7-1200 via ProTool proxy, and third-party PLCs over OPC are all subject to the same Recipe View control.

Prerequisites for the Workarounds

• ProTool RT runtime or ProTool/Pro 6.x configuration installed on the engineering station.
• A configured user administration with at least three levels (1, 8, 9) in Users > User Administration.
• At least one working recipe definition in the project tree (Recipes > New) with one or more data records.
• For the custom-screen and dynamic-script workarounds: familiarity with the ProTool script editor (Tools > Scripts) and the Recipe Manager API.
• Project password known (required for SetProperty calls and for changing protected fields at runtime).

Workaround 1: Duplicate Recipe Views per Password Level

The simplest path is to instantiate the same Recipe View on different screens, set a different password level on each, and route the user to the correct copy after login. The full procedure is documented in the Siemens Industry Online Support HMI Knowledge Base under the ProTool and WinCC flexible recipe entries.

Procedure

1. In the project tree, open Screens and create one additional screen per required password level, e.g. RecipeScreen_L1, RecipeScreen_L8, RecipeScreen_L9.
2. On each screen insert a Recipe View control and bind it to the same recipe definition.
3. Open the Properties of each view and set the Password Level to 1, 8, 9 respectively. Only operators at or below the configured level can interact with the view.
4. On the master screen, add three invisible pushbuttons stacked at the same coordinates. Set the Visibility property of each button to the corresponding operator level.
5. From the user-administration login routine, after a successful login, trigger a screen change to the correct recipe screen using SetScreen or ActivateScreenByNumber. If a logout is detected, return to the read-only view.
6. Disable the on-screen navigation that would let an operator jump directly to a higher-privilege screen. Set the password level of the screen-change button itself to the highest required level.

Drawback

The user must reload the screen after each login / level change, which is visible to the operator. On slow panel PCs (Windows CE, ProTool RT on Windows XP Embedded) the flicker is typically 200-600 ms. This is the workaround the original engineering question was trying to avoid.

Workaround 2: Custom Recipe Screen (Recommended)

Build the recipe screen from individual controls instead of using the bundled Recipe View. The underlying Recipe Manager script functions are then exposed, and each control (button, IO field) can carry its own password level. The recipe file format is identical to the bundled view's, so the project remains compatible with WinCC flexible's Recipes (Simple View) during migration.

Recipe Manager Script Functions

Procedure

1. Create a new screen, e.g. Recipe_Custom.
2. Insert a symbolic IO field for each recipe element. In the Properties dialog set the Password Level individually per field. Value entry fields that should only be written at supervisor level are set to level 8; read-only displays can stay at level 9.
3. Insert three pushbuttons: Download, Save, Delete. Assign Password Level 9, 8, 1 respectively.
4. Open the script editor and write the Click event for each button. Example for the Save button:

   Sub Click(ByVal Item)
       Dim sRec As String
       sRec = GetActiveRecipeName("Recipe_01")
       If sRec = "" Then
           ShowSystemAlarm "No active data record selected"
           Exit Sub
       End If
       SaveDataRecord "Recipe_01", sRec
       ShowSystemAlarm "Recipe " & sRec & " saved"
   End Sub

5. For the Download button, use LoadDataRecord with the name from a recipe-selection IO field, gated by the same GetUserLevel check or, more simply, by the button's own password level:

   Sub Click(ByVal Item)
       Dim sRec As String
       sRec = GetActiveRecipeName("Recipe_01")
       If sRec = "" Then
           ShowSystemAlarm "No active data record selected"
           Exit Sub
       End If
       LoadDataRecord "Recipe_01", sRec
   End Sub

6. Add a Delete button that calls DeleteDataRecord after a ShowMessageBox confirmation dialog (Yes/No, return value 6 = Yes, 7 = No):

   Sub Click(ByVal Item)
       Dim sRec As String
       Dim iRet As Integer
       sRec = GetActiveRecipeName("Recipe_01")
       If sRec = "" Then Exit Sub
       iRet = ShowMessageBox "Delete recipe record " & sRec & "?", 4, 32
       If iRet = 6 Then
           DeleteDataRecord "Recipe_01", sRec
       End If
   End Sub

7. Bind the recipe list to a text list populated by GetDataRecordName in a scheduled script (1 s cycle or on-screen-load). Iterate iIndex = 0 to GetDataRecordNumber("Recipe_01") - 1 and append each non-empty result to a tag-backed text list.

Why This Is Preferred

• No page reload after login.
• Each button and each IO field carries its own password level, matching the real-world access matrix.
• Recipe file format is identical to the bundled view's, so the project remains compatible with WinCC flexible's Recipes simple view during migration.
• The custom screen is easier to localize because each label is a normal text object, not a control property.

Workaround 3: Dynamic Password Assignment via Scripting

If duplicating the screen is not acceptable and the engineering budget allows for a custom screen, the password level of an arbitrary control can be changed at runtime by writing the property via the scripting interface. ProTool exposes the PasswordLevel property on most control objects, and the SetProperty function allows modification at runtime. The project password is required for the call to succeed.

Sub SetButtonLevel(ByVal Item, ByVal NewLevel As Integer)
    ' Project password required; otherwise SetProperty returns -1
    SetProperty Item.PWD_Button_Delete, "PasswordLevel", NewLevel
    SetProperty Item.PWD_Button_Save,   "PasswordLevel", NewLevel
    SetProperty Item.PWD_Button_Download, "PasswordLevel", NewLevel
End Sub

This approach is rarely used because the next page load resets the property to its configured value, but it is valid for transient workflows such as an approval mode toggle that resets when the operator logs out. Call SetButtonLevel from the post-login script of the user administration, then clear it on logout.

User Administration Reference

ProTool stores users and password levels in the project's User Administration table (Users > User Administration). Levels 0-9 are predefined:

Password Level Hierarchy Diagram

Equivalent Behaviour in WinCC flexible

WinCC flexible 2004 SP1 and later carry the same Recipe View control forward from ProTool. The per-button limitation is unchanged, so both Workaround 1 and Workaround 2 apply identically. The script syntax is preserved (LoadDataRecord, SaveDataRecord, DeleteDataRecord), and the custom-screen approach is the documented recommendation in the WinCC flexible Recipes manual. The WinCC flexible entry on Siemens Industry Online Support covers this in detail (search the Knowledge Base for recipe view password).

WinCC flexible 2008 SP2 adds the Recipes (Simple View) control, which is a re-skinned Recipe View and does not change the security model. The Recipes (Advanced View) in WinCC Runtime Advanced still uses a single global password level.

Equivalent Behaviour in TIA Portal (WinCC)

The TIA Portal recipe view (HMI > Recipes > Recipe view in the project tree) addresses the limitation: each toolbar button of the Recipe view can be assigned its own authorization under Properties > Toolbar > Authorization. This is configured per button (Save, Load, Delete, New, Rename, Export, Import) rather than per view. The active user is matched against the project's user administration (Runtime Settings > Users and Roles).

For projects migrating from ProTool, the recipe definition (CSV-compatible format) is importable through TIA Portal's Import recipe function. Custom recipe screens written with LoadDataRecord / SaveDataRecord continue to work in TIA Portal via the equivalent Recipe commands of the HMI tag interface, and the script functions were renamed to LoadDataRecord, SaveDataRecord, DeleteDataRecord but kept the same signatures. Verify behaviour against the current TIA Portal release notes on the Siemens Industry Online Support portal.

Verification Procedure

1. Compile and download the project to the target (RT or panel).
2. Log in as a level-9 operator. Confirm the Download button is enabled and the Save and Delete buttons are disabled (greyed out or hidden per the configured appearance).
3. Log out, log in as a level-8 supervisor. Confirm Save is now enabled and Delete remains disabled. The value-entry IO fields should now accept input.
4. Log out, log in as a level-1 administrator. Confirm Delete is enabled and the rename button is enabled.
5. Trigger a Download of a known-good data record and verify the values appear in the IO fields.
6. Trigger a Save at level 8 and verify the record file timestamp updates on the runtime PC. Check the path defined under Recipes > Properties > Storage Location.
7. Trigger a Delete at level 1 and verify the record is removed from the recipe file. If a confirmation dialog is configured, verify the No path leaves the file intact.
8. Cycle power to the runtime and confirm the recipe file is reloaded from disk on startup (default behaviour for ProTool RT).

Troubleshooting Matrix

Migration Checklist: ProTool / WinCC flexible to TIA Portal

1. Export the ProTool project as a .pnz archive (or WinCC flexible as .flb).
2. In TIA Portal, use Migrate Project to bring the screens and recipes across. Confirm the recipe definition is imported and bound to the correct HMI tags.
3. Replace the ProTool Recipe View control with the TIA Portal Recipe view (HMI > Recipes).
4. Re-assign per-button authorization in the TIA Portal Recipe view Properties > Toolbar > Authorization.
5. Re-test the verification steps above against the new runtime (WinCC Runtime Advanced or Professional).
6. Update any custom script that referenced the bundled view's internal name to use the new control name. LoadDataRecord, SaveDataRecord, DeleteDataRecord retain their signatures across the migration boundary.

Field-Proven Caveats

• The Recipe View control stores its data in the Recipes subdirectory of the project, typically under \Flash\Recipes on a Windows CE panel or C:\Program Files\Siemens\ProTool\Recipes on a PC runtime. Migrating runtime targets means copying the directory across, not just the project file.
• If the runtime target has a touch screen, the password prompt for the login screen must remain accessible. Hiding the login screen with the same password-level trick is a common cause of operators getting locked out after firmware updates.
• The GetUserLevel function returns the highest (most permissive) level of the active user, not the lowest. Projects that use level 1 for "supervisor" and level 9 for "operator" must call GetUserLevel and compare numerically; smaller means more privileged.
• Mixing English, German, and French installs of ProTool RT can produce mismatched message-box return values. Test the message-box return code with a print window on first commissioning.

FAQ