LOGO! Tank Sequences Need a Running Latch and a Counter Model

This fill/mix/empty assignment for LOGO! Soft Comfort stalls because Start (I1) latches the fill solenoid directly, with no NOT operators anywhere in the diagram. That leaves the program with no way to know whether it should resume filling, mixing or emptying after a Stop. The working structure has four parts. An RS latch holds a single Running bit. An Up/Down counter fed by pulse generators models tank level and remembers direction. A 12 s timer delays the empty valve. The mixer output comes from the other two outputs through NOT.

Why does the simulation always go back to filling after Stop?

In simulation, you press Start and Q1 (fill) lights. You press Stop partway through mixing, then Start again, and fill lights again even though the tank model is full. The cause is structural, not a wrong parameter. When I1 feeds an RS block whose output is the fill solenoid, resetting that RS block is the only way to stop filling, and setting it is the only way to restart. The program has no bit that records which step the process was in, so every restart means "fill".

The fix separates two independent pieces of state:

• Run state: Start/Stop, owned by one RS latch labelled Running. I1 and I2 connect to this block and nothing else.
• Process state: filling, mixing or emptying, owned by the counter and timer. Stop must not clear these, so they are still valid when Start is pressed again.

Every output is then an AND of Running with some process-state condition. When Running is False, all outputs are off. When it is True, exactly one output is on.

The second symptom is logic that can switch things on but never off at the right time. LOGO! FBD is Boolean algebra with three operators: AND, OR and NOT. Every other block is built from those three. A diagram with only AND and OR blocks cannot express "fill while the tank is not full" or "mix while the timer has not expired." Add NOT blocks or inverted input pins before tuning anything else.

How does LOGO! actually evaluate these blocks?

Read the diagram as operations on memory bits, not as wires to the terminals. Each scan cycle does three things:

1. Read the physical inputs into input image bits (I1, I2, AI1…).
2. Evaluate every block in a fixed order and write the results to memory: flags M/AM, block outputs, and output image bits Q/AQ.
3. Copy the output image bits to the physical outputs.

The scan then repeats. Timers accumulate between scans. Counters and RS latches keep their internal values from one scan to the next, and that retention is what lets the program resume a step.

When the simulation misbehaves, sort the problem into one of two classes before editing anything:

Fault class	What you see in simulation	Where to look
Block (parameter) fault	Output switches at the wrong count or time. Timer never expires. Counter never flips direction.	Block properties: counter On/Off thresholds, timer preset, pulse generator on/off widths.
Binding (connection) fault	Output never changes, or changes in the wrong step. Two outputs are on together. Nothing stops when I2 is pressed.	The connection lines: missing inverted pin, Running not ANDed into an output, I1/I2 wired past the latch.

Every symptom in the original diagram came from a binding fault: missing NOTs and Start/Stop wired straight to the fill logic.

What is the Up/Down counter doing on screen, and why does it model the tank?

No level sensors exist in this exercise. Each 1 s pulse from a pulse generator stands in for one unit of flow-meter volume. The counter's thresholds provide full/empty hysteresis. In the working build (B006), the On threshold is 8 and the Off threshold is 2:

Count value	Counter Q	Meaning
8 (at or above On = 8)	Always True	Tank full
1 (below Off = 2)	Always False	Tank empty
2–7	Keeps the last value reached	True if 8 was reached last (emptying). False if 1 was reached last (filling).

The in-between band is the useful part. The counter Q tells the program whether it is filling (counting up 1→7, Q False) or emptying (counting down 8→2, Q True). Because the counter keeps that value across scans and across a Stop, it already stores two things the assignment needs: the cycle repeats, and it restarts from where it was.

Two counter behaviours explain most of what you see:

• Edge counting. The counter changes once per Off→On transition at Cnt, even though it is evaluated on every scan while the input is held on. It stores the previous state of the pin and compares against it each scan.
• Direction from its own state. Feed the counter's Q to its direction input. It then counts up while Q is False and down while Q is True. Hold a single test input on and the count runs 1→8, flips, runs 8→1, flips, and repeats. Release the input at any point and the count and Q hold. Press again and it continues in the same direction.

Run this bench test before wiring the full sequence:

1. Place the counter alone, driven by one input configured as momentary.
2. Press Simulate and click the input a few dozen times.
3. From count 1, give seven Off→On transitions. Watch Q go True on the seventh, when the count reaches 8.
4. Give one more transition and note which way the count moves. Continue for six more, then watch what happens as the count reaches 1.

The fill/empty inhibit follows directly from this. With counter Q on an inverted pin of the fill AND (B001), the fill output drops when the count reaches 8. It cannot count past 8 even with the fill request held.

The assignment specifies two pulse generators: flow meter 1 enabled by Fill, flow meter 2 enabled by Empty. Their outputs are ORed into the counter's Cnt. A single pulse generator enabled by (Fill OR Empty) works identically, but build the two-generator version if the marking scheme follows the block list.

Which program structures can run fill, mix and empty?

Four structures are possible. They differ in whether they can resume after Stop and how much logic they need.

Approach	How the step is held	Resume after Stop	Complexity
A. Start/Stop RS drives Fill directly (original)	Not held	No. Always restarts at fill.	Low, but cannot meet the spec
B. Running latch + counter model + timer delays Empty. Mixer derived as Running AND NOT Fill AND NOT Empty.	Counter Q (fill vs empty) + timer (mix done)	Yes for fill and empty. Mix resume depends on timer type.	Lowest. Only two outputs need real logic.
C. Running latch + counter + timer runs Mixer for 12 s. NOT Mixing added as a third input on the empty AND (B002).	Counter Q + mixer timer	Same timer dependence as B	Similar to B, one more interlock
D. Cascade of RS latches, one per step. Each step sets the next and resets itself.	One latch per step	Yes, naturally. Latches ignore Stop.	More blocks. Transitions and a repeat reset must be written explicitly.

Use B. Once Running exists, only two outputs need logic built from level and time: Fill from the counter, Empty from the counter plus timer. The third output, the mixer, needs no timing of its own. It is on whenever the system is running and neither of the other two is. B and C both work. B wins because the mixer equation cannot conflict with fill or empty. C needs an extra interlock to stop Mix and Empty from overlapping. D is the better choice once you have more than three steps or need the latched step visible as its own bit. Try building it as a second exercise after B works.

Which timer keeps the 12 s mix correct through a Stop?

The assignment lists an off-delay timer for the mixer (B4). With the right trigger, an On-Delay, Retentive On-Delay, Off-Delay or Edge-Triggered Wiping Relay can all produce the 12 s mix. They differ in what happens when Stop is pressed mid-cycle, and that is where the requirement "stop immediately, continue from where it left off" catches people out.

Take a plain On-Delay with a 12 s preset. Its Q stays False until the accumulator reaches 12 s, then stays True while the trigger stays True. Two trigger choices behave differently:

Timer trigger	Stop pressed during Mix	Stop pressed during Empty
Counter Q only	Timer keeps running while stopped. It can expire, so on restart the program skips the remaining mix and empties an under-mixed tank.	Timer is already expired and counter Q stays True, so emptying resumes. Correct.
Counter Q AND Running	Timer resets to 0. A full 12 s mix runs on restart. Usually acceptable.	Timer resets. Restart runs a second full 12 s mix on a part-emptied tank. Not acceptable.

Neither trigger resumes correctly in both cases. A resume-capable mix timer must pause while stopped and clear only when the tank is empty:

Mix timer option	Setting	Effect
Plain On-Delay, trigger = Counter Q AND Running	Preset 12 s	Simplest. Use it first to get an uninterrupted fill/mix/empty loop running.
Retentive On-Delay	Preset 12 s. Reset pin driven by NOT Counter Q.	Holds elapsed/expired state through Stop. Needs an explicit reset when the tank becomes empty, otherwise the next cycle skips mixing.
Second Up/Down counter counting the 1 s pulses while Mix is on	On threshold 12. Reset by NOT tank-counter Q.	Pauses exactly while stopped, because Mix is gated by Running. Counters hold their value, as the tank model already shows. Resolution is 1 s.
Off-Delay / Edge-Triggered Wiping Relay	12 s width, triggered by the full condition	Can produce the mix pulse. Pausing on Stop needs extra logic. Test before committing.

Open each candidate's block help and run it alone in simulation before choosing. Feed it from test inputs with a 3–5 s preset and toggle the trigger and reset pins. Watch the accumulator after dropping the trigger mid-count. You need to see whether it freezes, keeps running or clears. If your first timer choice can't meet the resume requirement, replacing it is normal. The experiment tells you what the next block must do.

How do you wire the recommended sequence block by block?

The block numbers below follow the working build. Rename them to match your own diagram.

1. Add an RS latch (B007). Wire I1 to Set and I2 to Reset, and comment it Running. I1 and I2 must connect to nothing else.
2. Build the fill AND (B001). Connect Running to one input and tank-counter Q (B006) to an inverted input. Wire the output to the fill solenoid output.
3. Add flow meter 1: a pulse generator with 1 s timing, enabled by the fill output. Add flow meter 2 the same way, enabled by the empty output. OR their outputs into B006 Cnt.
4. Set B006 thresholds to On = 8 and Off = 2. Wire the direction input from B006 Q. Wiring it from the empty output instead behaves identically, because pulses only arrive while fill or empty is on. Counter Q is preferred because it is the state bit.
5. Add the On-Delay mix timer (B008) with a 12 s preset, triggered by B006 Q AND Running. Get the loop running with this first. Swap to a pause-capable timer later.
6. Change the empty AND (B002). It currently uses Running AND counter Q, which opens the valve the moment the count hits 8. Replace or add the timer Q input so the valve opens only when B008 expires.
7. Add the mixer AND: Running AND NOT Fill AND NOT Empty, using inverted pins or [1] NOT blocks.
8. Comment every block (Running, Tank level, Mix done). You will need those labels when debugging the resume behaviour.

The whole sequence as Boolean expressions:

Running   = RS( S = I1 , R = I2 )
Fill      = Running AND NOT CounterQ
MixTrg    = Running AND CounterQ            ; 12 s On-Delay -> MixDone
Empty     = Running AND CounterQ AND MixDone
Mix       = Running AND NOT Fill AND NOT Empty
Cnt       = Pulse(Fill, 1 s) OR Pulse(Empty, 1 s)
Dir       = CounterQ                         ; On = 8, Off = 2
; resume-capable variant: MixDone from Retentive On-Delay,
; reset = NOT CounterQ

Why is the mixer just Running AND NOT Fill AND NOT Empty?

While running, the process is always in exactly one of three states:

• Fill: the tank is not full.
• Empty: the tank is not empty and the mix delay has expired.
• Mix: everything else.

If the system is running, and it is NOT filling (count at 8, counter Q True, fill off), and it is NOT emptying (delay still active, valve closed), the only state left is Mix. The program already calculates Running, Fill and Empty in the same scan, so the mixer adds no timing or level logic of its own.

This also explains how the timer gates each output:

• The timer Q does not go to 1 until the accumulator reaches 12 s, which delays Empty.
• During those 12 s, timer Q is 0, Empty is 0, and Fill is also 0. That leaves Mix as the only True output.
• The count stays at 8 throughout mixing, so the fill output stays inhibited without any extra interlock.
• When the timer expires, Empty goes True and Mix drops automatically through its NOT Empty term.

A single wrong term shows up immediately in simulation:

What the screen shows	Missing or wrong term
Mixer on while stopped	Running not ANDed into Mix
Mixer and fill on together	Fill not inverted into Mix
Valve opens the instant the count hits 8	B002 still uses counter Q without the timer Q
Second cycle has no mix step	Mix timer not reset when the tank empties (retentive variant)

How do the assignment's output numbers and indicators map onto this logic?

The working build used Q2 as the empty valve during development. The assignment's allocation is different. Remap the outputs before submission:

Assignment point	Function	Driven by
I1	Start, push-to-make	Set of Running RS (B1 in the brief)
I2	Stop, push-to-make	Reset of Running RS
Q1	Fill solenoid A	Fill AND
Q2	Tank full indicator	Derived from counter state (see below)
Q3	Mixer motor	Running AND NOT Fill AND NOT Empty
Q4	Empty solenoid B	Empty AND
Q5	Tank empty indicator	Derived from counter state (see below)
M1	On/off flag from counter	Counter Q (B3 in the brief)

Indicators. The brief describes "full" as the counter On value of 8 and "empty" as the Off function at 1. Counter Q is a direction/state bit, not a level switch: it stays True all the way from 8 down to 2. If the indicators must light only at the extremes, qualify them:

• Full indicator: counter Q AND NOT Empty. This lights through the mix step and clears when draining starts.
• Empty indicator: NOT counter Q. This lights when the count reaches 1.

Decide which reading the marker expects and state it in a block comment.

No pumps. The brief describes solenoids A and B, not pumps. Name the outputs as solenoids.

Stop and repeat wording. "Stop immediately, continue from where it left off" and "reset and repeat until the stop switch is pressed" can be read two ways:

1. Immediate pause. Stop drops Running at once and all outputs go off. Start resumes the held step. The architecture above implements this reading, provided the mix timer pauses rather than resets.
2. Stop at end of cycle. Stop lets the current cycle finish and parks at empty. To get this, gate the Running reset with the empty condition (NOT counter Q) instead of wiring I2 straight to Reset.

Reading 1 matches "immediately". Build that one and note the interpretation in the program comments.

How do you prove resume-after-Stop in simulation?

1. Set I1 and I2 as momentary inputs and press Simulate.
2. Press I1. Confirm Q1 lights and the count climbs from 1 (the first pass may start from 0) to 8, one step per second.
3. At 8, confirm Q1 goes off, Q3 comes on, and the mix timer accumulator starts from 0.
4. Let 12 s elapse. Confirm Q3 goes off and Q4 comes on in the same step, and that the count falls 8→1.
5. At 1, confirm Q4 goes off, Q1 comes back on, and the mix timer clears. Let two full cycles run unattended.
6. Press I2 during filling. All outputs must go off and the count must hold. Press I1: filling must resume from the held count.
7. Press I2 at about 5 s into mixing. All outputs must go off. Check the timer accumulator:
   • With the plain On-Delay gated by Running, it resets to 0.
   • With a resume-capable timer, it must freeze at about 5 s.
   Press I1 and confirm the mixer runs only for the remaining time (resume-capable) or a full 12 s (plain).
8. Press I2 partway through emptying (count around 5). Press I1. Q4 must come straight back on with no second mix step, and the count must continue down from about 5.
9. Throughout every step, confirm that no more than one of Q1, Q3 and Q4 is ever lit, and none is lit while Running is False.

FAQ