Why a Sample Project Beats Reading Reference Material Alone

Understanding what a normally open contact does, or what a TON timer instruction looks like, is necessary but not sufficient — real controls work is about the design process that turns a vague operational requirement ("the conveyor should run when it's needed and stop safely when there's a problem") into a working, commissioned system. This article walks through that full process end to end using one of the most common industrial automation projects there is: a single conveyor section with photoelectric sensors, a motor starter or VFD-driven motor, safety interlocks, and a simple sequencing requirement. Where the PLC Ladder Logic Programming guide covers the general building blocks (contacts, coils, timers, counters), this article is a standalone worked project showing how those building blocks actually get assembled, in order, on a real job.

Step 1: Define the Process — What Does This Conveyor Need to Do?

Before any I/O list or ladder logic, write down the actual operational requirement in plain language, because everything downstream depends on getting this right. For this project: a single conveyor section receives parts from an upstream process and delivers them to a downstream process. The conveyor should only run when the downstream station is ready to receive a part and the upstream station indicates a part is actually present and ready to be conveyed. A photoelectric part-present sensor confirms a part has arrived on this section. Two independent safety devices — an emergency stop pushbutton and a guard door interlock switch — must be able to stop the conveyor immediately regardless of what the sequencing logic is doing. Finally, if a part gets photoelectrically detected but never clears the section within a reasonable time, the system should flag a jam condition and stop, rather than running indefinitely against a stuck part.

Notice this requirement makes no mention yet of PLC addresses, timer preset values, or rung numbers — that's deliberate. Nailing down the plain-language requirement first, and getting it reviewed by whoever actually operates the equipment, catches misunderstandings while they're still cheap to fix, long before they're buried inside logic that takes an afternoon to untangle.

Step 2: Build the I/O List Before Writing Any Logic

With the process defined, the next step — and the one most often skipped by less experienced programmers eager to start writing rungs — is building a complete I/O list. Every physical input and output the system needs gets a plain-English description and a proposed PLC address, before a single rung is written. For this conveyor:

  • Digital Inputs: Part-Present Photoelectric Sensor (part detected on this section), Downstream-Ready Permissive (from the next station, indicating it can accept a part), Upstream-Part-Available (from the prior station), E-Stop Pushbutton (NC contact, wired so the input reads "healthy" when the circuit is intact — critical for fail-safe design), Guard Door Interlock Switch (NC contact, same fail-safe principle), Motor Overload Trip (NC contact from the motor starter or VFD fault relay), Reset Pushbutton (to clear a latched jam or fault condition).
  • Digital Outputs: Conveyor Motor Run (to the motor starter coil, or the VFD's run/enable input), Jam Fault Indicator Light, Motor Running Pilot Light, Fault Horn/Alarm (optional).
  • Analog (if VFD-driven): Speed Reference output (4–20mA or 0–10V to the VFD) if the application needs variable speed rather than a fixed-speed motor starter — a straightforward across-the-line motor starter is sufficient for many simple conveyor sections and skips this analog point entirely.

Building the I/O list first accomplishes two things: it forces you to think through every physical device the system actually needs before getting distracted by logic details, and it becomes the document the electrical designer uses to size the I/O module, wire the panel, and assign terminal numbers — feeding directly into the wiring diagram and the panel's physical build, well before the PLC program exists in any form.

Step 3: Sketch the Sequence of Operations in Plain Language

With the I/O list settled, write the sequence of operations as a numbered list of plain-English steps — still no ladder logic yet. This step catches logical gaps (what happens on a jam? what resets it?) far more cheaply than discovering them while debugging rungs on the panel floor:

  1. System is in Idle. Conveyor motor is off. Jam fault is not active.
  2. When Upstream-Part-Available AND Downstream-Ready are both true, AND no fault is active, AND all safety interlocks (E-Stop, Guard Door) are satisfied, energize the Conveyor Motor Run output.
  3. Start a jam-detection timer the instant the Part-Present sensor first detects a part on this section.
  4. If the Part-Present sensor clears (the part successfully moves off this section) before the jam timer expires, reset the timer and return to Idle, ready for the next part.
  5. If the jam timer reaches its preset while Part-Present is still true (the part hasn't cleared in the expected time), de-energize the Conveyor Motor Run output immediately, latch a Jam Fault condition, and energize the Jam Fault Indicator.
  6. If E-Stop is pressed or the Guard Door opens at any point, de-energize Conveyor Motor Run immediately regardless of sequence step — this condition overrides everything else in the sequence, exactly as described for a hardware interlock chain.
  7. A latched Jam Fault (or a safety-interlock stop) requires an operator to physically clear the jam and press Reset before the sequence can return to Idle and resume normal operation. The system should never auto-clear a jam fault on its own.

Writing the sequence this way — as numbered, testable statements — makes it straightforward to translate directly into rungs in the next step, and it's also exactly the document an operator, maintenance technician, or the commissioning team will want to review and sign off on before the system goes live.

Step 4: Translate the Sequence to Ladder Logic

Only now, with the I/O list and sequence of operations settled, does actual rung-by-rung ladder logic get written. A simplified version of the core rungs for this conveyor:

Rung — Safety Permissive: E-Stop (NC contact) in series with Guard Door Interlock (NC contact) in series with Motor Overload (NC contact), driving an internal "Safety_OK" bit. Because all three are wired as NC contacts feeding one series chain, any single one tripping breaks Safety_OK immediately — the same series-interlock principle used in hardware relay schematics, just implemented as PLC logic here (see How to Read a Control Schematic for the hardware-relay version of this exact pattern).

Rung — Run Permissive: Safety_OK (NO contact, internal bit) in series with Upstream-Part-Available in series with Downstream-Ready in series with a NOT-Jam-Fault contact, driving the Conveyor Motor Run coil directly (a simple fixed-speed application) or an internal "Run_Command" bit feeding the VFD's enable and speed reference logic.

Rung — Jam Timer: Part-Present Sensor (NO contact) drives a TON (Timer On Delay) instruction with a preset matched to the longest expected normal transit time across this section, plus margin — for example, if a part normally clears the section in 8 seconds, a preset of 15–20 seconds gives margin without letting a genuinely jammed part run indefinitely.

Rung — Jam Fault Latch: The jam timer's .DN (done) bit, in series with the Part-Present sensor still being true (confirming the part genuinely never cleared, rather than the timer simply finishing after a normal cycle), drives a latch (SET) coil for the Jam_Fault bit. A separate rung with the Reset pushbutton drives the corresponding unlatch (RESET) coil — the classic set/reset pair for capturing and later clearing a fault condition.

Rung — Fault Indication: Jam_Fault bit drives the Jam Fault Indicator output and, optionally, an alarm horn — giving the operator immediate, unambiguous feedback about which condition stopped the conveyor.

Step 5: Handling the Jam-Detection Timeout Correctly

A subtle but important detail: the jam timer must be reset (not just left to time out and restart on its own) the moment Part-Present clears normally, so that the next part entering the section gets a fresh, full timing window rather than inheriting whatever time happened to be left on a timer that never fully reset. This is exactly why the sequence-of-operations step explicitly called out resetting the timer on a normal part transit (step 4 above) — a detail that's easy to miss once you're deep in rung-by-rung logic but obvious once it's written out as a plain-language requirement first.

Step 6: Commissioning and Testing — Forcing I/O Safely

Before running the full automatic sequence for the first time, verify wiring and I/O independently of the sequencing logic using controlled forces — the same technique covered in depth in our PLC Troubleshooting Guide. With the conveyor motor's power disconnect physically open or the motor otherwise mechanically isolated, force each digital input on the bench to confirm the correct bit changes in the processor, and force each output on to confirm the correct field device (or a test light in place of it) actually energizes — this validates every point on the I/O list before any of it depends on the sequencing logic being correct.

Only once every individual I/O point is confirmed wired correctly should you remove all forces (checking the processor's forces-active indicator to confirm none remain — a fault this commissioning check exists specifically to prevent) and test the sequence with the actual motor able to run, starting with a single manual test part and observing every transition: does the jam timer actually clear on a normal part transit, does E-Stop actually kill the motor immediately, does Guard Door do the same, and does the Reset button actually clear a deliberately induced jam fault. Test the failure paths deliberately — pull the E-stop mid-cycle, open the guard door mid-cycle, hold a test part in place past the jam preset — rather than only ever testing the happy path where nothing goes wrong, since those failure paths are exactly the ones a real operator will eventually encounter in production.

Where to Go From Here

This same design process — plain-language requirement, then I/O list, then sequence of operations, then ladder logic, then safe commissioning with forced I/O — scales up to far larger and more complex automation projects; only the number of I/O points and sequence steps grows. For the general reference on the ladder logic instructions used to implement any of these rungs, see the PLC Ladder Logic Programming guide; for the diagnostic hierarchy to follow once this system is running in production and something misbehaves, see the PLC Troubleshooting Guide and the PLC Scan Cycle concept explainer. For more on the photoelectric and other sensor types referenced in this project's I/O list, see the Automation Sensors Guide.