Call an HMI recipe from a tag with a recipe object

What you need

• The recipe records. They must already exist in the panel project with their record numbers, because the call addresses a record by number.
• A trigger tag. An internal or external tag that the line logic writes when the call should fire. If the write should be driven from the PLC's own logic, the PLC-bit route to the same recipe write covers that starting point.
• A record number source. Either a static number typed into the object, or an internal or external tag of type unsigned int 16 that the PLC writes with the number of the record to call.
• A placement. An operator screen, a background screen shared by the whole project, or a spot off the viewable area.

One boundary to keep straight: this object belongs to the machine's HMI panel and is configured in that panel's own software. A wall screen showing andon status or shift information is a different screen with a different job; the shop-floor screens category covers that case.

Configure the recipe object

1. Place a recipe object on the screen the panel will be showing while the call and its download run.
2. Tick the Use Write Event option, then select the tag, internal or external, that will start the recipe call.
3. On the Recipe tab, choose Single Source Recipe or Multiple Source Recipe. A Multiple Source Recipe also needs its recipe sheet picked from the drop-down selection box.
4. Choose a Static Recipe Record Number, or choose Tag Name and enter an internal or external tag of type unsigned int 16 to carry the number of the record being called.
5. Set the object's runtime placement now: operator screen, background screen, or off the viewable area.
6. Aim the first test at a non-production record, so a misfire cannot touch running settings.

Those option names come from one panel software family. Other packages use different labels for the same three roles: the event tag that starts the call, the recipe source and sheet the call addresses, and the record number it selects. Match the roles in your own panel's manual and the configuration transfers unchanged.

Keep the object displayed at runtime

The recipe object, also called a Recipe Button in that software family, must be displayed when the call fires. A correctly configured object sitting on a screen the runtime never shows simply never fires, which is why placement matters as much as the tag.

Three placements satisfy the rule. An operator screen works when that screen is up during the call. A background screen works better across a whole project: build a screen that carries the recipe object and use it as the background for the other screens, so the object is always displayed and the call works from any screen. Off the viewable area also counts as displayed; fully hiding the object is a dead end, but a spot 100 px past the edge of the screen keeps it live and out of the operator's way.

There is also a hidden variant. Set the object's visibility address to the internal SYS BIT ON tag and select 'Object is visible when address value is off', so the object draws only when the bit is off. This route serves the write-event call only, because an object an operator presses has to be visible, and a hidden object offers nothing to press. Test it with a non-production record and the exact visibility condition in place before the first real changeover.

Worked example: one tag write calls record 4

A filling line runs 6 products, and all six sets of machine settings live in one recipe, records 1 through 6. The changeover runs on two tags, named here Record_Select and Load_Recipe. Record_Select is an internal tag of type unsigned int 16 and carries the product number. Load_Recipe is the tag selected under Use Write Event.

A 16-bit unsigned tag holds 2^16 = 65,536 values, numbered 0 to 65,535, so records 1 to 6 sit far inside the range. The PLC program writes only 1 to 6 into Record_Select, and record 0 stays unused, so a zero in the tag can never select a real product.

The object sits on the project's background screen at x = 900 on an 800 x 480 pixel panel, 100 pixels past the right edge of the viewable area: displayed for the runtime, invisible to the operator.

The operator picks product 4 and confirms the changeover. The PLC writes 4 into Record_Select, then writes 1 into Load_Recipe. The object's write event fires, reads 4 as the record number, and downloads record 4's values into the machine tags. One operator action, one record, no screen navigation.

How to check it worked

1. Trigger the call once with the object's screen displayed and a non-production record selected, then watch the record's values arrive in the PLC addresses the recipe writes to.
2. Put the operator on another screen, leave the object on the background screen, and trigger again. The call must still fire; that is the display dependency, and it separates a working tag call from a dead one.
3. Run the hidden variant with SYS BIT ON and 'Object is visible when address value is off' exactly as configured, and check that the download still lands.
4. Exercise every record number operators will use, first and last included. Some panel software lets you cap the recipe's record range; if yours does, set the cap at the real record count so an out-of-range write is caught at the panel. One walkthrough of limiting the recipe data record number range shows a cap in action.
5. Give the PLC the final say: a handshake tag lets the PLC catch the recipe load and hold the line until the values are in. The PLC handshake tag for an HMI recipe load shows the tag arrangement.
6. If each call should leave a timestamp, an alarm history entry can record the job completion time of every load.

Recommendation: Drive the call from the write-event tag and keep the record number in its own unsigned int 16 tag whenever the PLC picks the product; reserve a static record number for objects whose record never changes. Put the object on a background screen so the call works from every screen in the project, and test the display dependency with a non-production record before the first real changeover.

Questions