Recipe Name Columns Stay Fixed; Store Part Numbers Separately

The recipe sheet’s Name column is not an editable data field in the described setup, so keep it as a row label and store each product part number in an editable recipe field. The discussion gave no release date for making the column editable; treat any change as a product capability to confirm for the installed version, not as a setting to hunt for during a production stop.

Keep the fixed name as a stable row label

Using labels such as “Setup 1” or “Item 1” works as a basic workaround, but it duplicates the row number already displayed beside the recipe. The important operational distinction is between the sheet’s row-identifying name and the recipe values operators can edit. Do not assume that the name’s text format explains its behavior: the question raised whether it was an ASCII field, but no answer established that as the cause.

Before changing a running recipe workflow, confirm the exact HMI or recipe software, installed version, and sheet being used. The 2011 exchange identifies no manufacturer, model, software version, or current product documentation. If the installed product exposes a property or configuration option for editing the name, verify it in the product’s own documentation before treating that as supported configuration.

Check: Open a non-production recipe sheet and determine whether the name is editable in the normal editing path or explicitly configurable. If it is not, move to a separate recipe field rather than trying to bypass the interface.

Put the part number in an editable recipe field

Use an editable field for the product identifier, preferably the first field operators encounter, and label it clearly as a part number or product ID. This preserves the existing recipe-sheet behavior while making the useful value visible where the operator needs it. Keep the name field as a short, stable row label if the sheet requires one.

1. Identify an editable field with enough capacity for the actual part number format.
2. Give the field a label that distinguishes the identifier from process settings.
3. Enter a part number in a test recipe and save it using the normal recipe workflow.
4. Reopen or load the saved recipe and confirm the part number remains associated with that recipe.

Do not repurpose a field that already controls a machine setting without checking its use in the recipe and control logic. An identifier field must remain descriptive data; it must not accidentally alter a setpoint or permissive.

Check: Save, reload, and inspect a test recipe. Confirm the displayed part number matches the intended recipe and that no unrelated value or machine behavior changed.

Use a naming convention only as a temporary restore

If operators currently rely on the name column to distinguish recipes, retain a readable label there until the separate identifier field is in place and validated. A temporary convention such as “Item 1” may be less useful than a part number, but it is safer than changing recipe definitions during a shift without confirming how the HMI stores and transfers recipe data.

Once the editable identifier is verified, update operator instructions and any local recipe-entry procedure to use that field. Avoid keeping two competing identifiers that can drift: for example, a part number in the name and a different part number in the editable field. When both must be displayed, define which field is authoritative and check them during recipe creation.

Check: Have an operator identify the correct recipe using the visible editable part-number field without relying on a duplicate or ambiguous label.

Test recipe selection and transfer before production

A displayed identifier is useful only if it stays attached to the intended recipe through the normal selection and load process. Test the complete path on a non-production recipe or in an approved test window: create or edit the recipe, save it, select it, and confirm the identifier and expected recipe values appear together. The specific transfer mechanism and storage location depend on the installed product and configuration, so use its documented workflow rather than assuming a particular memory or tag arrangement.

Compare the loaded recipe against the approved values, not just the displayed part number. If the product identifier is correct but the process values are from another recipe, stop and investigate recipe selection, save, and transfer behavior before returning the sheet to operators.

Check: Confirm the identifier and associated recipe values match after a full save-and-load cycle, then restore the tested recipe state before releasing the equipment.

Confirm product support before attempting to edit the name

The historical response said the editable name column was on an improvement list, but supplied no implementation date or affected product versions. That does not establish that the feature exists in the current installation. Do not spend production time looking for an undocumented toggle, editing project files, or forcing changes through an unsupported data path.

Record the HMI/recipe product and version, the sheet name, what edit action was attempted, and whether the column is locked in both runtime and configuration. Use those details to check official product documentation or ask the manufacturer’s official support channel whether the installed version supports editable recipe names. Until confirmed, the separate editable identifier field is the safer workaround.

Check: The installed-version documentation or official support confirms whether the name field can be changed; otherwise retain the workaround.

FAQ