exercises · South Africa
PLC Float Switch Pump Control: Trip and Reset Exercise
Study PLC float switch pump control with fill-band logic, active-trip priority, held-reset tests and clear recovery rules for South African PLC learners.

This PLC float switch pump control exercise uses two virtual tank-level inputs, a source-availability input and a latched trip to teach filling hysteresis and reset priority. You will calculate when a fill request starts and stops, investigate a reset held during an active blocking condition, and separate a software readiness delay from claims about power restoration.
The model is disconnected from equipment. PumpCommand is a Boolean learning result, not proof of flow or a motor's state. SourceAvailable is a supplied permission value, not independent evidence of borehole level, cable integrity or protection performance. No tank volume, pump rating, wiring diagram or physical dry-running protection design is supplied.
Start with ladder logic basics if contacts and holding conditions are unfamiliar. The start-stop exercise explains why a current input level, a new edge and remembered state are different. All three appear in this lesson, so keep their meanings visible before drawing rungs.
Define the two float meanings
Use AboveLow true when the fictional tank level is above the lower start boundary. Use AtHigh true when it has reached the upper stop boundary. For filling, a low tank requests a start and a high tank clears that request. Between the boundaries, the previous request determines whether filling continues.
| AboveLow | AtHigh | Interpretation in this model |
|---|---|---|
| False | False | At or below the lower boundary; a fill can begin |
| True | False | Between boundaries; preserve an eligible previous request |
| True | True | Upper boundary reached; clear the fill request |
| False | True | Inconsistent with the declared ordering |
The last combination is invalid in this simplified model. Report InvalidLevels and clear FillDemand and PumpCommand on that evaluation. It is a logical consistency check, not a diagnosis of a specific failed float. Real devices and installations may have different signal meanings, so this table must not be substituted for their documentation.
Do not infer “true when wet” or “true when healthy” merely from a variable name. The application needs an explicit relationship between the observed signal and its intended meaning. A contact selected in ladder examines a Boolean value; it does not establish how a field device is wired or whether a broken conductor is detected.
The space between thresholds is a logical demand band here. The example provides no physical distance, liquid-volume change or consumption rate, so it cannot calculate starts per hour. Two threshold values alone do not justify a claim that a pump will cycle a particular number of times or that all chatter is eliminated.
Keep fill demand, source trip and readiness separate
The model uses these additional values:
| Variable | Meaning | Role |
|---|---|---|
SourceAvailable | The exercise currently permits drawing from the source | Boolean input |
ResetRequest | A requested reset action | Boolean input |
PreviousReset | Reset level at the previous evaluation | Boolean state |
SourceTrip | A source-unavailable event has latched | Boolean state |
StartupReady | The exercise's declared readiness condition is satisfied | Boolean input |
ExerciseEnabled | The learning sequence is enabled | Boolean input |
FillDemand | A remembered filling request | Boolean state |
PumpCommand | Current virtual pump command | Boolean result |
Initialise SourceTrip and FillDemand false for a fresh exercise. Sample the current ResetRequest into PreviousReset before normal evaluations. An already-held reset is therefore not invented as a new action at initialisation.
Evaluate the source trip even when the exercise is disabled. If SourceAvailable is false, SourceTrip becomes true. That choice keeps an observed source-unavailable condition visible independently of whether a fill was requested. It still does not identify the physical cause of that condition.
This lesson clears FillDemand whenever an eligibility condition is lost. After recovery in the middle band, it stays cleared until the lower boundary requests another fill. That is one explicit recovery policy. A different model could preserve demand while blocked, but it would have different restart results and needs separate tests.

Give the active trip condition priority over reset
Calculate ResetEdge from the current and previous reset levels. Then update SourceTrip in this order:
ResetEdge = ResetRequest AND NOT PreviousReset
If NOT SourceAvailable:
SourceTrip = true
Else if ResetEdge:
SourceTrip = false
Else:
retain SourceTrip
PreviousReset = ResetRequest
SourceAvailable false wins even when a fresh reset edge arrives at the same evaluation. Update PreviousReset on every evaluation, including while the source is unavailable. A reset held through source recovery is then still a held level, not a new action.
Compare this with the faulty expression (NOT SourceAvailable OR PreviousTrip) AND NOT ResetRequest. With SourceAvailable false and ResetRequest true, that expression returns false. It lets reset erase an active trip condition. The counterexample needs only those two inputs; a long normal-running demonstration would not expose the error as directly.
Schneider Electric's set-dominant SR reference documents a bistable where the set input wins when set and reset are both asserted. That priority concept is relevant here. The lesson adds a separately defined fresh-reset-edge policy; choosing a set-dominant block alone does not automatically supply that edge history.
Likewise, the CODESYS SR function block reference gives its set-dominant expression and interface. Use the actual block documentation for your environment instead of inferring behaviour from the letters in an instruction name. The model here is not presented as a compiled project for every vendor.
Check the trip latch independently of tank level
Before combining the latch with filling, enumerate PreviousTrip, SourceAvailable and ResetEdge. With SourceAvailable false, all four combinations of the other two values must produce Trip true. With SourceAvailable true and ResetEdge true, either previous trip state becomes false. With SourceAvailable true and ResetEdge false, the previous trip state is preserved.
Those eight cases isolate the priority rule from the rest of the programme. If one fails, changing a float contact or readiness timer cannot repair the latch itself. Record the result at the latch output before checking PumpCommand. Then reconnect the eligibility calculation and repeat the active-source-block case to verify that the complete model also keeps its command false.
Calculate the fill request after the trip update
Once the new SourceTrip is known, calculate eligibility and the demand:
ValidLevels = NOT AtHigh OR AboveLow
Eligible = ExerciseEnabled AND StartupReady AND ValidLevels
AND SourceAvailable AND NOT SourceTrip
If NOT Eligible:
FillDemand = false
Else:
FillDemand = NOT AtHigh AND (NOT AboveLow OR PreviousFillDemand)
PumpCommand = Eligible AND FillDemand
TripIndicator = SourceTrip
InvalidLevels = NOT ValidLevels
The filling expression starts below the lower boundary, holds through the middle band and clears at the upper boundary. The direct SourceAvailable condition also makes the current source permission visible in the command path. Neither it nor the latch is claimed to be a physical protective function.
Calculate eligibility after updating the trip. Otherwise a sequential programme might use an old trip value for one evaluation. The ladder logic simulator guide explains this old-versus-new-value issue with smaller examples.
Keep one clear writer to FillDemand and one to PumpCommand. Use separate variables for the remembered request and the final output so the recovery policy can be discussed without confusing command state with demand memory. In this version the memory is cleared on ineligibility, deliberately.

Work through the held-reset and recovery trace
Initial SourceTrip, FillDemand and PreviousReset are false. ExerciseEnabled is true throughout. A 1 means true, and result columns show values after the evaluation. The pair Low/High corresponds to AboveLow and AtHigh.
| Step | Low | High | Source available | Reset | Ready | Trip | FillDemand | PumpCommand |
|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
| 2 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 1 |
| 3 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 1 |
| 4 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
| 5 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 |
| 6 | 1 | 0 | 1 | 1 | 1 | 1 | 0 | 0 |
| 7 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 |
| 8 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 |
| 9 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 1 |
| 10 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 |
| 11 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 0 |
| 12 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 |
Step five is the active-condition/reset overlap. Trip remains true. Step six restores source permission, but reset is still held, so no fresh edge clears the trip. Step seven observes the release and step eight accepts the new reset action.
FillDemand stays false at step eight because the tank is in the middle band and the previous request was cleared during the trip. Step nine reaches the lower boundary and starts another fill. This is different from an implementation that preserves the old demand while blocked.
Step eleven reports InvalidLevels as true in addition to the zero results shown. Step twelve restores a valid middle-band tuple but does not invent a fill request. Add the InvalidLevels column to your own worksheet so a zero command can be explained by the actual blocking condition.
Test recovery while the tank is already low
Use a separate fixture with SourceTrip true, FillDemand false, SourceAvailable true and the tank at the lower boundary. PreviousReset is false. Apply a fresh ResetRequest true evaluation with StartupReady and ExerciseEnabled true.
SourceTrip clears and FillDemand becomes true at that same evaluation in this model. Reset therefore permits a new fill immediately when the low-level condition is present. That result is intentional, but it means “manual reset” is not the same as “manual reset followed by a separate Start”.
If your learning requirement needs a separate Start action, add another state and define that sequence explicitly. Do not claim the current model waits for an input it does not have. Keep the low-tank reset case beside the middle-band recovery case so the difference is visible.
Also test a new reset edge while SourceAvailable is false and the tank low. The trip stays true and the command false. This small boundary case is essential because a happy-path reset with the blocking condition already cleared cannot prove priority when both conditions overlap.

Define readiness without assuming a physical power event
StartupReady is a supplied input in the main trace. For an optional timing revision, define a software SessionStartedAt timestamp and set readiness true after 30000 ms of elapsed session time. At supplied times zero and 29999 ms, readiness is false; at 30000 ms it becomes true.
That is a declared session timer, not proof of when grid voltage returned or when a PLC physically powered up. A browser reload, application restart, download and equipment power restoration can have different state and timing consequences. Record which event your test actually creates.
If readiness becomes true while the tank is low and all other conditions permit, this model starts a fill without another button action. If readiness becomes true in the middle band after demand was cleared, it stays idle. Test both rather than describing the delay only as “wait thirty seconds”.
The staggered-start exercise separates timing origins and observed thresholds. Use the same discipline here. A fixed software delay alone does not establish reduced supply stress, suitable motor starting or protection from voltage conditions.
Compare the two possible demand-memory policies
The current model clears FillDemand when eligibility is lost. Consider an alternative that updates the level-band demand even while the source trip blocks PumpCommand. In that alternative, a remembered fill can survive a trip and resume in the middle band when permission returns.
Neither policy should be hidden inside a rung without being stated. The first may wait until a later low condition; the second may resume a remembered request. Their expected outputs differ at step eight of the main trace. Write a separate requirement and result column before implementing the alternative.
Do not treat that software comparison as a recommendation about real borehole operation. The appropriate recovery behaviour depends on the application and evidence beyond these input values. The lesson's contribution is to make the policy reviewable and to show the exact case that distinguishes it.
The pump-alternation exercise makes a similar separation between demand, availability and selection. Understanding those separate meanings is useful before combining more than one pump or adding assist behaviour.

Deliberate faults to find in a disconnected copy
Make reset dominant over an active source trip. Repeat step five and compare the faulty expression with the priority rule. Keep the overlapping input values in the fault report; saying only “reset did not work” does not explain the error.
Stop updating PreviousReset while tripped. Hold reset through recovery. If the stored value stays false, the implementation can accept the held input as a delayed fresh edge. Restore the update on every evaluation and repeat steps five through eight.
Use one level input for both start and stop without memory. Compare a fluctuating Boolean sequence with the two-boundary model. Describe the resulting command changes from that supplied sequence rather than claiming a universal physical cycle rate.
Invert an input without changing its documented meaning. Apply all four level tuples and compare the interpretation table. An apparently sensible rung can be wrong because it assumes a different meaning of true.
Treat an invalid tuple as normal low level. Use AboveLow false and AtHigh true. The model must report inconsistency and remain ineligible. Correct the validation before interpreting command behaviour from that row.
Use the old SourceTrip in eligibility. In a sequential model, a later trip update can leave an earlier command decision based on stale state. Test the first source-unavailable evaluation and inspect values after the entire routine.
Make the exercise useful for South African learning
A learner comparing PLC courses can ask whether float-control lessons test invalid inputs, reset overlap, readiness and middle-band recovery. A syllabus mentioning tank filling does not show whether these assumptions are explained. The online PLC training guide covers broader course-selection questions.
For a Waterberg distance learner, a Gauteng evening class or a Western Cape study group, the Boolean tables can be prepared offline and checked later in a software session. These are suggested learning contexts, not claims about local training premises or an actual lodge installation.
Keep the input meanings, initial state, trip priority, demand-memory policy and trace together in a project record. Include the low-tank reset fixture and the different middle-band result. State whether the observations came from a paper model, custom code or a named native environment.
The instrumentation technician guide and PLC learning for electricians connect the exercise to broader study routes. This page does not establish an accredited qualification, physical commissioning result or approval to modify water-supply equipment.
Continue with relevant sensor and logic practice
Inspect the sensor learning material for the product's current treatment of signal interpretation. Check its stated scope and access conditions. The complete model and trace on this page are not claimed to be automatically graded there.
The PLC curriculum overview provides a route for comparing related learning topics. Preserve your own predictions and observations independently of any product progress record.
Continue to the tank-level exercise if the fill band is the main difficulty, or return to the timer exercise if readiness and elapsed-time observations need more work. Choose the next task according to the behaviour you want to explain.

Questions about PLC float-switch control
Why does the trip stay on after source availability returns?
It remembers the earlier blocking event until a fresh reset edge occurs with SourceAvailable true. A reset held during the event does not become a new action merely because availability recovers.
Can reset start the virtual pump?
Yes, if it clears the trip while the low-level condition is present and the other permissions hold. In the middle band, this model's cleared demand stays false. A separate-start policy would need an additional requirement and state.
Does a false source input prove dry running?
No. It is a supplied eligibility value in this exercise. Establishing the physical condition, detecting wiring faults and selecting protection require information the model does not contain.
What should I ask an AI tutor to verify?
Supply steps four through nine and the rule that PreviousReset updates every evaluation. Ask for ResetEdge, SourceTrip and FillDemand separately. Check whether the answer incorrectly clears an active trip or treats a held reset as a fresh edge on recovery.