How do you structure C-more recipes for oven ramp/soak?

Brian Holt7 min read
AutomationDirectProcess ControlTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

The C-more/Do-more oven project needs editable, transferable ramp/soak recipes without a separate HMI field and PLC memory location for every step. Replace the hand-built screen and fixed-address plan with one indexed recipe data model, then validate and copy a selected recipe into the values used by the running control sequence.

Check what each recipe step must store

Before building screens or PLC logic, write down the meaning and units of each step. The proposed profile has as many as 20 alternating ramp and soak segments. The description calls out a ramp value, a ramp rate in degrees per minute, and a soak value; it does not state whether the soak value is a duration, a temperature, or another command value. Decide that from the process design and the Do-more ramp/soak instruction configuration before assigning tags.

Field Define before implementation Why it matters
Ramp target Temperature value and engineering units The controller needs a meaningful destination for each ramp.
Ramp rate Degrees per minute or the rate units expected by the control logic A numeric value has no safe meaning without units and bounds.
Soak value Specify whether this represents hold time, target, or another process quantity Do not map an ambiguous value into control logic.
Step enabled/termination Define how the profile ends and how unused steps are marked Prevents blank recipe entries from being interpreted as real commands.

Use one consistent record layout for every step. A fixed set of fields indexed by recipe number and step number lets the HMI edit one step template repeatedly instead of maintaining a separate group of objects and tag names for each segment.

Check whether the 20-step layout fits the PLC data model

The proposed “80 locations” count needs reconciliation before programming. The description also enumerates 20 ramp values, 20 ramp-rate/time values, and 20 soak values, which is 60 values if each category has one value per step. If “ramp over time” means two separate values, count the ramp target, ramp rate, and soak field explicitly; do not allocate addresses from the inconsistent total.

On the PLC side, organize recipe records as a repeatable indexed structure if the Do-more programming environment and chosen instruction support it. Otherwise, use a documented contiguous block with a fixed stride per step and calculate each field location from recipe and step indices. Either approach is better than scattered individual memory locations, because a single edit routine can address the selected recipe/step and the PLC can loop through steps.

Keep recipe storage separate from the active control values. On selection, validate the stored recipe and copy it into an active buffer; the ramp/soak sequence should use that buffer rather than data the operator may still be editing. This prevents a mid-cycle HMI edit from unexpectedly changing the running profile. Define whether edits take effect only on the next start or require an explicit reload.

Check how the C-more edits one selected step

Replace 20 sets of numeric entry objects with a recipe editor that selects a recipe and one step at a time. Show the step index and field labels with engineering units. Provide separate actions for selecting, editing, saving, and starting a recipe so an operator cannot confuse a temporary entry with a committed profile.

  1. Display the selected recipe and step number, then read the corresponding fields from the PLC recipe data.
  2. Allow edits only to the displayed step fields; enforce numeric limits and reject invalid combinations before saving.
  3. Save the edited step to recipe storage, then read it back and show the stored values.
  4. Provide explicit controls to create a recipe, copy an existing recipe if desired, and mark unused steps as inactive according to the agreed data model.
  5. Require a deliberate selection and start command before loading a profile into active control values.

Use a small number of reusable HMI screens or repeated display elements where supported by the configuration software, rather than assigning a unique screen object to every recipe/step combination. Confirm the HMI can address the selected record and that its data types and PLC addresses match the controller project; the exact object setup depends on the installed C-more and Do-more software versions.

Check zero and unused-step behavior before enabling a recipe

The proposed zero-value shortcut is a specific risk: the plan says a zero value activates the “jog” portion of the ramp/soak box so the instruction will not ramp to zero. Do not use zero as both a valid process value and an implicit “step absent” marker. A blank or partially entered recipe could then invoke behavior different from the operator’s intent.

Test the exact instruction behavior in the Do-more program and document the result. Use an explicit step-active flag or a clearly defined end-of-profile marker if the data model allows it; keep the ramp target, rate, and soak fields independent. Reject a recipe if an active step lacks required fields, has a rate outside the process limits, or contains an invalid sequence. Test all-zero, partially populated, maximum-step, and end-of-profile cases before allowing the recipe to command the oven.

Check the CompactFlash transfer path on a second oven

The intended workflow uses a memory card to move updated recipe parameters to other ovens. Treat this as a data-transfer and compatibility check, not just a file copy. The source does not specify which component writes or reads the card, the file format, or whether the card contains recipe data or a project image; establish that path for the actual hardware and software.

  1. On the source oven, save a known recipe change and identify exactly which files or data are written to the card.
  2. On a test destination oven, confirm the controller and HMI project use the same recipe layout, units, and field meanings.
  3. Load the card data using the intended transfer procedure, then read back the recipe on the destination and compare every field with the source.
  4. Confirm the destination does not start heating merely because data was loaded; require the normal operator start action after validation.
  5. Repeat with an invalid or incomplete recipe to confirm the destination rejects it rather than silently using partial values.

Keep a known-good recipe backup and a clear version or revision field in the recipe data if the project needs to distinguish revisions. If the card transfer changes the PLC or HMI project rather than only recipe data, handle that as a controlled project update and verify compatibility before deploying it to another oven.

Check PID monitoring and prove the control path

The C-more display can only present values that the PLC exposes through the configured communications path and that the selected HMI object can read. Do-more PID control remains in the PLC; an HMI monitor is an operator display, not a replacement for the control loop. Map the process value, setpoint, controller output, and relevant status values that the PLC actually makes available, and verify the units and scaling shown on the screen.

Commission the display against live PLC values: change a test setpoint under controlled conditions, confirm the displayed setpoint follows, and compare the process value and output indication with the PLC monitor and available PID data logging. Confirm that the C-more trend and Do-more logging represent the same variables and time basis before using them to diagnose performance. If the chosen PID monitor object expects a particular data structure, check the C-more and Do-more documentation and configure the PLC data to match; do not assume that a PID object binds automatically to the controller instruction.

Before production, test each branch: a valid profile loads and runs the intended sequence; an invalid profile is blocked; editing during a run does not alter the active buffer; and card transfer reproduces the recipe. Also verify oven limits and independent protective interlocks outside the recipe editor, since recipe validation does not replace process safety functions.

FAQ

Why does a recipe editor need a separate active buffer?

It separates operator edits and saved recipe data from the values currently driving the sequence. Load a validated profile into the active buffer at start, and define when later edits can take effect.

Why should zero not mean both a blank step and a ramp command?

The proposed configuration associates zero with jog behavior, so a partially filled recipe could trigger unintended instruction behavior. Define an explicit inactive-step or end marker and test zero-valued fields against the configured instruction.

Why does the C-more PID monitor not automatically prove the loop is configured correctly?

The HMI displays PLC data through its communications and object configuration; it does not establish that the displayed tags, units, or scaling match the controller loop. Compare displayed values with the Do-more PID data and logs during a controlled test.

Stop before enabling heat if the soak field meaning, zero behavior, recipe mapping, or card-transfer path remains unclear. Contact official AutomationDirect support with the exact C-more and Do-more models, software versions, instruction configuration, and a reproducible test case.

Back to blog