Stage 4 of 6 · Theory, pen ready · about 20 minutes

Flow & state

Pseudocode is text; some logic is easier to see. Flowcharts draw the same three structured shapes as boxes, diamonds and arrows, and for branching flow they are often the clearest notation in the room. You have met their relatives before, in the automation lab.

A second notation, and why

Flowcharts and pseudocode describe the same thing, control flow, in different media. A flowchart's strength is topology: every possible path is a visible line, so a missing branch or an inescapable loop is literally a gap or a knot on the page. Its weakness is density: assignments, arithmetic and data details bloat a chart that pseudocode states in one line. Professionals sketch the flow when the branching is the hard part, and write pseudocode when the steps are. This course expects you to read both fluently and produce whichever the problem favours; the Wikipedia flowchart article covers the notation's long history, from 1920s industrial engineering onward.

The symbols

Four shapes cover this course. The full standard has more (subroutines, connectors, stored data); these four are the working set, and the discipline is in the arrows: labelled exits, no dead ends.

The reaction timer as a flowchart

The same design as the pseudocode, drawn. Follow the false-start path with a finger: it is one visible loop back to the top.

The branching is the picture. Two decisions, three loops (the wait loop back to the delay check, the false-start return, the new-round return), zero ambiguity about where any answer leads. This chart and the pseudocode are the same design; on the midterm you may be asked to convert either into the other.

The bridge from automation

You have drawn logic before. The IEC 61131-3 languages from your PLC work map onto this week directly, and recognizing the family resemblances makes both sides easier:

Ladder logic is mostly selection: each rung is an IF (contacts) THEN (coil), rescanned forever, which is why LOOP FOREVER around a batch of IFs felt familiar in Week 4's polling script.
Sequential function charts (SFC / GRAFCET) are flow plus state: steps that are active, transitions with conditions, exactly a flowchart whose boxes can be "the mode we are in". If you have drawn a GRAFCET, you have drawn a state diagram with different clothes.
The functional description your automation courses write before a control program is a requirements document; this week's shall-discipline is its software twin.

The transfer runs both ways: pseudocode and trace tables will make your next PLC design cleaner, and your GRAFCET instincts are about to make state diagrams feel obvious.

When flow is not enough: state

Flowcharts answer "what happens next"; some systems are better described by "what mode am I in". A state is a named mode; events move the system between modes; a state diagram is the map. The reaction timer has three natural states, and the diagram makes one subtle truth visible that the flowchart buries: the button means different things in different states, a false start in one, a measurement in the other.

Same button, different meaning per state. In code, state is just a variable (mode = "WAITING") consulted by IFs, or, from next week, an object's attributes. The diagram is the map; a variable is the memory.

You have already built state without naming it: Week 4's hold-to-arm exercise was a two-state machine (armed/disarmed), its state stored in whether the LED was lit. Naming states is the upgrade: designs stop being "a pile of flags" and become "a machine with three modes", which is how Week 10's control logic and the project's operating modes (normal / alarm / maintenance, say) will be designed. The finite-state machine article is the standard background; GRAFCET veterans will find it familiar territory.

Choosing a notation

The hard part of the problem is...	Reach for	Because
Steps and calculations, mostly linear	Pseudocode	Dense, precise, traceable line by line
Branching: many paths, easy to miss one	Flowchart	Every path is a visible line; gaps show
Modes: the same input means different things at different times	State diagram	Makes the modes and transitions the primary objects
Convincing yourself it works	Trace table	Executes any of the above, on paper, mercilessly

Drawing tools, when paper stops being enough: diagrams.net (free, in the browser) draws flowcharts and state diagrams; for diagrams that live in the repository as text, Mermaid renders them from Markdown, GitHub included. Hand-drawn and photographed is completely acceptable evidence in this course.

Checklist for this stage

I can draw the four symbols and state each one's rule
I followed all three loops of the timer flowchart with a finger and matched each to the pseudocode
I can name the ladder-logic and GRAFCET relatives of IF and of state diagrams
I identified the timer's three states and what the button means in each
I can pick a notation for a given problem and defend the pick

Check yourself

A diamond in a flowchart has one unlabelled exit. What two rules are broken?

A decision must have one exit per answer (at least yes and no), and every exit must be labelled. One unlabelled exit means a path is missing and the remaining one is ambiguous, exactly the errors flowcharts exist to expose.

When does a flowchart beat pseudocode, and when the reverse?

Flowcharts win when branching topology is the hard part: paths are visible lines, so missing branches show. Pseudocode wins when steps, data and calculations dominate: one precise line replaces a bloated box, and it traces better.

What is the GRAFCET/SFC cousin in this week's toolkit?

The state diagram: active steps are states, transitions with conditions are events. If you can read a GRAFCET, you can read a state diagram, and vice versa.

What fact does the timer's state diagram make obvious that the flowchart hides?

That the same event, a button press, means different things in different modes: false start in WAITING, measurement in READY. State diagrams make "meaning depends on mode" the headline.

How does "state" exist in actual Python code?

As remembered data consulted by decisions: a mode variable (mode = "WAITING") with IFs on it, flags like false_start, or, from Week 6, an object's attributes. The diagram is the design; variables are the implementation.