Resolving TIA Portal V15 RecipeView 'Command Not Possible' Error

Resolving TIA Portal V15 RecipeView 'Command Not Possible' Error in WinCC Comfort/Advanced Runtime

The "Command not possible" runtime error raised when a button calls RecipeViewNewDataRecord or RecipeViewSaveDataRecord on a Recipe View widget configured without a visible recipe table is a known restriction in TIA Portal V15 with WinCC Comfort/Advanced. The error appears on ComfortPanel, PC Runtime, and Panel PC (Windows 10 Embedded) targets when the recipe view is operated in non-table mode. This reference documents the root cause, the affected system function catalog entries, four field-proven workarounds, and a step-by-step verification procedure.

1. Problem Statement

A WinCC Comfort/Advanced project is configured with a single Recipe View widget that displays only the recipe name drop-down and the data record list (no table). Synchronization between HMI tags and PLC tags is disabled because the application requires tag manipulation in the PLC prior to saving a record. Two buttons on the screen are configured with the following system functions:

• Button "New" → RecipeViewNewDataRecord
• Button "Save As" → RecipeViewSaveDataRecord

Pressing either button generates the runtime error "Command not possible" (German: "Befehl momentan nicht möglich", system message ID 130001 family). When the same buttons are configured on a Recipe View that has the table enabled, both functions execute correctly and write the new data record to the recipe CSV file. The application requirement, however, is to keep the table hidden from the operator while still allowing record creation and "save as" operations.

2. Affected Software and Hardware Environment

The same restriction is reported on later V15.x updates and on V16 with the same symptom; engineering-side correction typically requires a configuration change rather than a service pack upgrade.

3. Root Cause Analysis

The Recipe View is implemented internally as a complex widget in the WinCC Comfort/Advanced graphic runtime. Complex widgets (Recipe View, Alarm View, Trend View, f(t)/f(x) View, User View, Browser, HTML browser) are rendered above the base layer of basic objects and have a fixed z-order priority that cannot be changed by overlapping basic objects such as rectangles, IO fields, or text fields. This priority model is documented in the WinCC Comfort/Advanced manual under "Complex widgets / Display hierarchy".

The internal state machine of the Recipe View distinguishes two operating modes:

1. Table-backed mode – the table area is the source of truth for record selection, record editing, and record creation. The system functions RecipeViewNewDataRecord, RecipeViewSaveDataRecord, RecipeViewDeleteDataRecord, and RecipeViewRenameDataRecord all interact with the table's row pointer.
2. Selection-only mode – only the name drop-down and the record number drop-down are rendered. No row pointer exists in the widget, so the four record-mutation system functions cannot resolve a target row and reject the request with 130001 "Command not possible".

The runtime error is therefore not a bug but a design choice: the system function API of the Recipe View was designed to operate on the table buffer. Disabling synchronization does not change this; it only affects whether the values are written back to the PLC tags immediately after a tag change.

4. Error Code and System Function Reference

Only the four record-mutation functions require the table pointer. Read-only and selection functions are pointer-independent and continue to operate in selection-only mode. This table is the basis for choosing the correct workaround in the next sections.

5. Workaround 1 – Enable the Table and Animate Its Visibility

This is the most portable solution and is supported on every runtime target (Comfort Panel, Panel PC, PC Runtime). It leaves the widget structure intact and only hides the table region from the operator.

5.1 Procedure

1. Open the screen containing the Recipe View in the TIA Portal graphics editor.
2. Select the Recipe View widget, open the Properties pane, and switch to the Layout tab.
3. Set the Table property to "Show" (do not leave it as "Hide"). The widget now renders the table area internally even if you do not see it on screen yet.
4. Drag the Recipe View in the editor so that the table area is positioned outside the visible screen area, or keep it on-screen and hide it in step 5.
5. Select the table region of the Recipe View, open the Animations tab in the Properties pane, and add a new Visibility animation.
6. Configure the animation with a constant value of 0 (invisible) or tie it to a boolean HMI tag that defaults to 0. The table is still rendered internally, so the system functions resolve their target row correctly, but the operator never sees it.
7. Compile the project and download to the HMI/runtime.

5.2 Verification

After the download, the operator should see only the drop-down fields and the function buttons. Press "New" – a new row is created in the CSV. Press "Save As" – the runtime prompts for a new name and writes the record. No 130001 error is raised.

6. Workaround 2 – Two-Recipe-View Architecture

This approach uses two stacked Recipe View widgets: one for the operator-facing drop-down fields and one "service" Recipe View with the table enabled. Buttons on the operator view are wired to the service view by ID.

6.1 Procedure

1. Insert two Recipe View widgets in the same screen, both bound to the same recipe.
2. Service view – configure the table as Show, set the position outside the screen or hide it via a Visibility animation as in Workaround 1. The widget remains addressable by the system function's widget reference parameter.
3. Operator view – configure it as drop-down only. Place it on top of the service view in the editor.
4. On the "New" and "Save As" buttons, select the RecipeViewNewDataRecord / RecipeViewSaveDataRecord system function and point the widget reference parameter to the service view, not the operator view. Most engineers miss this: the system function must be told which widget to operate on. In the configuration dialog the widget selection is in the second drop-down after the function name.
5. Wire the operator-facing drop-down to write to an HMI tag (e.g. CurrentRecordName). Use the RecipeViewSetDataRecordName system function on the service view to apply the selection before the record operation runs.

6.2 Sample Button Configuration (Operator View)

Event:      Click on "New" button
Function 1: RecipeViewSetDataRecordName
            → Widget: ServiceRecipeView
            → Name source: HMI tag "CurrentRecordName"
Function 2: RecipeViewNewDataRecord
            → Widget: ServiceRecipeView

7. Workaround 3 – VBScript Direct Recipe I/O (PC Runtime / WinCC Advanced only)

WinCC Comfort/Advanced PC Runtime and the Advanced Runtime on Panel PC support VBScript with the SmartTags, HMIRuntime, and DataSet objects. Comfort Panels themselves do not execute VBScript, so this workaround applies only to the PC-class targets listed in the affected environment.

7.1 Create a New Data Record

' VBS on a button "New"
Dim oRecipe
Set oRecipe = HMIRuntime.Recipes("MyRecipe")

' Set HMI tag values that participate in the recipe
oRecipe.GetDataRecord SmartTags("CurrentRecordName").Value

' Modify the record in memory
oRecipe.Name = "NewRecord_" & Year(Now) & "_" & Second(Now)

' Write the in-memory record back to the recipe CSV
oRecipe.SaveAsDataRecord oRecipe.Name

Set oRecipe = Nothing

7.2 Overwrite an Existing Record

Dim oRecipe
Set oRecipe = HMIRuntime.Recipes("MyRecipe")
oRecipe.GetDataRecord SmartTags("CurrentRecordName").Value
' apply any tag manipulation here
oRecipe.SaveDataRecord SmartTags("CurrentRecordName").Value
Set oRecipe = Nothing

7.3 PLC Tag Manipulation Sequence

Because synchronization with the PLC is disabled in the original project, the script must explicitly push the HMI-side values down to the PLC before the recipe read, and pull the PLC results back before the recipe write. The recommended pattern is:

1. Trigger a write-to-PLC job using a marker tag (e.g. Job_WriteTags) in the PLC. Wait for the PLC's Job_Ack tag to come back high.
2. Call oRecipe.GetDataRecord to load the in-memory snapshot.
3. Trigger a read-from-PLC job using a second marker tag. Wait for the matching Job_Ack.
4. Call oRecipe.SaveAsDataRecord or oRecipe.SaveDataRecord to commit.

This is the same hand-shake pattern that the Recipe View's synchronization uses internally; replicating it in the script restores the symmetry that the disabled synchronization flag removed.

8. Workaround 4 – Decouple Record Operations from the Widget

The four failing system functions all require a Recipe View reference. Three alternative system functions operate on the recipe directly without any widget reference:

• LoadDataRecordFromPLC – populates HMI tags from a named record in a named recipe.
• SaveDataRecordToPLC – writes the current HMI tag values to a named record in a named recipe.
• SaveAsDataRecordToPLC – creates a new record with a fresh name and writes the current HMI tag values.

8.1 Procedure

1. Remove the Recipe View widget from the screen entirely (or keep it read-only for display purposes).
2. Add an IO field bound to an HMI tag that holds the current record name (e.g. RecipeName). This is the operator's drop-down replacement.
3. On the "New" button, configure SaveAsDataRecordToPLC with the recipe name from a fixed HMI tag or a project constant. The runtime generates a unique record name (recipe-name + sequential index) and writes the data record to the recipe CSV.
4. On the "Save As" button, prompt the operator for a new name with a built-in input dialog (system function ShowInputBox) and feed the result into SaveAsDataRecordToPLC.
5. Wire the PLC manipulation job to a tag change event on the IO field, not to a Recipe View event.

This is the cleanest solution for projects that do not need the Recipe View at all and only need the recipe CSV as a storage mechanism. The trade-off is that the operator no longer sees the record list in a formatted widget; you must rebuild the list with a symbolic IO field, a text list, or a custom VBScript pop-up.

9. Choosing the Right Workaround

10. Verification Procedure

1. CSV inspection: After pressing "New", export the recipe from the HMI (Project tree → Recipes → right-click → Export) and open the CSV in a text editor. A new row with the expected column count and the new record name should be present.
2. Error queue: Open the runtime's Diagnostic Viewer on the HMI. No 130001 entry should appear in the last operating session.
3. PLC trace: Trigger the read/write handshake tags in the PLC and confirm the data record values match the values seen in the recipe CSV.
4. Reload test: Restart the HMI runtime (warm restart), open the screen, select the newly created record from the drop-down, press "Load". The IO fields should populate with the values from the CSV row.
5. Round-trip test: Edit a value, press "Save As" with a new name, restart the HMI, reload both records and confirm the values are independent and correct.

11. Commissioning Checklist

• Confirm the TIA Portal project matches the HMI firmware with the WinCC Comfort/Advanced compatibility tool.
• Disable the "Synchronization" flag on the recipe only if the PLC handshake is implemented at the application level (jobs and acks), otherwise the HMI will overwrite PLC values that the PLC is in the process of computing.
• Configure the Visibility animation on the table with a constant 0 or a tag that the operator cannot toggle. If the operator can flip the tag, the table will appear and may break the layout of nearby IO fields.
• On a Panel PC running Windows 10 Embedded, the recipe CSV path defaults to C:\ProgramData\Siemens\Automation\Recipes\. Verify that the runtime user has write permission to this directory. Read-only access produces a different runtime error (130005 "File access error") which is sometimes mistaken for 130001.
• Back up the recipe CSV before any firmware update. The CSV is the source of truth for the on-HMI recipe database.
• If the project is upgraded to V16 or later, re-test the workaround. The Recipe View widget received changes in V17 that allow record creation in selection-only mode; check the firmware release notes before deciding which workaround to keep.

12. Field-Proven Pitfalls

• Wrong widget reference. When wiring the system function in Workaround 2, the widget drop-down sometimes defaults to the most recently selected widget on the screen. Verify the widget ID in the HMI tags tab before downloading.
• Animation re-trigger. If the visibility animation is bound to a tag that is updated every cycle (e.g. a heartbeat), the widget re-paints continuously. Use a static tag or a constant.
• Multiple recipe views on the same screen. Only one Recipe View can be the "active" widget at a time. The other widget still receives events but cannot be the focus of a record-mutation system function. Use a tag-based selection to switch the active widget before calling the record-mutation function.
• CSV path on Panel PC. The runtime stores the recipe in the user profile path by default. If the Panel PC is configured with a read-only user profile, the runtime silently falls back to a temporary location and the records vanish on the next restart. Set the path explicitly in the HMI device configuration under Runtime settings → Recipes → Storage path.
• Trigger order in VBScript. The PLC handshake must be awaited with a polling loop or with the WaitFor method. A Sleep call is not enough because the runtime is single-threaded per script invocation and the PLC acks are read by the same script.

13. Related System Functions and Tools

• GetDataRecordTagsFromPLC – reads the HMI tags that are bound to a recipe from the PLC.
• SetDataRecordTagsToPLC – writes the HMI tag values that are bound to a recipe to the PLC.
• GetDataRecordName / SetDataRecordName – manipulates the active record name on the Recipe View.
• ExportDataRecords / ImportDataRecords – bulk operations on the recipe CSV.
• ClearDataRecord – resets the in-memory snapshot to default values.
• Project tree → Recipes → right-click → Check consistency – engineering-side validation that catches most wiring errors at compile time.