When an E300 recipe omits fields shown on another screen, adding edit screens alone will not expand the recipe: the recipe function must include the devices associated with those fields. Define that complete device set with the append-recipe method, a text block, or a PLC-controlled recipe design.
Screen changes that leave recipe membership unchanged
Putting some recipe fields on a second operator screen solves a display-space problem, but it does not by itself establish that those fields belong to a recipe. A save control on one screen may capture only the recipe items associated with that screen or block. If the required devices are not included in the recipe definition, saving and restoring can appear to work while leaving part of the data unchanged.
Several layout workarounds can help, but each has a boundary:
- Adding more edit screens: This provides room for operators to enter values. Use the append-recipe function or a consolidated recipe block to make sure the additional devices join the recipe.
- Hiding overlapping objects: A reported layout uses overlapping objects and a toggle to control visibility; the objects were still stored in the recipe. Treat this as a layout technique to test on the configured E300 project, not as a replacement for checking recipe membership.
- Using a multi-page text screen: Scrolling can expose more fields, but confirm that the devices in the unseen portion are included when saving and restoring. Visibility or page position is not a reliable substitute for a device-list check.
- Using a report-type text block: This has been used to place recipe devices together, but availability may differ across HMI ranges. Confirm that the required block type exists in the target project before designing around it.
Recipe membership as the deciding quantity
For this problem, the deciding quantity is the set of device registers included in the recipe operation—not the number of operator screens. E300 is identified as Cimrex 30 in the supplied material. The described approaches all solve the same underlying issue: make every required device part of the recipe save/restore set.
A text block containing all devices required for save and load is described as the easiest and best approach. An alternative is to save a recipe on one block and append the devices from another screen. A third approach puts recipe management in PLC logic and uses HMI screens as the operator interface.
| Approach | Recipe device set | Best fit | Check before commissioning |
|---|---|---|---|
| Append recipe | Devices from another screen are added to the existing recipe through the append function. | Existing recipes that need fields from additional screens. | Confirm each intended device is included after appending. |
| Consolidated text block | All devices to save/load are placed in one text block. | A compact recipe definition while keeping operator edit screens separate. | Check the block type and device list in the project. |
| PLC-controlled recipes | PLC logic manages recipe data; HMI buttons and screens support selection, reading, and writing. | Projects where recipe behavior is easier to control in PLC logic. | Test the PLC recipe transfer and HMI commands as a complete path. |
Append-recipe sequence for multiple E300 screens
The append method connects the recipe definition across screens. The described sequence begins with a recipe saved in one block, then adds devices from the second screen through the append recipe function.
- Identify all device registers required in the recipe, including those displayed on each operator screen.
- Save the initial recipe from the first block using the standard recipe function.
- Navigate to the additional screen and use the append recipe function for its recipe devices.
- Repeat the process for other screens that contribute devices, following the project’s recipe-function arrangement.
- Inspect the resulting device set and verify that every required field is included before operators use the recipe.
The essential distinction is between moving to another display screen and appending its devices to the recipe. Only the latter addresses missing recipe membership. Do not infer a particular menu path, button label, or append order beyond what the configured project and E300 software show.
Consolidated text-block recipe layout
A single text block with all devices needed for recipe save and restore provides a second way to avoid a recipe definition spread across operator pages. Keep the operator editing screens arranged for usability, then maintain the required recipe devices together in the block used by the recipe functions.
One described variation creates a separate recipe-function screen containing all required registers. The recipe devices can be positioned over one another and hidden with a dummy visibility bit, while the operator-facing edit screens present the values in a usable layout. The example uses device ranges D50 through D99 on one page and D100 through D150 on another, then includes D50 through D150 on the recipe-function screen. These are illustrative addresses from a particular project, not E300 defaults; substitute the device addresses used in the application.
Where the text block overflows its visible area, enable More Indication in the block settings so the operator can see that additional data is off-screen. This indicator addresses visibility of content, not whether the recipe includes every device. Confirm those as separate checks.
PLC storage and HMI recipe responsibilities
PLC-controlled recipes are a valid alternative when the project is easier to manage with recipe data in PLC logic. The HMI can provide the recipe screens and buttons used to move, read, and write recipe data. This shifts responsibility for the recipe transfer and storage behavior into the PLC program, so validate both sides of that interface rather than assuming a screen control alone completes the operation.
HMI recipe storage can also provide a second copy of data held in the PLC. In the described application, calibration data was stored in both places, allowing the HMI copy to restore data after PLC replacement and the PLC copy to remain available if the HMI failed. This is a specific redundancy strategy, not a substitute for confirming that both copies contain the intended current values. Define which copy operators may edit, how changes are saved, and how a restored copy is checked before production use.
Access levels and legacy recipe settings
Recipe restoration can fail when included values are not available for operator input at the active login level. One reported case had data intended for display only included in the recipe; restoring the recipe produced error messages. Separate read-only display values from recipe-editable values, or assign access so the active operator level can write every value included in the restore operation.
For older E300 versions, a Current Recipe Reg register in Recipe settings was identified as a possible requirement. The same account noted that it might not apply to newer versions, so check the target software version’s recipe settings and project behavior rather than carrying that legacy requirement forward uncritically.
Record the operator login level used during testing and verify each recipe value at that level. A successful save under an engineering login does not establish that production operators have the write access needed for restore.
Save, restore, and field verification
Commission the recipe with a controlled test using known values. Verify the saved device set and the restored values separately: a recipe operation can complete without proving that every intended field was included.
- List each required recipe device and the screen or block where it is presented. Mark which values are editable and which are display-only.
- Enter a distinct test value for each recipe field and save the recipe using the intended operator workflow.
- Change the values in the HMI or PLC, then restore the saved recipe at the intended operator access level.
- Read back every device in the list, including fields on other screens and any fields below a text block’s visible area.
- Confirm that restored values match the saved test values, that excluded read-only data does not trigger access errors, and that any PLC/HMI copy strategy behaves as designed.
If fields fail selectively, compare the missing devices against the recipe block or appended device set first. If recipe membership is correct but restore errors occur only for certain users, inspect operator input permissions and the active password level. For an older project, check whether its recipe settings require a current-recipe register.
FAQ
Can I use multiple screens for an E300 recipe?
Yes. Use the append recipe function to add devices from another screen, or put all required devices in one text block or recipe-function screen. Verify the complete device set by saving and restoring test values.
Does an invisible E300 object get stored in a recipe?
A reported E300 layout stored overlapping objects even when a toggle hid them. Test the configured project by changing, saving, and restoring the hidden device values; do not use visibility alone to judge recipe membership.
Can read-only values cause E300 recipe restore errors?
They can if a recipe restore attempts to write values unavailable at the active operator password level. Give recipe values the required operator-input access or keep display-only values outside the restore set, then test with the production login level.
Does an older E300 need a Current Recipe Reg?
Older E300 versions may require a Current Recipe Reg in Recipe settings; the requirement may differ in newer versions. Check the target project’s settings and verify its save/restore behavior. Stop deployment if the device list or restore behavior remains unclear, and escalate with the project version and a reproducible test case to official Beijer Electronics support.