PLC Pump Alternation Logic: Duty, Standby and Recovery

This PLC pump alternation logic exercise separates three decisions that are often mixed together: when a demand cycle exists, which pump is preferred, and which available commands should be active now. You will model two virtual pumps, alternate the preferred lead after a defined demand completion, and test availability changes and an additional assist request.

The example is a disconnected software lesson. PumpOneCommand and PumpTwoCommand are indicators, not proof of flow, rotation or equipment health. No sump dimensions, pipework, motor ratings, protection design or flood-prevention performance are supplied. The input names describe fictional observations for learning, not validated field signals.

Before starting, review the start-stop seal-in exercise for remembered demand and the PLC programming examples collection for the wider project progression. Here the aim is to explain a complete state trace, including interruptions and recovery, rather than simply watch two lights take turns.

Separate demand, preferred lead and availability

Demand is a remembered request that starts at a supplied high-level condition and clears at a supplied low-level boundary. PreferredLead is either One or Two. AvailableOne and AvailableTwo are independent Boolean inputs that decide whether each virtual command is eligible.

Alternating PreferredLead is not the same as alternating the actual selected command. If the preferred pump is unavailable, the other available pump can be selected. If neither is available, demand can still exist while both commands are false. Keep those values separate in your watch sheet.

AssistRequest asks for both available commands while demand exists. In this lesson it is represented by a high-high input in a simplified ordered-level model. It never overrides availability. A false AvailableOne always prevents PumpOneCommand, including during assist.

The basic version recalculates command selection every evaluation. If the preferred pump becomes unavailable, selection can move to the other. If the preferred pump becomes available again during the same demand, selection returns to it. That return is intentional in this version and must be tested; a design that keeps the replacement selected until the cycle ends needs additional state.

Define the level meanings and valid combinations

Use three supplied Boolean level values with ordered thresholds. AboveLow means above the lower stop boundary. AtHigh means the start threshold has been reached. AtHighHigh means the assist threshold has been reached. In this fictional model, reaching a higher threshold implies the lower thresholds are also reached.

The remaining four Boolean combinations are inconsistent with this simplified ordering. For example, AtHigh true with AboveLow false is invalid here. Report InvalidLevels and clear demand and commands on that evaluation under this lesson's policy. Do not interpret an invalid tuple as a normal completed demand cycle.

This validation is a logical consistency check, not diagnosis of a failed float or a complete response design for a real installation. Actual devices can have different meanings, arrangements, delays and failure modes. Those need their own defined interpretation.

Add an ExerciseEnabled input. False means abort the current virtual demand and clear commands without rotating the preferred lead. That gives you a clean way to distinguish an interrupted lesson sequence from a completion at the declared lower boundary.

02

Define exactly when the preferred lead changes

Initialise Demand false and PreferredLead One for a fresh exercise. When ExerciseEnabled and ValidLevels are true, calculate:

NextDemand = AboveLow AND (AtHigh OR PreviousDemand)
CompletedDemand = PreviousDemand AND NOT NextDemand

If CompletedDemand is true in that valid, enabled evaluation, swap PreferredLead once. If demand remains false over several evaluations, do not keep swapping. If ExerciseEnabled is false or the level tuple invalid, clear Demand without treating the interruption as CompletedDemand.

That completion means the model observed a valid demand cycle end. It does not mean pumping succeeded, a measured volume was transferred or either pump actually ran. If both pumps were unavailable during the cycle, the same supplied level sequence could still end the demand. Name the event according to what the software actually knows.

A falling edge of Demand alone cannot distinguish all those causes. If you reset Demand for a mode change, invalid input or programme restart, it can also fall. The completion rule therefore includes the context in which the transition occurred.

The selected lead is retained between normal evaluations in this lesson. Persistence across programme restart, browser reload or controller power loss is a separate requirement. The online PLC simulator guide explains why saved programme content and runtime state should not be assumed to be identical forms of persistence.

Calculate command selection after updating demand

Once the new Demand and PreferredLead are known, use these rules:

PumpOneCommand = Demand AND AvailableOne
                 AND (PreferredLead = One OR AtHighHigh OR NOT AvailableTwo)
PumpTwoCommand = Demand AND AvailableTwo
                 AND (PreferredLead = Two OR AtHighHigh OR NOT AvailableOne)
NoAvailablePump = Demand AND NOT AvailableOne AND NOT AvailableTwo

When both pumps are available and assist false, only the preferred command is true. During assist, both are true. When only one is available, that one is selected while demand exists. When neither is available, both commands are false and NoAvailablePump is true.

NoAvailablePump describes the supplied eligibility inputs. It is not proof of a particular electrical fault or a comprehensive common-fault alarm. You could add separate reasons for unavailability in a larger learning model, but do not invent those reasons from a single Boolean value.

Calculate the commands after the demand and completion decisions. On a normal completion, Demand is false and both commands clear, even though PreferredLead has just changed for the next cycle. A display that shows the new preferred lead while both commands are off is therefore consistent with the model.

In ladder or structured text, preserve one clear writer for each state and command. The ladder logic simulator guide works through assignment-order effects that can make a watch display appear to contradict a correct intermediate result.

03

Work through availability, assist and rotation

Begin with Demand false and PreferredLead One. Both pumps are available unless a row says otherwise. All rows use valid level combinations. A 1 means true; Lead and command columns show the result after each evaluation.

Step three shows demand holding between thresholds. Step four transfers selection because the preferred pump is unavailable. Step five deliberately returns selection when that availability is restored. The preferred lead itself did not change during either event.

Step seven is a valid completion and rotates the lead. Step nine is an interruption through ExerciseEnabled false, so it clears demand without rotating. At step ten the still-present high-level condition starts a new demand under the same preferred lead. There is no fresh-button requirement in this level-driven demand rule.

Record these distinctions before running the programme. If your intended policy avoids returning to the preferred pump mid-cycle, keep this trace as the baseline and create a separate selection-memory revision with new expected rows.

Check the complete availability table

With Demand true and PreferredLead One, the command decisions are:

Repeat the table with PreferredLead Two. Only the both-available, no-assist row changes its selected command. This small comparison verifies that availability dominates preference, and that assist does not request an unavailable pump.

Also set Demand false for every row. Both commands and NoAvailablePump must then be false under the given definitions. If you want a separate indication that no pump is available even without demand, define another result instead of quietly changing the meaning of this one.

These tables establish Boolean properties. They do not measure transfer time, hydraulic response or uninterrupted service. Describe an observed change as a command selection change at an evaluation, not an instantaneous physical takeover.

04

Test invalid levels and repeated idle observations

Start an active demand with PreferredLead One, then supply AboveLow false and AtHigh true. The tuple is invalid. Under the exercise policy, InvalidLevels becomes true, Demand clears and PreferredLead stays One. The interruption must not count as a completed demand.

Restore the valid tuple with AtHigh true. Demand starts again and One remains preferred. Complete normally with all level inputs false and observe the single swap to Two. Repeat that same all-false tuple several times: Two must remain preferred throughout the idle observations.

This test catches a common mistake: toggling a lead variable on a false level every evaluation instead of on a defined completion event. It also exposes an implementation that uses every falling demand edge as evidence of successful completion.

If AtHighHigh is true while AtHigh false, flag the inconsistency in this model. Do not let an assist input bypass validity checks simply because it sounds urgent. A real application's response to abnormal level information requires its own assessment; this disconnected exercise only specifies a reviewable software behaviour.

Cycle alternation does not mean equal running hours

Consider four fictional completed demand cycles lasting 2, 10, 3 and 9 minutes, with both pumps available and no assist. Strict lead alternation gives One the first and third cycles, totalling five minutes, and Two the second and fourth, totalling nineteen. Both receive two lead assignments, but the commanded durations differ substantially.

Those durations still do not establish equal wear, energy use or actual runtime. They are supplied command intervals in a learning example. If you compare a runtime-based policy, define whether its counters use requested command, feedback-confirmed running or another observation.

Schneider Electric's operation-priority function block overview describes priority based on operating hours or a user-defined table within its pumping library. That is evidence that priority criteria can differ; it is not a claim that this article implements that library or that one criterion always produces the best equipment outcome.

A useful next revision chooses the lower accumulated runtime at a cycle boundary and specifies a tie-break. Keep its results separate from strict alternation. Changing the criterion changes the expected sequence and the data you must preserve.

05

Make recovery policy a deliberate choice

The basic version returns to the preferred pump when it becomes available again. A different version could store SelectedPump for the current demand, change it only when that selected pump becomes unavailable, and avoid returning merely because another recovers. Assist would need an explicit relationship to that stored selection.

Before implementing that extension, answer three questions in the requirements. Does a demand start choose the preferred available pump? Does loss of both availability inputs clear selection or remember the last one? When one becomes available again, can the programme select it automatically during continuing demand?

Those are policy choices, not details that the word “standby” resolves by itself. Test a selected-pump loss, recovery of the original lead, loss of both and recovery of only one. Record selection separately from command eligibility so an unavailable remembered selection cannot directly produce a command.

The star-delta sequencing exercise demonstrates why commanded state and physical feedback must remain separate. Use that distinction here too: AvailableOne true is a supplied eligibility input, not proof that Pump One is producing the required flow.

Preserve state with an explicit restart assumption

For this lesson, restarting a fresh exercise sets Demand false and PreferredLead One. Normal evaluations preserve the lead between completed cycles. If you want to preserve preference across a restart, define where it is stored, when it is restored and what happens if the stored value is unavailable or invalid.

Do not assert that a retentive bit is always the right answer or that it alone restores a consistent sequence. A stored lead, a demand latch and an actual process state can be restored at different times. Decide which state belongs to the learning policy and which must be recalculated from current observations.

For South African learners considering supply interruptions, the useful question is “Which variables survive this particular restart, and which inputs are present when the application resumes?” A general reference to load-shedding does not answer it. Keep browser reload, programme download and controller power restoration as distinct tests where relevant.

Build a useful training and portfolio record

A learner comparing pump-control topics in PLC courses can ask whether the course distinguishes preference, availability, demand completion and actual performance. A syllabus that mentions duty/standby does not show how it handles recovery or invalid inputs. The online PLC training guide covers wider course-evaluation questions.

For a Boksburg evening learner, a Durban study group or a Western Cape college project, the tables can be predicted offline and checked in a later software session. These are possible learning settings, not claims about local premises, current bookings or an actual workshop installation.

Keep the demand rule, completion definition, initial lead, input meanings and expected table together. Add the invalid-level case, both-unavailable case and the five-versus-nineteen-minute arithmetic example. State which results were calculated and which were observed in a named environment.

The millwright learning guide and instrumentation technician guide connect these concepts to broader study paths. A completed exercise is evidence of the reasoning recorded, not an accredited qualification, hydraulic design approval or proof that a real sump will not overflow.

Continue with relevant simulation material

Inspect the PLC curriculum overview for the current learning sequence and access conditions. Compare its stated objectives with this article's demand and selection model. The eleven-row trace and all extensions here are not claimed to be automatically graded there.

The sensor learning material is relevant if interpreting level inputs is the main difficulty. Preserve your own observations independently of product progress and distinguish a simulated level value from a measured installation signal.

Continue to the tank-level exercise to study the demand band more closely, or the flashing-beacon exercise to investigate indication and acknowledgement. Choose the next topic according to the behaviour you need to understand rather than adding alarms without a defined purpose.

06

Questions about duty/standby pump logic

Why does the preferred lead change when demand ends?

That is the chosen rotation point for a valid, enabled completion in this model. An abort or invalid input clears demand without rotating. Other policies can choose a different event, but they need their own expected cases.

Will alternating every cycle equalise running hours?

Not necessarily. Different cycle durations, assist and availability changes can produce unequal commanded time. The worked four-cycle example gives two lead assignments each but five versus nineteen minutes.

Why does selection return to the original lead after recovery?

The basic command rule recalculates from preferred lead and current availability every evaluation. A policy that keeps the replacement selected needs additional remembered selection state and explicit recovery rules.

What should I ask an AI tutor to check?

Provide steps four, five, seven and nine of the trace with the previous Demand and PreferredLead. Ask it to calculate completion, new preference and both commands separately. Check whether it incorrectly treats an interruption as a completed cycle or a recovered availability signal as a rotation event.