Put operator notes in the HMI recipe with dynamic text

Keep the notes in the same recipe as the values

A recipe earns its keep by moving one product's whole set of values in a single load. Treat the setup notes as part of that set.

The arrangement that fails looks like this: two recipes, one for values and one for comments, with the comments held in the panel. After the project downloads, the comments recipe's Load button is gray. The values recipe still loads, which tells you the path from the engineering PC to the panel is fine; the gray control belongs to the comments recipe's internal arrangement. Combining the comments into the values recipe brings the Load control back, displays the notes, and makes them editable.

What you need

• The values recipe that already loads your products into the PLC, with its selection list and Load control left as they are.
• The comment text for each product, ready to move into string fields.
• A comments screen with one dynamic text object per note field.
• A text-entry object for every note field an operator is allowed to type in.
• A test download to the panel before the operators see the change.

Build the combined recipe and the comments screen

1. Open the values recipe that already works. Leave the product selection and Load control doing their current job.
2. Add one string field per note line, for example a first and a second note field. Short, plain field names keep the screen bindings readable.
3. Move each product's comment text into those fields, so every note stays with its own product.
4. Remove the separate comments recipe. Two recipes for one product is the arrangement that grayed the Load control.
5. On the comments screen, place one dynamic text object per note field and bind it to that field in the recipe. If the dynamic text object shows one character instead of the note, the binding points at the wrong data, so check the field before touching the screen.
6. Wherever operators type, place a text-entry object bound to the same field the dynamic text reads, so display and edit point at one value. Give the typing a save path by saving the screen input to recipe storage with a second button set.
7. If operators may change notes but not process values, set the recipe screen read-only for operators on the value columns and leave the note fields open.
8. Point the comments screen at the same selection the values use, so the product chosen on screen is the product whose notes appear. When the controller has to catch each load, let the PLC catch the recipe load with a handshake tag.
9. Download and walk the checks below with two products you know well.

How long one note can be

Text entry at this class of panel writes into a string tag, and that tag is limited to 128 characters. A longer note does not stretch the tag; you add fields, and every field you add carries the same limit again. Make the split visible on the screen: label the areas Line 1 and Line 2, so the operator knows a long note carries on in the next field.

String data on the controller side has its own declared maximum, written in square brackets in the declaration, and some engineering packages default that maximum to 32 characters until you raise it. Declare any string that carries a recipe name as STRING[25] or larger, and declare the note fields to the length you actually designed. If the recipe table lives in the controller instead of the panel, storing recipe tables in PLC memory and loading the values keeps the same one-selection rule.

Example: 50 products with two note lines

Inputs, and where each comes from:

• 50 products on the line, the count this screen serves.
• 128 characters per string tag, the documented limit for text entry at this panel class.
• Two note fields per product, the design choice this example sizes.
• One dynamic text object plus one text-entry object per field on the comments screen.

Rule in words: every note field carries up to 128 characters, and the number of screen objects follows the number of fields, one display object and one entry object each. The sample recipe sheet instead needs one load control per product.

Arithmetic:

• Note capacity per product: 2 fields × 128 characters = 256 characters.
• Note values stored: 50 products × 2 fields = 100 string values in the recipe.
• Sample-sheet route: 50 products × 1 load control each = 50 controls on one screen.
• Combined recipe: 1 selection list and 1 Load control, plus 2 dynamic text objects and 2 text-entry objects on the comments screen.

Result and decision: two fields cover any note up to 256 characters. When a real note passes 128 characters, add a field; each field costs one more line in the recipe and one more pair of screen objects. The selection list and the Load control stay at one each whatever the product count.

Recommendation: put the notes in the values recipe as two string fields bound to dynamic text objects, and add a third field only when a real note outgrows 256 characters. Keep a separate comments recipe only for notes a different crew loads on its own schedule, and give that crew its own Load control.

Check it worked

• Select a product you know. The Load control is active, not gray.
• Load it, then read two or three tags in the controller against that product's numbers.
• Open the comments screen. The notes shown belong to the product just selected.
• Pick a different product without loading. The dynamic text changes with the selection, so the screen never shows one product's notes beside another product's values.
• Type into a note field. The dynamic text beside it shows what you typed.
• Enter the longest real note and read it back. Nothing important sits past the field's limit.
• Power-cycle the panel, reload the recipe, and read the note again. Whether an edited note survives power and reload is the one behavior to verify yourself: test it once and record the answer, because that result decides where the notes must be stored.
• Run the whole pass with the full product count before the operators get the screen.

Questions