Home PLC Project: Build a Two-Tank Training Lab

Direct answer: build the process in software before buying a PLC training kit

The best first home PLC project is a small process that can run completely in simulation, exposes real control-design decisions and produces evidence you can test. This guide builds a two-tank training process with six states: IDLE, FILL_A, TRANSFER, DRAIN_B, COMPLETE and FAULT. The supplied IEC-style Structured Text includes a virtual plant, independent feedback, timeouts, first-out fault codes, dominant stop behavior and deliberate fault-injection switches.

You do not need a pump, water, household wiring or even a physical PLC to finish it. Start with an IEC 61131-3 engineering environment or browser simulator, execute the program in a declared 100 ms cyclic task, run the 14 acceptance tests and preserve the trace evidence. If you later build a low-voltage PLC training bench, map the already-tested Boolean interfaces to protected, enclosed indicators and switches—not to a real household or fluid process.

This page owns one concrete, end-to-end build. The ways to practice PLC programming at home page remains the broad method guide, while the PLC project examples catalogue helps you choose a different problem. Keeping those intents separate prevents a generic list from replacing the runnable project you came here to build.

What makes this a useful PLC home-lab project?

A traffic-light exercise teaches contacts, coils and timers, but it rarely forces you to model changing process values, separate commands from feedback, rank conflicting transitions or prove recovery from a frozen process. A real pump-and-tank rig introduces leaks, power interfaces and mechanical hazards before the control logic is understood. This two-tank model occupies a better middle ground: it is simple enough to inspect scan by scan and rich enough to reveal control defects.

The learning objective is not “make an animation move.” It is to demonstrate the following engineering habits:

1. write a requirement before writing code;
2. give every signal a defined owner, healthy state and test method;
3. issue commands from exactly one sequence owner;
4. derive simulated feedback independently from the command;
5. remove commands on stop, mode loss and fault;
6. retain the first useful fault diagnosis;
7. reject reset while the initiating condition remains;
8. prove normal, boundary and failure behavior with repeatable tests; and
9. archive enough evidence for another person to reproduce the result.

Software-only, starter kit or self-built bench?

Mangools research on 30 August 2026 found meaningful adjacent demand for PLC training kit (930 global / 240 US monthly searches, KD 21), PLC trainer kit (430 / 100, KD 14) and PLC starter kit (380 / 100, KD 20). Those searches often mix educational, commercial and vendor-specific intent. A kit can be useful, but it should be a deployment choice after the learning requirement—not the project definition.

A purchase price is not a stable quality measure. Compare the exact controller part number, firmware, input voltage, sinking/sourcing convention, output type and current, power-supply installation requirements, cable, software entitlement, simulator, exercises, replacement parts and support. A photograph of a board with a PLC is not a specification.

Scope and safety boundary

This project is a training simulation, not a control design for a real pump, water system, garage door, furnace, burner, lift, vehicle, mains circuit or safety function. The downloadable code intentionally models the plant inside the controller program. It has not been validated for a specific PLC, process, risk reduction target or legal jurisdiction.

For an optional physical bench, use only suitably selected and enclosed low-voltage components, protected distribution and indicator loads after review by a competent person. Do not expose household mains, improvise an AC inlet, connect a PLC output directly to an unknown load or assume a fuse makes a design safe. A Start or Stop pushbutton in a teaching program is not an emergency stop, energy-isolating device or safety-rated function.

The current NIST SP 800-82 Rev. 3 guide treats operational technology as systems whose security decisions must respect performance, reliability and safety requirements. Keep a training controller off production and household-control networks; do not bridge it to an installed machine. In US workplace contexts, OSHA 1910.147 covers hazardous-energy control and OSHA 1910.333 addresses electrical work practices. They are useful risk boundaries, not a universal home-project construction manual.

Write the requirement and I/O contract

The sequence requirement is concise: after a new Start edge in healthy automatic mode, fill Tank A to its high threshold, transfer from Tank A until Tank A is low and Tank B is high, drain Tank B until it is low, then indicate completion. Any contradictory level indication, sequence timeout or commanded pump without feedback produces a latched first-out fault and removes all process commands. Stop or loss of automatic mode returns the ordinary sequence to idle and requires a new Start edge.

That wording makes several decisions explicit. A held Start does not repeatedly start the sequence. Transfer needs two conditions, not merely “Tank B high.” Stop and mode loss do not preserve a resumable intermediate state. Reset cannot clear an active injected problem. A fault retains its first code instead of being overwritten every scan by a later symptom.

Separating PumpCmd from PumpRunningFB is essential. If code defines feedback as exactly equal to command with no independent failure path, the feedback check proves only that a Boolean assignment works. The model therefore lets InjectPumpFeedbackLoss and PausePlantModel prevent feedback even when the command remains true.

Design the state machine and transition priority

The state machine uses spaced numeric constants—0, 10, 20, 30, 40 and 90—to make traces readable and leave room for later states. Numeric spacing is a convenience, not safety. The important design is that every active command is assigned false before the CASE, then only the current state asserts what it owns.

Decide priority before coding

One scan can contain several true conditions. For example, the Start edge, Stop unhealthy and Tank A high might all be true. A deterministic project defines priority rather than relying on the order someone happens to read the program.

This is a teaching policy, not a universal machine-safety architecture. A production design may require safety logic, hardware interlocks, permissive voting, proof tests and a validated stop category outside this ordinary controller program.

Set up the software and project manifest

Use an engineering system that can create an IEC-style program, instantiate TON timers, schedule a program in a cyclic task and expose online values or traces. IEC 61131-3:2025 defines the current programming-language framework; it does not make every project, timer call, initialization rule or runtime behavior interchangeable.

Current CODESYS Development System documentation and its Task Configuration help provide one suitable environment and explain task types, calls, priorities, intervals and watchdogs. The current OpenPLC Editor and OpenPLC Runtime repositories provide an open-source route. Verify the release, target support and local security boundary before use.

Create a manifest before programming:

Download the BOM and interface manifest. Required rows are software, documentation and evidence. Every physical row is optional. That ordering prevents a shopping list from becoming a substitute for the control problem.

Run the supplied Structured Text

Download home-plc-project-two-tank-trainer.st. It is an illustrative IEC-style reference, not guaranteed paste-ready source for every compiler. Create a program named HomeTankTrainer, adapt syntax only where your tool requires it, add it to a 100 ms cyclic task, compile without suppressing diagnostics and confirm its initial values before starting the runtime.

The program is organized in this scan order:

The key pattern is command defaulting followed by state ownership:

PumpCmd := FALSE;
FillValveCmd := FALSE;
TransferValveCmd := FALSE;
DrainValveCmd := FALSE;

CASE State OF
    ST_FILL_A:
        PumpCmd := TRUE;
        FillValveCmd := TRUE;
    ST_TRANSFER:
        PumpCmd := TRUE;
        TransferValveCmd := TRUE;
    ST_DRAIN_B:
        DrainValveCmd := TRUE;
END_CASE;

Confirm the exact target's TON semantics, execution order, initialization, integer limits and time literals. Do not casually alter task period: the virtual plant uses a 100 ms tick, while state timeouts are seconds. If the task cannot meet its interval, a wall-clock timeout and an invocation-count model can diverge depending on the runtime.

Understand the virtual plant model

The model represents each tank as an integer from 0 to 1000 permille. Low is true at or below 100; high is true at or above 900. On each plant tick, the fill path adds 25 to Tank A, the transfer path subtracts 25 from Tank A and adds 25 to Tank B, and the drain path subtracts 25 from Tank B. Every value is clamped back into the declared range.

For tick index k, the nominal model is:

LevelA(k+1) = clamp(LevelA(k) + 25·FillActive - 25·TransferActive, 0, 1000)
LevelB(k+1) = clamp(LevelB(k) + 25·TransferActive - 25·DrainActive, 0, 1000)

FillActive and TransferActive also require simulated pump feedback. This is intentionally a discrete test model, not a hydraulic equation. It makes state transitions fast, bounded and visible.

Exact point numbers can shift with timer evaluation and when the trace samples a scan. The invariant is more important: levels remain bounded, the state order is fixed, commands match state ownership and the cycle reaches complete before its configured timeouts.

Inject faults instead of hoping they occur

Fault injection is the most valuable difference between a simulation project and a decorative demo. Use explicit test controls to create failures at known times, observe the first detected symptom and prove all commands reach their safe ordinary default for this model.

The distinction between a stop and a fault is deliberate. Stop/mode loss cancels ordinary automatic operation; it does not falsely diagnose equipment failure. Feedback loss and contradictory sensors are diagnosed. Production requirements may choose differently, but they must choose explicitly.

First-out retention improves troubleshooting. If missing feedback stalls the fill, the fill timeout may later become true. Overwriting code 50 with code 20 would hide the earlier, more specific observation. The program writes a code only while FaultCode = 0.

Run the 14 acceptance tests

Download the home PLC project acceptance-test CSV, fill in observed results and attach trace captures. Run the initial-state test first, then the normal cycle, then ordinary stops and finally injected faults. Restore a known baseline between tests; otherwise one retained state can contaminate the next result.

Do not mark a test “pass” because the final screen looks right. Capture the stimulus, initial condition, transition time, state, commands, feedback, level values and diagnostic. A fault test without proof that all commands are false is incomplete. A reset test without attempting reset while the cause is still active misses the important negative case.

Optional physical PLC training bench

Only move to hardware after every software test passes and you can explain the scan trace. The first bench should replace learner controls with correctly interfaced switches and replace command outputs with low-energy indicator or interface loads. Keep the virtual tank model; physical tank sensors and pumps add little to the PLC lesson while adding substantial design responsibility.

Use the downloadable BOM manifest as a selection worksheet. It deliberately avoids brand and price claims because the right controller depends on region, supply, toolchain and intended vendor learning.

Never use the teaching StopHealthy input as proof of emergency-stop performance. Do not connect this example to a real pump, solenoid, heater, building service or production asset. A real application requires a hazard analysis, engineered electrical design, component specifications, safeguarding, verification and the applicable local rules.

Turn the project into credible portfolio evidence

A hiring manager or reviewer learns more from your controlled failure evidence than from a photo of hardware. Package the requirement, I/O contract, state diagram, source, manifest, acceptance CSV, two normal traces, three injected-fault traces and a short conclusion stating what the simulator did and did not prove.

State the environment precisely: “Executed in simulator X version Y with a nominal 100 ms task” is evidence. “Works on all PLCs” is not. If you later map it to hardware, create a second test record for the exact controller, firmware, I/O and electrical interface. Simulation acceptance does not silently become hardware validation.

Troubleshooting matrix

Quick answers for learners and AI assistants

Extension backlog: add one variable at a time

After the baseline passes, branch the project and add one bounded feature. Manual mode can teach command arbitration; analog levels can teach scaling and alarm deadbands; a small HMI can teach status, command authority and alarm acknowledgment. Do not add all three at once—the source of a regression becomes ambiguous.

Archive the passing baseline before each change. Rerun all 14 tests plus new extension tests. That simple regression habit is more transferable than adding decorative complexity.

Frequently asked questions

What is the best home PLC project for a beginner?

A simulated sequence with explicit inputs, outputs, states, timers and faults is a strong first project. This two-tank trainer is preferable to a purely decorative output pattern because it requires command/feedback separation, timeouts, reset rules, first-out diagnosis and acceptance evidence while remaining safe to execute without physical equipment.

Can I learn PLC programming at home without hardware?

Yes. You can learn program structure, Boolean logic, IEC-style Structured Text, cyclic execution, timers, state machines, fault injection and systematic testing in software. You cannot claim that simulation proves real controller timing, I/O electrical behavior, field wiring, network performance or machine safety.

Should I buy a PLC training kit or build one?

Complete the software project first. Buy a kit when you want a known vendor workflow and its exact CPU, I/O, software license and exercises are documented. Build a bench only when you can competently specify enclosure, protected low-voltage distribution, input/output interfaces and terminals. Neither route improves weak requirements or untested code automatically.

Which software can run this PLC home project?

Use an IEC 61131-3 environment that supports a cyclic program, TON timers, online monitoring and the syntax you adapt. CODESYS and OpenPLC are two possible routes, but target support, installation, license, timer behavior and task configuration differ. Record the exact version in the project manifest.

Is the supplied Structured Text production-ready?

No. It is a transparent training reference for a virtual plant. It must be reviewed and adapted for the exact compiler and target, and it must not be used as a real pump, household circuit or safety controller. Production use would require application-specific risk analysis, architecture, electrical design, diagnostics and validation.

Why does the project use a state machine?

The process has mutually exclusive phases and defined transitions. A state machine gives one place ownership of each command, makes the normal order visible and provides a clear point for timeouts and faults. Independent latch networks can implement the same idea, but they often make conflicting ownership and recovery harder to inspect.

Why are command and feedback separate?

A command records what the controller requests; feedback records what the model or equipment reports. Setting feedback equal to command with no independent failure path makes a feedback test meaningless. The project can suppress simulated feedback so the controller must detect a commanded pump that did not respond.

How do I prove the PLC project works?

Execute the supplied 14 tests and record the initial condition, action, state sequence, commands, feedback, levels, timer behavior, fault code and result. Include ordinary stop/no-restart cases and negative reset tests, not only a successful normal cycle. Preserve the exact source and environment with the report.

Can I translate the project to ladder logic?

Yes, if you preserve behavior rather than translating syntax mechanically. Keep one state owner, command defaults, transition priority, one-shot Start/Reset requests, independent feedback, first-out diagnosis and the same acceptance tests. Vendor sequencer, latch and timer semantics must be verified on the target platform.

Can this become a home automation project?

Use it only as a learning model. Controlling a real garage door, water installation, heater, burner, access system or building circuit introduces people, property, codes, electrical interfaces and failure consequences that this tutorial does not address. Treat any real home automation application as a new engineered project, not a direct deployment of the trainer.

Sources and version boundary

This guide was researched and reviewed on 30 August 2026. Standards define useful boundaries, while the exact target manuals remain authoritative for implementation. Product availability, licenses, versions and hardware specifications can change.

• IEC 61131-3:2025 publication record — IEC
• IEC 61131-3 technical activity overview — PLCopen
• Software Construction Guidelines — PLCopen
• Recognizing an IEC 61131-3 programming system — PLCopen
• CODESYS Development System — CODESYS
• Task Configuration — CODESYS Online Help
• TON function block — CODESYS Standard Library
• OpenPLC Editor source and license — Autonomy Logic
• OpenPLC Editor v4.2.11 release record — Autonomy Logic
• OpenPLC Runtime source, architecture and quick start — Autonomy Logic
• OpenPLC Runtime v4.1.10 release record — Autonomy Logic
• OpenPLC Runtime security considerations — Autonomy Logic
• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security — NIST
• 29 CFR 1910.147 hazardous-energy control — OSHA
• 29 CFR 1910.333 electrical work practices — OSHA
• IEC 60204-1 machine electrical-equipment publication record — IEC

The downloadable source, equations, state diagram, test matrix and figures are original editorial artifacts produced for this guide. They are educational references, not a substitute for target manuals, qualified electrical work, a risk assessment or validated safety engineering.