exercises · South Africa
PLC Batch Mixing Program: Recipes, Pause and Batch Counts
Build a PLC batch mixing program with level checks, retained mixing time, pause tests and a four-batch limit, plus South African PLC course questions.
This PLC batch mixing program is a disconnected sequence for two virtual fill commands, a timed mixing command and a drain command. It also counts completed software cycles and blocks a fifth start after a target of four. The key learning problem is retaining the correct mixing time through Stop and resume without letting the rest of the sequence advance while paused.
The inputs are supplied level indications. They do not measure ingredient identity, concentration or product quality. The fictional ninety-second mixing interval is a programming parameter, not a chemical recipe or a recommendation for operating a physical mixer.
For South African learners comparing industrial automation courses, this example is useful because it brings together state memory, event handling, accumulated time and a batch quota. You should be able to explain each part independently before claiming that the complete sequence behaves as intended.
Define level meanings and valid combinations
Call the three inputs LowCovered, MidCovered and HighCovered. True means the corresponding supplied level indication is covered. Avoid naming the bottom input “Empty” when true actually means covered; the name should help a learner interpret the Boolean correctly.
For this exercise, higher covered indications require all lower ones to be covered. HighCovered implies MidCovered, and MidCovered implies LowCovered. The model treats a combination that violates that ordering as a fault. It does not infer a unique physical cause from the inconsistency.
| Low | Mid | High | Interpretation under this model |
|---|---|---|---|
| 0 | 0 | 0 | No supplied probe is covered |
| 1 | 0 | 0 | Only the low indication is covered |
| 1 | 1 | 0 | Low and mid indications are covered |
| 1 | 1 | 1 | All three indications are covered |
The other four Boolean combinations are invalid under the stated ordering. Real sensing arrangements and process conditions would need their own interpretation; this is a deliberately simple model contract.
Starting a new batch requires all three inputs false. That is an observed-empty condition for the exercise, not proof that a physical vessel contains no residual material. No drainability, cleaning, contamination or chemical compatibility claim follows from these inputs.
Keep mode, process step and batch count separate
Use Ready, Running, Paused and Fault as operating modes. Use Idle, FillA, FillB, Mix and Drain as process steps. CompletedBatches is an integer from zero to four, and TargetReached means CompletedBatches is four.
Initialise Ready/Idle, count zero, MixElapsedMs zero and StartArmed false. Sample the current StartButton, RecoveryResetButton and CountResetButton values into their previous-value memories. A button already held at startup must not appear as a new request.
| Step while Running | Ordinary transition |
|---|---|
| FillA | MidCovered selects FillB, provided HighCovered is still false |
| FillB | HighCovered selects Mix |
| Mix | Accumulated mixer-command time of 90000 ms selects Drain |
| Drain | All three level indications false completes one batch |
In FillA, HighCovered true reports UnexpectedHighDuringA rather than allowing the programme to pass rapidly through two fill stages. In FillB, MidCovered must remain true; its loss reports MidLostDuringB. Mix requires all three indications true, otherwise it reports LevelChangedDuringMix.
These additional checks detect specified model inconsistencies. They cannot prove that ingredient A or B was delivered, or that a plausible-looking sequence of false inputs is truthful. Do not equate a passed Boolean test with validated dosing.
After a valid Drain completion, increment the count once, clear mixing time and return to Ready/Idle with StartArmed false. Each new batch requires another accepted fresh Start. The model does not automatically launch the next batch.
The silo pause-and-resume exercise introduces the mode/step separation. The ladder logic basics guide is a useful starting point for the conditions used here.
Accept Start only when its conditions are available
Enabled and Permission must be true, and StopRequest false. While Ready/Idle, Start can arm only with all level indications false and CompletedBatches below four. Observe StartButton false under those conditions, then accept a later raw rising edge.
If those Ready start conditions are unavailable, clear StartArmed. A held button cannot start a batch merely because the level indications later become clear or the quota is reset. The release and new edge must be observed under the defined conditions.
An accepted Ready Start selects Running/FillA, clears StartArmed and resets MixElapsedMs to zero. It does not also process FillA on the same evaluation. With the required initial level combination, the virtual A command becomes the active output.
During Running, further Start presses are ignored. During Paused, observe a release after StopRequest is false, then accept a fresh edge to resume the retained step. Apply at most one ordinary process transition on that resume evaluation after validating its current conditions.
Update all button histories every evaluation, including during Stop and Fault. Gating a button edge detector with a mode or permission can make an old held value appear newly pressed when that condition changes.
Make ninety seconds mean accumulated command time
Use a supplied nondecreasing millisecond timestamp. At the beginning of each evaluation, calculate the difference from the previous timestamp. If the previous evaluation’s MixerCommand was true, add that interval to MixElapsedMs, capped at 90000. Otherwise retain the accumulator.
This is an explicit sample-and-hold convention: the previous virtual command is assumed to remain in effect until the new observation. Therefore the interval ending at a Stop evaluation is counted when the previous mixer command was true. Time after that Stop is not counted because the resulting command is false.
On entry to Mix, initialise its accumulator to zero. At the end of each evaluation, store the resulting MixerCommand and the current timestamp for the next calculation. A resumed Mix retains its previous accumulated value, while a new batch or recovery reset clears it.
The CODESYS TON documentation describes a falling input edge resetting the delay counter. Schneider Electric’s TON documentation describes on-delay input, elapsed time and output conditions. Neither source justifies treating an ordinary TON as this retained-time accumulator merely by putting Running in its input condition.
A native retentive timer may implement an appropriate policy, but its exact reset, enable and timebase behaviour must be checked. The supplied-timestamp model here defines its own semantics and is not executable vendor-specific timer code.
Trace a pause after thirty-seven seconds
Begin this timing fixture in Running/Mix at time zero, with all three level indications true and MixerCommand true. MixElapsedMs starts at zero. The table isolates mixing time; earlier fill steps are not included.
| Time ms | Event | Mode / Step | MixElapsedMs | MixerCommand |
|---|---|---|---|---|
| 0 | Enter Mix | Running / Mix | 0 | True |
| 37000 | StopRequest true | Paused / Mix | 37000 | False |
| 57000 | Stop released, Start released | Paused / Mix | 37000 | False |
| 57010 | Fresh Start edge | Running / Mix | 37000 | True |
| 110009 | Ordinary observation | Running / Mix | 89999 | True |
| 110010 | Threshold reached | Running / Drain | 90000 | False |
The command was requested for 37000 ms before the pause and 53000 ms after resume. Total requested mixing time is 90000 ms. Wall-clock time from Mix entry to Drain entry is 110010 ms, including the pause and the ten milliseconds before the new Start edge.
If a reset-on-pause implementation starts again from zero, it requests ninety more seconds after resume. If a wall-clock deadline ignores the pause, it can end mixing with less requested-on time. Those alternatives produce different traces; neither should be described as equivalent.
The accumulated value measures the model’s requested command interval. It does not establish shaft rotation, agitation effectiveness or adequate mixing of a particular material.
Pause the process as well as the outputs
StopRequest during Running selects Paused, clears StartArmed and captures the current three level inputs as a snapshot. Keep the process step and accumulated mix time. Do not run an ordinary FillA, FillB, Mix or Drain transition after the Stop decision.
While Paused, compare subsequent level observations with the saved snapshot. Any change reports PausedLevelsChanged and selects Fault, even if StopRequest remains true. Repeated Stop evaluations must not overwrite the snapshot with newer values.
The snapshot is a limited consistency check. Unchanged Boolean inputs do not prove that the same material remains in the vessel or that nothing changed between observations. Resuming this exercise assumes process continuity beyond what those three bits can demonstrate.
On a fresh resume, process the retained step with the current levels. If HighCovered became true on the initial Stop evaluation during FillA, that value can be part of the snapshot, but the resumed FillA still reports UnexpectedHighDuringA. Pause is not a way to bypass the step’s validity rules.
If the mixer accumulator reaches 90000 exactly on the Stop evaluation, keep Paused/Mix with that accumulated value. A later valid resume can transition to Drain without issuing another mixer command. Stop priority controls the transition, while the time update still accounts for the preceding requested interval.
Separate recovery reset from count reset
Loss of Enabled or Permission, invalid level ordering, invalid mode/step values and the defined process faults select Fault. Preserve the first FaultReason until recovery reset. Commands are false in Fault, and restoration of permission alone does not resume work.
A fresh RecoveryReset edge is accepted only when Enabled and Permission are true, StopRequest false and the level combination valid. It returns to Ready/Idle, clears elapsed mixing time, the pause snapshot and the fault reason, and leaves StartArmed false. It preserves CompletedBatches.
Recovery reset does not assert that a partially filled vessel is empty. Ready still blocks a new start until all level indications are false. In the disconnected exercise, establish the next fixture deliberately; no physical recovery or disposal procedure is supplied.
CountReset is a separate request. Accept its fresh edge only in Ready/Idle, with all three levels false, global permission available and StopRequest false. It sets CompletedBatches to zero and clears StartArmed. An accepted count reset consumes that evaluation, so it cannot also start a batch.
A count-reset edge in another condition is rejected; it does not erase a partial or completed count. Use a CountResetRejected observation flag if helpful. If recovery reset and count reset arrive together, recovery reset has priority and preserves the count; another fresh count-reset request is needed afterwards.
Enforce the quota in the start condition
TargetReached is a displayed result of the count. The actual start condition must also require CompletedBatches below four. Merely lighting a lamp at four does not block another batch.
Count only the accepted Running/Drain-to-Ready/Idle transition. Several evaluations with the vessel already observed empty while Ready must not add further batches. Keep the value saturated at four, even when exercising boundary fixtures.
Run four complete software sequences from count zero. The completed counts should be one, two, three and four. Release and press Start again with clear level inputs: the fifth attempt must remain Ready/Idle with no activity command. Then perform a valid CountReset, release Start and press again to begin a new sequence.
Recovery reset during a fault after three completed batches must leave the count at three. A count reset while paused must be rejected. These cases distinguish process recovery from deliberate counter administration.
The bottle-counting exercise provides related practice with events and bounded counts. Avoid counting the Drain state level, which can remain true for many evaluations before completion.
Decode outputs after committing the decision
Use one priority path: update requested mixing time; handle unavailable permission and invalid input ordering; accept eligible recovery reset; accept or reject count reset; handle latched faults and invalid state; check paused-snapshot changes; handle Stop; accept Start or resume; process at most one ordinary transition.
The accepted recovery-reset and count-reset branches end further decisions for that evaluation. A rejected count reset may report its flag while ordinary processing continues. Existing faults remain latched unless an eligible recovery reset was accepted.
After committing Mode and Step, define Operate as global permission available, StopRequest false and Mode Running. ValveACommand is Operate and FillA; ValveBCommand is Operate and FillB; MixerCommand is Operate and Mix; DrainCommand is Operate and Drain.
The process checks run before these outputs are decoded. Their purpose is to prevent known inconsistent step/input combinations from issuing commands. Each output has one writer in the model, and only one activity step is selected at a time.
The scan-cycle lesson helps explain why old and newly assigned values matter. An output comparison alone cannot prove that other parts of a native project do not write the same tag or that physical actuators follow the requested state.
Test a complete level and state sequence
Start from Ready/Idle, count zero and level inputs 000 in low-mid-high order. After release and fresh Start, expect FillA. Supply 100, then 110: the latter transitions to FillB. Supply 111 to enter Mix with elapsed time zero.
Keep 111 through the required accumulated mixing interval. After Mix reaches its threshold while Running, expect Drain. Supply decreasing valid combinations 110, 100 and 000. The final observation completes the batch once and returns to Ready/Idle.
Now repeat with HighCovered true during FillA. A combination 101 is invalid by level ordering; 111 is ordered but still unexpected during that step. Both must fault for their respective reasons. A valid ordering does not make every input appropriate in every process phase.
Test lost MidCovered in FillB and lost HighCovered in Mix. Test Stop at Mix completion and Stop when Drain first observes 000. The first retains the completed accumulator while paused; the second must not increment the batch count until an accepted resume processes Drain.
Keep the normal trace, the pause-time trace and quota tests separate in your portfolio. Each demonstrates a different requirement, and one uninterrupted successful batch does not establish all three.
Explain what level-based quantities would require
This programme treats the probes as sequence conditions. To infer volumes from levels, a separate model would need vessel geometry, starting contents and the relationship between each observation and volume. Boolean probes do not directly identify delivered ingredient quantities.
For a purely fictional arithmetic example, suppose an ideal vessel starts at zero volume, the mid threshold corresponds to 400 litres and the high threshold to 700 litres. Ignoring all losses and overshoot, the first addition would be 400 litres and the second 300 litres. The second addition is the difference between the two thresholds, not another 700 litres.
If the mid threshold instead represents 450 litres while the high remains 700, those ideal additions become 450 and 250 litres. The total remains 700, while their proportions change. That calculation illustrates an assumption; it is not a validated recipe or a calibration result.
Real measurement uncertainty, residual volume, flow after command removal and material behaviour are outside this example. Do not claim that the state sequence guarantees a dose ratio simply because the level transitions occurred in order.
South African training questions and next extensions
When comparing PLC courses in Durban, Pinetown, Gauteng, Cape Town or online, ask the provider to demonstrate the retained-time trace and the blocked fifth start. A mixer animation can look correct while resetting its timer on every pause or allowing unlimited batches.
Ask whether “recipe” means a fixed teaching sequence, editable setpoints, versioned production instructions or measured dosing. Those are different scopes. The online PLC training guide and instrumentation-technician guide can help frame software and measurement questions separately.
An editable mix target should be validated and copied into the active batch record at Start. Specify whether edits during a running batch affect the current batch or the next one. Likewise, adding fill or drain timeouts requires a declared timebase and a reason tied to the observation, not a promise to detect every possible physical failure.
Describe the current result as a virtual batch-sequencing model. A portfolio can include expected and observed values, the exact environment used and a corrected defect. It should not claim a commissioned chemical process, measured production quality or a registered qualification.
Questions learners ask about PLC batch mixing
Does an ordinary TON preserve mixing time when stopped?
The cited CODESYS TON resets its delay counter on a falling input. This exercise uses a separately defined accumulator. Check the exact native instruction and reset policy rather than assuming that putting Running in a TON input creates retention.
Why are four valid level states not enough to verify a recipe?
The four valid level combinations describe ordered Boolean observations. They do not identify ingredients or measure concentrations. The sequence and any quantitative recipe evidence must be assessed separately.
Why does recovery reset preserve the count?
It releases a process fault and discards the interrupted batch state. CompletedBatches records earlier completed software cycles. Clearing that record is a separate eligible count-reset action, so routine recovery does not silently erase it.
Does ninety seconds of MixerCommand prove adequate mixing?
No. It proves the requested-on interval under this supplied-time model. Actual movement, process conditions and the meaning of adequate mixing require independent evidence.
Continue with timer and execution-order practice
Inspect the PLC timer learning page in PLC Simulation Software and its scan-cycle highlighting feature for related learning entry points. These links do not claim that this exact batch model is supplied or graded on a particular plan.
Return to the PLC programming examples collection when you can explain the retained mixing interval, the event that counts a batch and the condition that blocks the fifth start. Those are distinct requirements, and your test evidence should make each one visible.