Recipe entry value limits in the PLC when the keypad allows 9999

Why the keypad stops at 9999

The keypad behind a recipe edit is a generic numeric entry surface, and in the editor it exposes no minimum or maximum property for the recipe field. There is no limit to set at the keypad. What the field accepts follows its width: a 4-digit field holds 0 to 9999, while the 16-bit unsigned tag behind the recipe usually spans 0 to 65535. Neither width describes the process range.

Two platform behaviors are worth a look in your software's help before you build anything. Some HMI software keeps the minimum and maximum on the HMI tag behind the recipe, and you set them there. Some recipe-transfer setups expose a per-value Max Input property; one HMI maker's manual documents a recipe value with Max Input set to 100 and an ingredient value set to 200. If your editor has either, set it to the approved bounds. It shapes what the keypad accepts. The PLC compare still gates what the machine accepts, because recipe load and any other write path bypass the keypad.

The numeric-entry keypad on a dedicated input object is a separate path with its own handling; Clamp HMI numeric entry limits in PLC ladder logic covers that case. A recipe field whose editor offers no limit property gets its range from PLC logic.

Symptoms and what each points to

• The keypad takes 0 to 9999 and the editor shows no limit property on the recipe input. The entry object has no range control in this software, so the range has to be enforced in the PLC.
• The machine reacts to a bad value the moment the entry is made. The field writes the active tag directly. Insert a staged buffer and validate before the commit.
• After a rejected or corrected entry, part of the new recipe is already applied. Fields are being committed one at a time. Validate the whole set first, then commit it in one operation.
• A value keypad entry would have rejected reaches the machine after a recipe load. The load path writes the tags without passing through the entry object. Run the load through the same compare.
• The number on the screen and the number the logic uses differ. Scaling or decimal places disagree between the HMI and the tag; Move an HMI numeric entry decimal point from a PLC tag covers the decimal-place case.

Checks before you write the logic

• Trace the tag the recipe field writes, from the entry object to the logic that consumes the value, and note whether it is a staged buffer or the active control tag.
• Read the tag's data type, signedness and decimal places, and convert the approved bounds into tag units before the compare is written.
• Fix the approved minimum and maximum with their units, from the process specification and the ratings of the equipment downstream. Record whether the endpoints are inclusive. If no approved range exists, stop before the value is enabled in production and get the specification first.
• List every write route to the same tag: keypad entry, recipe load, and any program or client move. Each route goes through the staged compare or gets its own equivalent check.

The fix: compare the staged value and commit only what passes

1. Point the recipe field at a staged tag instead of the active tag, with the same data type, signedness and scaling as the active tag.
2. Compare the staged value against the bounds each time it changes:

// Illustrative names; use your project's tags and language.
MIN_SETPOINT    : UINT  := 150;   // approved minimum, inclusive
MAX_SETPOINT    : UINT  := 320;   // approved maximum, inclusive
STAGE_SETPOINT  : UINT  := 0;     // the recipe field writes this tag
ACTIVE_SETPOINT : UINT  := 0;     // used by the control logic
RANGE_ERROR     : BOOL  := FALSE;

IF STAGE_SETPOINT < MIN_SETPOINT OR STAGE_SETPOINT > MAX_SETPOINT THEN
    RANGE_ERROR := TRUE;          // ACTIVE_SETPOINT stays unchanged
ELSE
    RANGE_ERROR := FALSE;         // ready to commit on confirm or load
END_IF;

3. Commit on a pass: an operator confirm for keypad entry, the load command for a recipe load. Copy the whole staged set to the active tags in one operation, every field together, so a set with one bad field never lands half-applied.
4. On a fail, keep the active tags unchanged and set the range-error bit the screen displays.
5. Clear the error bit only on a defined action: a corrected entry that passes the compare, or an operator acknowledge. Closing the screen clears nothing.
6. If the editor turns out to offer a tag-level range or a per-value Max Input property, set it to the same bounds once the PLC check is in place. It is the second line of defense for the keypad.

Recipe sheets can be large. One common recipe database holds up to 1000 recipes per sheet and 99 sheets, so nobody reviews a load by eye. If you store HMI recipe tables in PLC memory and load the values, the load copy runs through this same compare before anything moves to the active tags. When the approved range itself changes with the selected recipe, carry the bounds in the recipe row and compare against those, as in Recipe dependent HMI entry limits enforced in PLC logic.

Recommendation: Put the range compare on the staged tag in the PLC for every recipe field with a defined range. Commit all fields together on a pass, keep the last accepted values active on a fail, and clear the error only on a defined retry. Set any editor-level limit property to the same bounds as a keypad aid once the PLC check is in place and tested. Clamp a bad value to the nearest bound only where the process owner has approved that in writing for that specific field; everywhere else, reject and retain.

Example: an oven zone setpoint

A rework oven has one heated zone, and the operator edits its setpoint from a recipe sheet. The approved range is 150 to 320 °C, endpoints inclusive. The tag is a 16-bit unsigned integer spanning 0 to 65535. The field is 4 digits, so the keypad accepts 0 to 9999, and 9999 is greater than 320, so the field accepts every value the process forbids. The compare makes the decision.

The operator means to type 250 and types 850. The field takes it, because 850 sits under 9999. The staged compare runs: 850 is above 320, so the upper bound fails, RANGE_ERROR goes true, the commit is blocked, and the zone keeps running at its last accepted 240 °C with the range message on screen. The operator retypes 250. The compare passes, the confirm commits, and the active setpoint becomes 250 °C.

A saved sheet holding a row with 850 from before the check existed runs the same compare before the commit copy: 850 fails the upper bound, the row is rejected, the zone stays at 250 °C, and the load report flags the row. The boundary values behave by the same arithmetic: 150 and 320 pass, 149 and 321 fail.

Test the rejection path

Run the first pass with the machine in a safe commissioning state, outputs off or drives disabled, so a deliberately bad value cannot move anything. Then work through the boundaries:

1. Enter 149 and then 321. Both must be rejected, the active value must hold, and the range message must show.
2. Enter 150 and then 320. Both must be accepted and committed; this verifies the endpoints are inclusive as recorded.
3. Enter a mid-range value such as 250 and verify the commit.
4. Load a saved sheet holding an out-of-range row and verify the load rejects it before any commit copy.
5. Correct the field to an in-range value, commit, and check the error bit clears. Close and reopen the recipe screen afterward and check the invalid value does not reappear as active.

Record the approved bounds, the units, the endpoint behavior and the test results in the maintenance file.

Where a PLC range check goes wrong

• The compare watches the staged tag while a second write path updates the active tag directly. Route every write through the stage, or add the compare to that path as well.
• The compare runs after the commit copy instead of gating it. A value that fails must never reach the active tags, so place the check between the stage and the copy.
• The HMI and the compare disagree on units or decimal places. If the tag carries one decimal place, an entered 150.0 becomes 1500 counts, and a compare written against 150 blocks valid entries or passes bad ones. Write the compare in tag units.

Questions