Ladder Logic Examples: 17 Programs, Traces and Tests

What are the best ladder-logic examples for beginners?

Start with a motor seal-in circuit, then add permissives, feedback timeout, alarm latching, timers, counters and a small state sequence. Those patterns recur in conveyors, pumps, packaging machines and process skids. The most useful examples include normal operation, abnormal inputs, reset behavior and a test table—not only a screenshot of one rung.

The examples below use vendor-neutral ladder notation:

| |   normally open contact
|/|   normally closed instruction
( )   non-retentive output coil
(L)   latch/set coil
(U)   unlatch/reset coil
TON   on-delay timer
CTU   count-up counter
OSR   one-scan rising-edge pulse

Adapt instruction names, timer time bases and address syntax to your PLC. Read how ladder logic executes during the scan before copying a pattern.

The saved production queue records 920 global and 380 United States monthly searches for ladder logic example at KD 35. This existing article owns pattern breadth across many applications. The ladder tutorial owns the complete language-learning path, the ladder program owner owns a single end-to-end program architecture, and the practice exercises own graded problems and full solutions. Keeping those tasks separate prevents a second examples list from competing with this canonical.

Choose an example from the behavior you need to prove:

Requirement	Start with	State that must be visible	First negative test
hold a motor request after a momentary Start	three-wire seal-in	request, permissive and final command	Stop and Start true in the same scan
detect command without physical response	feedback timeout	command, proof, elapsed state and first-out	feedback arrives at the exact timeout boundary
retain an output briefly after demand ends	off-delay or explicit state	demand, delayed state and current permissives	trip occurs during delayed run-on
count products	one-shot plus counter	raw sensor, edge pulse and accumulated count	input remains true for multiple scans
control between low and high thresholds	hysteresis/set-reset state	measured value, quality and request	bad signal while request is retained
coordinate several steps	explicit state sequence	current state, transition cause and timeout	expected proof never arrives
arbitrate manual and automatic requests	one accepted request and one output owner	mode, each request and accepted command	mode changes while a request is held
diagnose a jam	commanded motion plus missing progress	command, run proof, product progress and timer	conveyor stops normally during timing

Before drawing rungs, write the I/O contract. This small contract applies to the motor and conveyor examples:

Signal	Meaning	Valid/abnormal rule	Why it is separate
StartPB	normalized momentary ordinary-control request	true only while the mapped input is accepted	a request is not a retained state
StopHealthy	ordinary stop circuit healthy	false dominates Start	name describes engineering meaning, not symbol artwork
MotorRequest	accepted retained request	drops on stop, inhibit or fault policy	internal state is not the physical output
MotorCmd	one final ordinary command	requires current permissives	provides one output owner
MotorRunFb	validated starter/drive feedback	must not be inferred from command	proves the controlled device reported response
ProductEye	raw/filtered product presence	quality and debounce policy defined	level may span many scans
ProductPulse	one accepted product edge	one scan/task event	counter must count events, not scan duration
FirstOutCode	initiating fault identity	first nonzero cause retained until valid reset	later symptoms must not erase origin

1. Three-wire motor start/stop

Goal: A momentary Start button runs a motor until Stop or an overload permissive opens.

Rung 1 — Motor command
|--|/| StopPB --| | OverloadOK --+--| | StartPB ----( MotorCmd )--|
|                                  |
|                                  +--| | MotorCmd --|

Rung 2 — Physical output
|--| | MotorCmd --|/| SafetyTrip --( MotorContactor )--|

Truth table:

Stop healthy	Overload healthy	Start pressed	Prior MotorCmd	Next MotorCmd
1	1	1	0	1
1	1	0	1	1
0	1	either	1	0
1	0	either	1	0

Important: StopPB in this pseudocode represents the normalized “stop circuit healthy” condition. The field device, input polarity and safety architecture must be documented separately. An ordinary PLC input is not an emergency-stop safety function.

See the complete motor start/stop ladder tutorial for wiring and commissioning context.

2. Motor feedback timeout

Goal: Alarm when the PLC commands a motor but auxiliary feedback does not arrive within three seconds.

|--| | MotorCmd --|/| MotorRunFb --------[TON StartFbTimer 3s]--|
|--| | StartFbTimer.DN -------------------(L) FailedToStart ----|
|--| | ResetPB --|/| MotorCmd --| | MotorRunFb --(U) FailedToStart --|

The reset rung requires the command to be off and feedback to match the stopped condition. This avoids clearing a fault while its cause remains.

Test:

• Command plus feedback in 1 s → no alarm.
• Command with no feedback for 3 s → FailedToStart latches.
• Feedback arrives after alarm → alarm remains until the documented reset condition.
• Feedback is already on before start → flag a separate “unexpected running” condition.

3. Conveyor off-delay after the last product

Goal: Keep a conveyor running for five seconds after a photo-eye clears.

|--| | AutoMode --| | ProductPresent ----( ConveyorDemand )--|
|--|/| ProductPresent --------------------[TOF ClearDelay 5s]--|
|--| | AutoMode --+--| | ConveyorDemand --+--( ConveyorCmd )--|
|                 |                      |
|                 +--| | ClearDelay.Q ----+

Use feedback and jam detection before treating ConveyorCmd as proof of movement. For a broader design, read the conveyor-belt PLC programming guide.

4. Tank fill with hysteresis

Goal: Start a fill valve at 30% level and stop at 80%.

|--[LES LevelPct 30.0] --| | AutoMode ----(L) FillRequest --|
|--[GRT LevelPct 80.0] -------------------(U) FillRequest --|
|--| | FillRequest --|/| LevelBad --|/| HighHigh --( FillValve )--|

Separate high-high protection from normal control. The above is process logic only; hazardous overflow may require independent protection.

5. Duty/standby pump alternation

Goal: Alternate the lead pump after each completed cycle while allowing one available pump to run if the other is faulted.

|--| | CycleComplete --[OSR CyclePulse] ----( ToggleLead )--|

Pump1Request :=
    Demand AND (
        (LeadIsPump1 AND Pump1Available)
        OR NOT Pump2Available
    );

Pump2Request :=
    Demand AND (
        (NOT LeadIsPump1 AND Pump2Available)
        OR NOT Pump1Available
    );

In ladder, implement the equations with branches and document what happens if neither pump is available. Do not toggle lead on a scan-level completion bit without a one-shot.

6. One-shot production counter

Goal: Count each product once even if the sensor stays on for multiple scans.

|--| | ProductEye --[OSR ProductPulse] --[CTU ProductCount 100]--|
|--| | ProductCount.DN ------------------( BatchQuantityReached )--|
|--| | NewBatchPB --|/| ConveyorRunning -[RES ProductCount]--|

Test with a long pulse, sensor chatter and power cycle. Decide whether the accumulated value must be retentive.

7. Alarm latch with acknowledge and reset

Goal: Preserve a transient fault, acknowledge operator awareness, and reset only after the condition clears.

|--| | HighTempCondition -----------------(L) HighTempAlarm --|
|--| | AckPB --| | HighTempAlarm ---------(L) HighTempAcked --|
|--| | ResetPB --|/| HighTempCondition ---(U) HighTempAlarm --|
|--| | ResetPB --|/| HighTempCondition ---(U) HighTempAcked --|

Acknowledgment is not reset. The alarm remains active while the process condition remains active.

8. Permissive and interlock summary

Goal: Explain why a pump will not start and why it stopped.

StartPermissive :=
    AutoMode
    AND SourceLevelOK
    AND DestinationAvailable
    AND PumpAvailable;

RunInterlock :=
    NOT LowSuctionPressure
    AND NOT MotorOverload
    AND NOT SealFault;

PumpCmd := Demand AND StartPermissive AND RunInterlock;

Expose each input and a combined permissive/interlock state to the HMI. A generic “start failed” message wastes troubleshooting time.

9. Analog input scaling with quality

Goal: Convert a raw 4–20 mA input to 0–100 °C and reject a bad signal.

SignalGood := (RawAI >= RawLowValid) AND (RawAI <= RawHighValid);

IF SignalGood THEN
    TemperatureC :=
        (REAL(RawAI - RawAt4mA) / REAL(RawAt20mA - RawAt4mA))
        * 100.0;
ELSE
    TemperatureC := LastGoodTemperatureC;
    TemperatureBad := TRUE;
END_IF;

Implement the calculation in the target PLC’s available math instructions or a reusable block. Never let a substituted last-good value look like healthy live data. Use the analog scaling calculator to verify two test points.

10. High-high trip voting

Goal: Demonstrate two-out-of-three process voting as an educational control pattern.

TwoOfThreeHigh :=
    (HighA AND HighB)
    OR (HighA AND HighC)
    OR (HighB AND HighC);

This Boolean example does not establish a safety integrity level or replace the required sensor diagnostics, proof testing, independence and safety lifecycle.

11. Traffic-light state sequence

Goal: Use states rather than interdependent timer-done bits.

NS_GREEN → NS_YELLOW → ALL_RED_1
         → EW_GREEN → EW_YELLOW → ALL_RED_2
         → NS_GREEN

Output decode:

NsGreen := State = NS_GREEN;
NsYellow := State = NS_YELLOW;
NsRed := NOT (NsGreen OR NsYellow);

EwGreen := State = EW_GREEN;
EwYellow := State = EW_YELLOW;
EwRed := NOT (EwGreen OR EwYellow);

See the complete traffic-light state-machine example for code, limitations and acceptance tests.

12. Batch mixer phase sequence

Goal: Coordinate dose, mix, heat/hold and transfer.

VERIFY_READY → TARE → DOSE_A → DOSE_B
→ START_AGITATOR → HEAT → HOLD → TRANSFER → COMPLETE

Each phase exposes Ready, Running, Complete, Faulted and actual process values. Transition on measured completion rather than elapsed time alone. The batch-process PLC programming guide contains the full example.

13. Packaging reject register

Goal: Track a failed inspection from the sensor to a downstream reject station.

At each encoder/index pulse:
RejectRegister[5] := RejectRegister[4];
RejectRegister[4] := RejectRegister[3];
RejectRegister[3] := RejectRegister[2];
RejectRegister[2] := RejectRegister[1];
RejectRegister[1] := RejectRegister[0];
RejectRegister[0] := InspectionFail;

RejectSolenoid := IndexPulse AND RejectRegister[5];

Production code must define missed indexes, double-detection, conveyor slip, reject confirmation and register recovery after a stop.

14. Star-delta training sequence

Goal: Teach mutually exclusive contactor commands.

MainCmd  := MotorRequest AND AllPermissives;
StarCmd  := MainCmd AND NOT TransitionTimer.Q AND NOT DeltaFeedback;
DeltaCmd := MainCmd AND TransitionTimer.Q AND NOT StarFeedback;

Actual starters require correctly engineered power circuitry, mechanical/electrical interlocking, motor suitability and protection. Do not build a motor starter from PLC logic alone.

15. Manual/automatic command arbitration

Goal: Ensure one final command owner.

AutoRequest   := AutoMode AND SequenceCallsMotor;
ManualRequest := ManualMode AND ManualStartPB;

MotorRequest :=
    (AutoRequest OR ManualRequest)
    AND NOT ModeConflict
    AND CommonPermissives;

Manual mode should not bypass safety functions or essential equipment protections. Define whether process interlocks remain active in manual operation.

16. First-scan initialization

Goal: Initialize nonretentive control state without energizing equipment unexpectedly.

|--| | FirstScan ----------------( State := STOPPED )--|
|--| | FirstScan ----------------(U) AutoRestartRequest --|
|--| | FirstScan ----------------[RES TemporaryTimers]--|

Do not reset legitimate retained production totals or recipe data blindly. Document retention variable by variable.

17. Jam detection

Goal: Detect a commanded conveyor with no downstream product movement.

|--| | ConveyorRunFb --| | ProductExpected --|/| ExitEyePulse
|----------------------------------------[TON JamTimer 4s]--|
|--| | JamTimer.DN ----------------------(L) ConveyorJam --|
|--| | ConveyorJam ----------------------( ConveyorStopRequest )--|

Set the timer from the maximum legitimate travel time plus margin, not from guesswork. Pause or reset it under every documented mode change.

Why scan order matters

PLCs normally read inputs, execute logic and update outputs cyclically. A tag written on an earlier rung can affect a later rung in the same scan; a physical output may not change until output update.

Trace one motor example scan by scan

The following trace uses normalized inputs and an illustrative program order: first compute a rising Start pulse, then update retained request, then compute the final command, then execute the feedback timeout. The physical output and feedback may update on different boundaries. Replace the illustrative rows with observations from the exact runtime.

Scan	Start	Stop healthy	Start pulse	prior request	next request	command	feedback	timeout/fault
100	0	1	0	0	0	0	0	reset / none
101	1	1	1	0	1	1	0	timing starts
102	1	1	0	1	1	1	0	timing continues; held Start is not another event
103	0	1	0	1	1	1	1	timeout resets; running proof accepted
104	1	0	1	1	0	0	1 then field-dependent	stop dominates; no new request
105	0	1	0	0	0	0	0	stopped; a new Start edge is required

This trace prevents three common mistakes. First, a held Start does not generate repeated rising edges. Second, Stop priority is a tested equation rather than a visual assumption. Third, MotorCmd = 0 and MotorRunFb = 1 can coexist briefly while a starter or drive decelerates; decide whether that is normal stopping or a feedback-stuck diagnostic using the equipment requirement.

Download the ladder-example I/O and state contract and scan-trace worksheet.

Translate the examples instead of transliterating mnemonics

The Boolean purpose can be portable while syntax and state are not. Rebuild each example in the target project and test it; do not replace a tag spelling and assume equivalent execution.

Concept in this article	Rockwell Logix example	Siemens S7-1200/1500 example	CODESYS/IEC-style example	Mitsubishi/Omron boundary
true/false contact	XIC / XIO presentation	normally open/closed contact in LAD	contact in LD	vendor device/label and contact instructions differ
ordinary output	OTE	assignment coil	coil	direct, set/reset and output-refresh ownership must be checked
rising edge	ONS/OSR by platform	R_TRIG or supported positive edge	R_TRIG instance	Mitsubishi pulse instructions and Omron DIFU/edge forms are target-specific
on-delay	TON timer structure/tag	IEC TON instance	Standard TON FB instance	Mitsubishi time base/instruction and legacy Omron BCD/binary operands differ
count up	CTU structure	IEC CTU instance	Standard CTU FB	input-edge, reset and representation must be reverified
latch/set-reset	OTL/OTU or state equation	S/R coils or state assignment	SR/RS or explicit state	priority and startup/retention are not portable by mnemonic
state sequence	tag/UDT/AOI/project convention	FB/FC/DB and state value	program/FB with enum or integer	device/step/label architecture and task execution differ

Check the target documentation for instruction availability in the chosen language, instance allocation, operand types, skipped-call behavior, multiple writers, prescan or first-cycle behavior, retained memory and online-edit consequences. The examples deliberately use descriptive names; mapping them to raw devices is an engineering step, not a formatting step.

Use one state writer and one physical-output owner

Multiple output coils or state writers can make a rung screenshot look right while a later network changes the result. Cross-reference every direct coil, latch/unlatch, assignment, move, indexed write, HMI device test and I/O refresh that can reach the final output. Resolve manual and automatic sources before the final command:

AcceptedMotorRequest :=
    ((AutoMode AND AutoMotorRequest)
     OR (ManualMode AND ManualMotorRequest))
    AND NOT ModeConflict;

MotorCmd := AcceptedMotorRequest
            AND StopHealthy
            AND MotorAvailable
            AND NOT FirstOutActive;

This is an ordinary-control pattern. Manual mode does not imply bypassing essential equipment interlocks or any safety function. If the requirement allows a maintenance override, represent its authorization, scope, duration, indication and audit trail explicitly.

Reproducible practice project

Combine examples 1, 2, 3, 6 and 7:

1. Start/stop a conveyor motor.
2. Require run feedback within three seconds.
3. Count ten products with a one-shot.
4. Keep the conveyor running five seconds after the tenth product.
5. Latch a start-failure or jam alarm.
6. Require the cause to clear before reset.

Acceptance tests

ID	Injected condition	Expected result
L01	Normal start and feedback	Motor runs; no alarm
L02	Start without feedback	Failed-to-start alarm after 3 s
L03	Product eye stays on for 1 s	Count increases once
L04	Ten valid product pulses	Batch quantity bit turns on
L05	No exit pulse while movement expected	Jam alarm after defined time
L06	Press reset while cause remains	Alarm does not reset
L07	Stop during timing	Output turns off and timers follow documented behavior
L08	Power cycle with request present	No unintended restart
L09	Start and Stop become true together	Stop-dominant result; command remains off
L10	Feedback arrives at timeout boundary	documented proof-versus-timeout priority is observed
L11	Product eye remains true for ten scans	exactly one accepted product count
L12	Product-eye chatter around one item	result matches filter/debounce requirement; no invented items
L13	Manual request held while mode changes to Auto	no transition-generated start or dual output owner
L14	Analog input reports bad quality	process value is marked bad; no silent healthy last-good value
L15	Sequence enters undefined state	outputs follow declared fail response; diagnostic identifies invalid state
L16	Cause remains while Reset is pressed	first-out and inhibited state remain

Save the I/O list, ladder screenshot, truth table and test results. That evidence is more useful than claiming the program “works.”

Download the 16-case ladder-example acceptance matrix. Retain target model, firmware, programming-software version, project checksum, initial state, stimulus, expected result, observed result and reviewer with every run.

Debug a ladder example from the first failed boundary

When an example does not work, avoid rewriting the rung immediately. Compare expected and observed behavior from left to right:

Symptom	First evidence to inspect	Likely boundary	Do not assume
rung never becomes true	mapped input/tag and normalized polarity	I/O mapping, quality, force or upstream state	contact instruction is broken
request becomes true but command stays false	every permissive, inhibit and first-out input	arbitration or command gate	physical output has failed
command is true but output terminal is inactive	output image, force/test list, module status, common and supply	mapping, module or electrical circuit	green rung proves voltage
output is active but feedback stays false	starter/drive status, field wiring and proof mapping	controlled-device or feedback path	increase timeout indefinitely
counter increments repeatedly	raw sensor and one-shot memory over several scans	missing/mis-scoped edge instance	counter preset is wrong
timer finishes early or late	instruction, unit, task/call and duplicate owner	time base, scan/call or preset conversion	every timer uses milliseconds
state jumps over a step	transition order and competing writers	simultaneous conditions or program order	state machine is nondeterministic by nature
fault disappears before maintenance sees it	latch/first-out/reset ownership	diagnostic state model	acknowledgment and reset are the same
behavior changes after restart	retention, initialization and first-scan code	undocumented startup contract	the simulator and controller initialize identically

Use online monitoring as evidence, not as authorization to force or edit. Record temporary states, control hazardous energy as applicable, keep actuators in a controlled condition and verify every force/device test/bypass is cleared before handoff.

Ladder-logic example answer map

Question	Concise answer	Boundary
What is the best first ladder example?	A stop-dominant motor seal-in with command/feedback separation and tests.	Ordinary control is not emergency stopping.
How do I read a ladder rung?	Evaluate series conditions as AND and valid parallel branches as OR from left to right under the target scan model.	Symbols display logical tests, not necessarily physical contact state.
How do I make Start hold after release?	Place the retained request contact in parallel with momentary Start while Stop/permissives stay in series.	Test simultaneous Start/Stop and restart.
How do I count one product once?	Convert the sensor transition to one accepted rising-edge pulse, then count the pulse.	Define chatter/filter and restart behavior.
How do I detect a motor that failed to start?	Time MotorCmd AND NOT MotorRunFb; fault if proof misses the approved deadline.	Command echo is not physical proof.
Why does ladder rung order matter?	An internal value written earlier may be read later in the same scan.	Physical I/O refresh can occur on another boundary.
Can I use two coils for one output?	Prefer one final owner after explicit request arbitration.	Cross-reference indirect and external writes too.
Should a sequence use many cascaded timers?	Prefer explicit states with timers as transition guards and sensors as completion evidence.	A timer cannot prove physical motion.
What should Manual mode bypass?	Only what the approved design explicitly permits; never infer that Manual bypasses protection or safety.	Authorization and indication remain required.
How do I prove a ladder example works?	Run normal, boundary, simultaneous, interruption, restart and fault-injection tests with observed evidence.	Simulator evidence is limited to its declared model.

Frequently asked questions

What is a simple ladder-logic example for a beginner?

Use a momentary Start, a normalized stop-healthy condition, one retained motor request and one final command. Add a separate running feedback and a timeout only after the basic stop-dominant truth table passes. This teaches contacts, coils, state, scan behavior and diagnosis without hiding them inside a large machine.

How do parallel branches work in ladder logic?

Parallel branches represent alternative true paths, similar to Boolean OR. Series contacts on any branch still all need to evaluate true. A seal-in branch should bypass only the momentary Start contact; stop and essential permissives stay in series with every holding path.

Why is a normally closed ladder instruction not always a normally closed field contact?

The ladder instruction tests a stored Boolean value. The field device's electrical contact type, input wiring, module channel and program normalization determine what that value means. Use names such as StopHealthy and retain the electrical drawing rather than inferring wiring from the on-screen symbol.

How do I make Stop dominant over Start?

Express and test the priority: if StopHealthy is false, the next request and final command are false even when Start is true. Keep Stop outside the Start/seal branch and include a simultaneous Start/Stop acceptance case. Program order and later writers still need review.

Why should command and feedback be separate?

Command states what the PLC asks; feedback states what the controlled device reports. Keeping them separate lets the program diagnose failed start, unexpected running and slow stopping. Copying command into feedback makes the diagnostic pass without proving any physical response.

How do I prevent a PLC counter from counting every scan?

Create one edge pulse per accepted sensor transition and feed that event to the counter according to the exact instruction semantics. Test a held input and chatter. On platforms with instance-based edge blocks, give every event stream independent instance memory.

Can I copy these ladder examples into any PLC?

No. The requirements and Boolean patterns are portable teaching material, but instruction names, instances, operands, time representation, scan/call behavior, prescan/startup, retention, I/O mapping and online operations vary. Reimplement and test in the exact vendor environment.

What is the difference between a permissive and an interlock?

Terminology varies by organization, but a useful design separates conditions required to accept a start from conditions monitored while running. Name every condition and its response rather than relying on the labels alone. Safety functions remain a distinct engineered layer.

Should a timer directly energize an output?

Usually use the timer's completion as one state or command condition, then recheck current permissives at the final output owner. If the timer's original enable or an essential condition disappears, a stale done bit must not keep an actuator on unintentionally.

How do I test a ladder-logic example in a browser?

Declare inputs and initial state, run one stimulus at a time, observe scan/state/output evidence and compare with an acceptance matrix. A browser learning model is useful for logic reasoning but does not validate a vendor project, task scheduler, electrical I/O, machine, process or safety function.

What should happen after a PLC power cycle?

The approved restart narrative must define each retained request, state, timer, counter, alarm and output. A conservative ordinary machine default often requires a new start request, but the real process and risk assessment control. Test CPU stop/run and power interruption on approved equipment.

Can ladder logic implement an emergency stop?

An ordinary PLC example cannot establish an emergency-stop safety function. Required safety performance needs a risk-assessed architecture, suitable safety-rated devices/controller/I/O and final elements, controlled software, fault testing and measured validation of the complete installed function.

Primary sources and technical review trail

Reviewed 31 August 2026. The six responsive figures are original editorial illustrations. They explain logic and testing; they are not vendor screenshots, wiring drawings, electrical designs or safety evidence.

• IEC 61131-3:2025 publication record — current programming-language standard scope.
• CODESYS LD programming-language reference — current Ladder Diagram editor/language behavior.
• CODESYS Standard library index — current TON, TOF, TP, CTU and trigger block references.
• CODESYS R_TRIG reference — instance-based rising-edge behavior.
• Rockwell Automation Logix discrete instruction index — XIC, XIO, OTE, OTL, OTU and one-shot families.
• Rockwell Automation Logix timer/counter instruction index — target-specific timer/counter references.
• Siemens S7-1200 V20 basic instructions — contacts, coils, edge, timer and counter documentation entry point.
• Siemens S7-1200 V20 IEC timers — TP, TON, TOF and TONR boundaries.
• Mitsubishi MELSEC iQ-F FX5 instruction manual JY997D55801 AB — current instruction, timer and output behavior.
• Mitsubishi MELSEC iQ-F program-design manual JY997D55701 M — program, label, device and retention context.
• Omron NJ/NX Instructions Reference Manual W502 — LD instructions, timers, counters and edges for the stated platform.
• Schneider Electric Machine Expert Standard library — current standard function-block entry point.
• NIST SP 800-82 Rev. 3 — operational-technology change and security boundary.
• OSHA control of hazardous energy — maintenance/commissioning energy-control context where applicable.
• ISO 13849-1:2023 publication record — machinery control-system safety-related parts scope.

Vendor documentation, the approved controls narrative, electrical drawings, risk assessment and site procedures take precedence over these independent teaching examples.

Practise the examples in a browser

PLC Simulation Software provides interactive ladder-logic scenarios for motor control, conveyors, traffic lights, batch mixing and other sequence exercises.

Ownership disclosure: PLC Programming and PLC Simulation Software are operated by the same publisher. The simulator is a training environment, not a vendor PLC runtime or a safety controller.

Start the free PLC simulator, reproduce L01–L08 and then reimplement the same behavior in your target vendor software.

Safety and implementation limits

• Never treat ordinary PLC logic as an emergency-stop or required safety function.
• Verify input polarity against electrical drawings.
• Use output feedback where commanded state is not sufficient.
• Define power-up, stop, fault and reset behavior.
• Validate timer units and retentive behavior on the target PLC.
• Use vendor manuals for instruction edge cases.
• Test with isolated simulation or approved commissioning procedures before connecting actuators.

Key takeaways

• Start with one simple rung and add one requirement at a time.
• Use readable tags and expose permissives.
• Count edges, not scans.
• Separate state transitions from outputs.
• Measure physical completion instead of trusting commands or time alone.
• Treat acknowledgment and reset as different actions.
• Prove every example with a small acceptance-test table.

Related ladder-logic resources

• Ladder logic tutorial
• Ladder logic symbols
• PLC timer programming
• Structured Text programming
• PLC programming practice exercises
• How to program a PLC step by step