Your next machine

What should be on your desk before the editor?

Bring a sketch of the material path, a list of commands with their physical meaning, a signal map with validity and timing, and the unanswered questions. Add a behavior contract, the smallest adequate memory model, and at least one input history that could expose a wrong interpretation.

The first code should implement a decision you can already explain. For a simple indicator, that might be one Boolean expression. For a batch, it will include accepted parameters, sequence states and recovery. For two stations, it includes ownership across a boundary. The method is consistent; the amount of machinery you need is not.

Begin with a blank page you know how to use

You are given a new assignment: design a model cell that fills reusable containers, checks their weight, and sends them either to a good-output lane or a rework lane. A container can arrive while the preceding one is being inspected. The rework lane has limited capacity. The operator needs understandable recovery after interruption.

You do not need to remember an example program that happens to match this machine. You need a sequence of questions that turns an incomplete brief into a defensible design. This final project asks you to produce the evidence, not merely the animation.

Use the book's working path: brief, behavior, signals, sequence, code, fault tests, and handover. Move backward whenever a later step reveals an unanswered question. Discovering uncertainty is progress when you record and resolve it.

Your capstone assignment

The training cell has an inlet conveyor, one filling nest, one weighing nest, and a diverter feeding two lanes. Filling and weighing may overlap because they use separate nests. Transfer between them uses one shared zone. Each nest holds one container. The rework lane holds two; the good lane reports available capacity.

The model supplies presence sensors, measured weight with validity, conveyor position, actuator feedback, and configurable failures. Recipe values include target fill quantity, accepted weight band, maximum fill time, and maximum inspection time. The model does not represent a validated dosing instrument or safety system.

Your deliverables are a one-page functional brief, an I/O and interface list, resource and state diagrams, an active-part data structure, ordinary control code, test results, and a handover note. There is no required number of lines. A shorter design with clear ownership is preferable to a large program built from unexplained patches.

First resolve the questions the brief leaves open

Who owns a container while it is between nests? What happens if a weight result arrives after the container has moved? Does an unavailable measurement mean rework or a held container? Can a filling operation be continued after interruption? What stops admission when both output paths are blocked?

Choose explicit answers for the model and label them as design decisions. In a real project, the process owner and relevant engineering authorities would resolve these questions. Do not quietly turn your preferred answer into a customer requirement.

A defensible model policy is to reserve the destination before transfer, hold a container at weighing until its valid result is accepted, classify missing inspection as rework, and block release when the required lane has no capacity. An interrupted fill requires disposition and a fresh cycle. These decisions make uncertainty visible instead of guessing that the product is good.

Build a model answer from ownership

Use a line supervisor for admission and shared-zone arbitration. Give the filling and weighing stations their own sequences. Give the diverter one actuator owner. Use part records to carry identity, accepted recipe version, fill outcome, weight outcome, route decision, and final disposition.

The transfer transaction moves ownership from filling to weighing only after the agreed receipt evidence. Output-lane reservation belongs to a specific part. A generic LaneReady bit is an invitation to request capacity, not proof that a previously reserved place disappeared when readiness goes false.

Part record:
  Id and accepted recipe revision
  Current owner and transaction identifier
  Fill outcome and interruption reason
  Weight value, validity, and result timestamp
  Required route and reserved lane slot
  Final disposition or unresolved reason

Avoid one giant state number that encodes every combination of both nests and both lanes. Concurrency belongs in coordinated components with explicit interfaces. A shared supervisor should resolve shared resources, not duplicate each station's private logic.

Choose invariants before detailed transitions

An invariant is a statement that must remain true across all permitted operation. For this model, one part has one current owner; one shared zone has at most one granted transfer; filling and transfer requests cannot be active together for the same container; a released part has a recorded route; and a part with unavailable inspection is never labelled confirmed good.

These statements are excellent test assertions. They catch errors even when you did not predict the exact sequence that produces them. They also guide code review: locate the owners that enforce each invariant and challenge any alternate writer.

Add progress requirements. Eligible work should advance when its resources become available. Every accepted operation should complete or report an explained interruption. A design that never moves can satisfy many exclusion rules while failing its purpose.

Create a compact acceptance portfolio

Use normal cases, boundaries, disturbances, and recovery. For example:

Record model limitations beside the results. Passing with ideal sensors says nothing about real noise unless noise was represented and tested. Passing at a browser's display rate says nothing about a target controller's scheduling guarantees.

Hand over the reasoning

A useful handover note fits a clear template:

Purpose and operating envelope:
Approved requirements and unresolved decisions:
Software, configuration, and recipe versions:
Signal and resource owners:
Normal operation and recovery policies:
Acceptance evidence and known limitations:
Backup, restore, and change procedure:
Responsible support and approval roles:

Include a short glossary where terms have project-specific meanings. In this model, Accepted means work was committed under a transaction; Complete means the operation met its stated completion condition; Good means the defined quality evidence passed; Acknowledged means a message was received; Reset means a permitted latch or sequence condition was cleared; Recovered means physical and logical ownership were reconciled. None of these words should silently mean another.

Try it

Design the capstone before reading further. Then challenge it with this sequence: container 501 finishes filling, transfers toward weighing, and loses its receipt acknowledgement. Container 502 arrives at the inlet. The rework lane becomes full. The weight interface returns a delayed invalid result for 500, followed by a valid failing result for 501. Decide who owns each container, which resources remain reserved, and what may move.

Work through the answer

The missing acknowledgement leaves the sender uncertain about 501's transfer outcome. It does not prove that 501 remained at filling. Use the transaction identity and receiver evidence to reconcile ownership. The repeated acknowledgement for the existing transfer must not create another part record.

The result for 500 cannot classify 501 or 502. Match by identity and record the stale message separately. Once 501's valid failing result is accepted, its route is rework. Because rework capacity is unavailable, preserve 501 and its route at the defined holding location; do not relabel it good to keep production moving.

Container 502 may be admitted only if the chosen resource policy leaves a valid place for it without violating ownership or blocking necessary recovery. There is no universal requirement to maximize motion in this moment. The correct answer is the one consistent with the declared capacity, reservation, and recovery rules, supported by a trace.

Keep learning on a real target

Take one completed model to a selected vendor development environment. Study its task scheduling, I/O update rules, data types, timer library, online-change behavior, diagnostics, and restart semantics using the manufacturer's documentation. Rebuild the test harness around those facts. Treat differences as engineering work, not evidence that the earlier reasoning was wasted.

Then deepen the subjects your machines actually need: motion, process control, networks, electrical design, safety engineering, cybersecurity, or production data. You now have a way to approach unfamiliar tasks: identify the work, establish ownership, make decisions observable, and test the ways reality can disagree with your assumptions.