A recipe is a named record of stored values, each tied to its destination register, and one trigger that writes them all. An HMI recipe function and a chain of PLC move instructions are the same operation with a different owner. Troubleshooting splits at the transfer boundary: wrong stored value, value that never arrived, or logic downstream.
A recipe is a named record of stored values, each value tied to the register it belongs in, plus one trigger that writes the whole set. That is the entire term. An operator selects part X, the record is written to its destinations, and the machine logic sets up from what landed there. The chain of move instructions you build in the PLC and the recipe function built into an HMI panel perform the same operation. Documentation for common HMI recipe functions describes the same three parts you build by hand: pre-defined data, pre-defined destinations, and a transfer to the controller on selection. What differs between the two is who stores the record and who fires the write, and that difference is exactly where you look when the wrong setup appears.
What a recipe holds
Three parts make up any recipe, on either side.
- The record: the stored values for one part, held together under the part's name or number.
- The mapping: the destination tied to each value, the working register the machine logic reads.
- The trigger: the action that writes the whole record into those destinations as one operation.
Stored values act on the machine only after that write. A record in storage positions no station and arms no actuator. Working registers are what the logic consumes while the machine runs, so keep stored data and working data at separate addresses and label both, so one data view can show them side by side.
On the HMI side, the record lives in panel memory. You define the items and each item's destination in the controller, and a load action at runtime writes the record's values to the controller. On the PLC side, the record is a block of controller memory, the operator writes a selection number, and MOV rungs copy each value to its working register. Both paths end in the same place: new numbers in the registers the logic reads.
The same job with a different owner
| HMI recipe function | PLC selection and moves | |
|---|---|---|
| Where the record lives | Panel memory, edited at the panel | Controller memory, part of the program data |
| What selection does | A load action writes every item to its configured destination | The selection number indexes the table, and MOV rungs write each value |
| How destinations are set | Per item in the recipe configuration; one documented bulk mode writes consecutive addresses starting from a single designated address | Named in the rungs, one destination per value |
| What to audit | The item list and the destinations together, plus a transfer-done state where the application provides one | The selection condition and every destination rung |
The machine cannot tell the two apart. Both leave the working registers holding the selected part's values. Choose by who edits the data and how the load must be sequenced; the write itself is the same operation either way.
Where the transfer boundary sits
The boundary is the write that carries stored values into working registers. Upstream of it is record content. On it are selection and mapping. Downstream of it is everything that consumes the values: scaling, positioning commands, arming outputs, the actuators themselves.
A wrong setup lives in exactly one of those three places, and each place has a different fix. That is the practical value of keeping stored and working values separate: with both visible in one data view, you stand at the boundary and see which side of it the fault is on.
What a selection does on the machine
On a feed-through machine the sequence runs like this. The operator selects the part. The record is written to the working registers as one operation. The logic reads the new values, commands the station positions along the travel, and sets the bits that arm the motors and actuators acting on the work piece. The machine runs the part on that setup.
One rule belongs in every version of this, on either side of the boundary: hold setup motion until the whole record has landed, and check the incoming values against the machine's permitted range before they can command motion. A half-written record with one station position missing can drive an axis to a place it must never go.
Example: loading part X on a four-station feed-through machine
Inputs, each with its source:
- Four station positions along the travel, one per station: the feed-through case this article is about.
- Each position stored as a 32-bit floating-point value, which occupies two 16-bit words (IEEE 754 single precision). The word order at the destination must match the order in the record.
- Three actuator arming bits, packed into one 16-bit word.
- Destinations in one consecutive block, matching the documented bulk mode in the table above: consecutive addresses from a single designated address.
- Forty parts in the library, a typical count for this class of machine.
Rule in words: record size equals position words plus the bit word. Table size equals record size times the number of parts. The load is one write of the record, and the load is good when every destination word equals its record word.
Arithmetic:
- Positions: 4 stations x 2 words = 8 words
- Arming bits: 3 bits packed into 1 word
- Record size: 8 + 1 = 9 words
- Library: 40 parts x 9 words = 360 words of retentive storage
- Post-load check: 9 word comparisons
Result: one selection writes 9 words, and the 40-part library occupies 360 words.
Decision: allow zero mismatches. If all 9 words match, the boundary is clean and any wrong setup is downstream of it. If one station's two words disagree while the other seven match, that item's mapping is the suspect; fix the destination and reload. If the disagreement sits at the tail of the block, the transfer stopped early; block the setup and load again. Where the recipe function provides a transfer-done state, use it, and still run the 9 word comparisons once at commissioning.
Splitting a wrong setup into three causes
Work the path in this order.
- Wrong value in the record. Open the record and read the value yourself before touching logic. Fix the record and reload. If records go wrong after being right, find every path that can write a record; capturing the running setup as a new record is its own job, covered in saving operator recipes from an HMI with no save button.
- Right value in the record, stale or wrong at the destination. Check the selection first: the part the operator picked and the pointer that indexes the table. Keeping that indirect register selection and the math in the PLC makes the index visible in a data view. Then compare every destination word against the record. Then check the trigger condition that fires the write and the done state that closes it.
- Right value at the destination, machine still wrong. Look downstream in this order: units and scaling between the register and the physical command; a second writer to the same register; logic that copied the value once at cycle start and is running on the copy. For a position that displays oddly, check the two-word order first, as with a PLC float stored in two word registers. For the packed arming bits, splitting the bits of a 32-bit register into discrete tags shows the extraction.
Most wrong setups die at the destination compare. One data view, nine comparisons, and you know which third of the path you are in.
Which side should own the recipe
Recommendation: keep the record in the panel's recipe function when operators or supervisors must edit values or swap records at the machine; keep the table in the controller when values may change only with a program change, or when the load must be sequenced with machine state inside the PLC's own logic. Between those cases either side works, because the machine sees the same write. If the library is growing, choosing a PLC for recipe storage walks the memory decision, and storing recipe tables in PLC memory and loading the values shows the layout end to end.
Make the loaded part visible
The cheapest guard against a wrong selection is a part name people can read from where they stand. Drive it from the working registers, not from the selection: the registers hold what the machine will actually run, the selection is only a request. Put it in the header of every HMI page. Size it from the legibility planning figure of 30 ft of viewing distance per inch of capital height (FHWA), and use 20 ft per inch where a glance has to do the reading: 2 in capitals carry 40 ft at a glance and 60 ft at the planning figure. On the far side of the aisle, a posted setup sheet or a shop-floor notice screen carrying the part's setup page does the same job.
Questions
Is an HMI recipe different from a recipe held in the PLC?
No. Both store values with destinations and write them on selection, and the machine sees the same result. What differs is custody. A panel record lives in panel memory, is edited at the panel, and can be exported to a CSV file on external storage for archiving or editing away from the line. A table held in the controller changes only through a program change or through a write you programmed yourself.
One item loads wrong while the rest are correct. Where do I look?
At that item's mapping. A single wrong destination among correct ones points to that item's destination address or word count in the recipe configuration, so fix the mapping and reload. If the wrong item is the last one in the block, a transfer that stopped early looks the same, so compare the full record once after the fix. Wrong values everywhere point instead at the selection or the record content.
Should the part name on the screen come from the selection or from the loaded registers?
From the working registers. The selection is a request; the registers hold what the machine will actually run. Header text driven from the loaded value makes a failed or partial transfer visible on every page instead of hiding behind a correct-looking selection. If the header and the registers disagree, you have found the fault before anything moves.
How many recipe records can a panel or controller hold?
That is a specification of the panel or controller you use, so confirm it against the model before you size the library. Scale it from your own record: at 9 words per record, 40 parts need 360 words and 80 parts need 720 words of retentive memory. Count the spare you want for growth before you commit to a number.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.