Writing Your First PLC Program: Ladder Logic Starter Guide

Overview

Every first PLC program follows the same proven workflow, whether the controller is an AutomationDirect CLICK, a ProductivityOpen P1AM, or an entry-level Do-more BRX. The hardware is forgiving; the discipline is not. Engineers who skip the sequence-of-operations document and jump straight into ladder logic end up rewriting the program two or three times. This guide walks through the field-proven methodology that takes a blank project to a working machine, using the same checklist that a controls integrator would apply to a small home-shop project or a single-station production cell.

Prerequisites

Before opening the programming software, gather the following:

• Mechanical sketch – A dimensioned drawing of the machine, including actuator mounting, sensor locations, and the human operator's reach. A simple freehand sketch is fine for a home shop; production work requires a controlled drawing.
• Electrical schematic – Power distribution, fuse/breaker sizing, and the I/O wiring detail for every sensor and coil connected to the PLC.
• PLC platform selected – For a first project, the AutomationDirect CLICK series (C0-1x, C0-2x) is a common starting point with free CLICK programming software. See the CLICK PLC product page for current part numbers and the CLICK User Manual for hardware specs.
• Programming cable and software – USB or Ethernet depending on the platform; CLICK uses the free CLICK Programming Software v3.x and a USB-C cable for the C0-1x series.
• Spare inputs and outputs – Always allocate 20% spare discrete I/O for revisions and troubleshooting indicators.

Step 1 – Write the Sequence of Operations

The sequence-of-operations (SeqOps) document is the single most important artifact of any PLC project. Without it, the programmer is guessing. With it, the ladder logic writes itself.

A SeqOps for a small machine is usually a one-page table with five columns:

List every operator action, every interlock, and every fault condition that must drop the machine out of auto. The AutomationDirect community knowledge base article on PLC programming fundamentals reinforces the same point: a clear SeqOps with named I/O lets the program be written deterministically, regardless of who writes it.

Step 2 – Build the I/O Map

The I/O map is a fixed table that ties every PLC address to a real-world signal. Tag it with a name that matches the schematic so anyone can trace from code to wire. The table below is a typical template for a CLICK-series discrete I/O module.

Symbolic tag names eliminate the classic first-project mistake of writing to the wrong address three months later when no one remembers what X3 does.

Step 3 – Ladder Logic Building Blocks

Every first program uses the same five ladder primitives. Learn these and the rest is composition.

3.1 Examine-If-Closed (XIC) and Examine-If-Open (XIO)

The XIC contact is true when its bit is a logic 1. The XIO contact is true when its bit is a logic 0. In Allen-Bradley RSLogix 500 terminology these are --| |-- and --|/|--. In AutomationDirect CLICK the equivalents are STR (start, XIC) and STR NOT (XIO).

3.2 Output Energize (OTE)

The OTE coil turns its assigned bit on when the rung is true and off when false. Use it for non-retentive outputs that must drop out the instant the rung goes false.

3.3 Latch / Unlatch (OTL / OTU)

Use OTL/OTU pairs when a step must remain active after the input that started it drops out. Classic example: Start PB is momentary, but the machine must keep running until Stop PB, fault, or cycle-complete unlatches it.

3.4 Seal-In (Seal-Around) Contact

The classic seal-in pattern is the fundamental building block of any start-stop circuit:

|  PB_Start  PB_Stop  ES_OK  Motor_Run  |
|-------| |------|/|----|/|----|/|------( Y2 Motor_Run )------|
                              |                                   |
                              +-----------| |--------------------+ 

The Motor_Run XIC contact in parallel with PB_Start is the seal. It holds the rung true after the pushbutton is released. PB_Stop (N.C.) and ES_OK (N.C.) are wired in series; opening either one breaks the seal and drops the output. This is the first rung of essentially every PLC program ever written, and it is the one that should be mastered first.

3.5 Timer / Counter

Use a TON (on-delay) timer for dwell, debounce, or restart-inhibit timing. Address conventions differ by platform; CLICK uses the T data type with preset values in 100 ms increments, while ProductivityOpen uses _TIMER structures. See the CLICK User Manual, Chapter 6 for the exact instruction set.

Step 4 – Build a Simple State Machine

For any machine with more than two steps, a state machine beats a long ladder of seals. The simplest implementation is an integer tag (e.g., State) and one rung per state. Each state rung contains two parts: the permissives to enter the state, and the conditions to leave it.

For the CLICK platform, a SG (Stage) instruction is a built-in state-machine primitive. For ProductivityOpen P1AM-100, ladder with integer State and comparison instructions is more flexible. Either approach is acceptable; what is not acceptable is to encode states as a tangled web of non-overlapping seal-in rungs.

Step 5 – Add a Safety Routine

Even a home-shop machine deserves the following three rungs, in this order at the top of the program:

1. E-stop drop-out: any E-stop opening forces the machine into State = 0 or State = 40 via a normally-closed contact that overrides every seal.
2. Guard interlock: opening a guard door while a hazardous motion is in progress must either prevent start or de-energize the hazardous outputs immediately.
3. Fault latch: any unacknowledged fault must be latched into a FaultWord bit that survives a power cycle so the operator can see what happened.

Step 6 – Program Structure on a Multi-Task Controller

Once the program grows beyond about twenty rungs, split it into named tasks or subroutines. The ProductivityOpen P1AM-100 and Do-more BRX platforms support task-level prioritization; CLICK supports program files. A standard split is:

Putting the safety routine first guarantees that even if the state machine locks up, the E-stop still drops the outputs in the same scan.

Step 7 – Testing and Verification

Never trust untested ladder. Verify in this order:

1. Offline simulation. Most CLICK software versions and all Do-more Designer releases include a built-in simulator. Step through the SeqOps line by line and confirm each transition fires the right output.
2. Power-on bench test. With all actuators disconnected, watch the output LEDs on the PLC as you actuate each input. The output LED should follow the OTE coil truth table exactly.
3. Force-disable test. With the machine in a safe state, force the start input high in the software. The outputs should come on. Remove the force and they should drop. If they don't, the seal is wrong.
4. Single-cycle test. Run the machine through one full cycle, watching every limit switch and output LED in real time. Use the software's trend or data view to capture the scan-level behavior.
5. Fault-injection test. Trigger every documented fault (E-stop, guard open, timeout, overload) and confirm the machine enters the fault state and requires an explicit reset.

Document each test result in a one-page commissioning sheet. That sheet is your evidence that the machine was verified against the SeqOps.

Common First-Program Pitfalls

From First Program to Production Program

Once the home-shop program is working, the next three things to add before treating the code as production-grade are:

1. Comments on every rung – the rung comment should say in plain English what state the machine is in and what this rung does. Future you will thank you.
2. Revision history in the file header – date, author, change description. CLICK and ProductivityOpen both support free-form project notes; use them.
3. Backup of the program off the PLC – upload the project to a versioned directory on a PC or a Git repository. A PLC without a backup is a maintenance liability.

The first PLC program is rarely the last. Treat each revision as a learning artifact, document the changes, and the code will be portable to the next machine.