Machine Setpoint Management: From Spreadsheets to Controlled Recipes

What is a machine setpoint?

A setpoint is a target or configured value used by equipment or a process. Examples may include a temperature target, line speed, pressure, timer, vacuum level, or selected operating mode. Some values are sent to controls. Others are entered by an operator, used during setup, or recorded as reference information.

Plants use different language. Controls engineers may say tags or setpoints. Process engineers may say parameters or process conditions. Operators may say settings. When a controlled collection of those values runs a specific product on a specific machine, this guide calls it a manufacturing Recipe.

What is the difference between a Parameter and a Recipe value?

A Parameter definition describes the meaning and rules. A Recipe Parameter stores the value for one definition in one Recipe Version. Keeping them separate prevents every spreadsheet or Recipe from redefining the same engineering term.

The definition establishes that the field accepts a Decimal between 100 and 150 °C. The Recipe Version supplies 125 as the value for Product A on Machine 4. Product B may use 132 °C while sharing the same definition.

Why separation matters

Names stay consistent

“Temp,” “Process Temp,” and “Barrel Temperature” might refer to the same point, or they might not. One controlled definition gives the organization a code, name, description, and expected use.

Units are explicit

A value without a unit invites assumptions. The definition can specify °C, bar, rpm, seconds, millimeters, or another unit from the plant's catalog. Unit conversion and equipment configuration still require appropriate engineering review.

Validation is reusable

The same data type, range, decimal-place rule, allowed choices, and required status apply wherever the definition is eligible. The plant does not need to rebuild the formula on every spreadsheet tab.

History stays meaningful

A Recipe Version points to the definition and preserves its own value and notes. A comparison can identify a change from 125 to 130 without confusing it with a change to what “Temperature Setpoint” means.

Use types that match the engineering value

Treating every parameter as free text makes data easy to enter but hard to validate. Common types include Text, Integer, Decimal, Boolean, Date, DateTime, Enum, and structured JSON. A speed of 120 rpm should not accept “fast” if the field is intended to be numeric. A mode selection may be better represented by a controlled Enum such as Standard, Rapid, or Gentle.

In Summit, Parameter definitions can include type, unit, minimum, maximum, allowed values, decimal places, validation pattern, default, and required status. Recipe values are validated against the applicable definition. Required values are checked when a Draft is submitted and again when it is approved.

Min/max validation is a data control, not a safety control

Minimum and maximum rules catch data-entry mistakes and values outside an allowed information range. For example, a definition with a minimum of 100 and maximum of 150 rejects 1,250 before the Recipe moves forward.

That validation does not replace PLC bounds, alarms, interlocks, safety functions, equipment limits, hazard analysis, or operating procedures. Summit is an information and workflow system. It does not write a setpoint to the machine or determine whether a proposed process is safe.

Limits also need context. The physically possible range, equipment protection range, validated process window, and normal target range are not always the same thing. Define the field according to the organization's actual control purpose.

Control Parameter scope

Not every Parameter belongs on every Recipe. A corporate naming field might be available across the Client. A utility condition may apply to one Plant. A model-specific zone temperature may apply only to one Machine.

Summit uses three Parameter scopes:

• Client: available for Recipes on every Plant and Machine in the Client.
• Plant: available only for Recipes using a Machine in that Plant.
• Machine: available only for Recipes on the selected Machine.

The eligible set for a Recipe is the union of its active Client, Plant, and Machine definitions. Product selection does not change eligibility in the current model. Product remains an explicit Recipe relationship and determines which product configuration the values describe.

Parameter Groups are organizational. They can arrange items into sections such as Heating, Motion, or Cooling, but they do not control eligibility or scope.

Why Machine/Product relationships matter

Nominally similar machines can require different settings due to controller scaling, tooling, capacity, geometry, sensor placement, wear, or validated process limits. Copying one generic product sheet across equipment can hide those differences.

A controlled Recipe should state the Plant, Machine, and Product. The organization can then compare Versions within the same Recipe identity instead of comparing unrelated machine configurations.

These numbers are illustrative only. They show why the value and its context belong together.

Move setpoint changes through a controlled Version

Changing a definition and changing a Recipe value are different actions. A definition change alters the rule or meaning for eligible Recipes. A Recipe value change creates a proposed new operating configuration for one Machine/Product Recipe.

Prepare value changes in a Draft Recipe Version. Validate types and limits, compare the Draft with the Current Version, record the reason, and submit it for the review your organization requires. Once approved, the new Version becomes Current and the former Current Version remains as Superseded history.

See how Recipe Version control protects approved setpoints, or use the Recipe Control Checklist to evaluate your current parameter process.