Ladder Logic Complete Guide: Master Industrial Programming

historyHistory of Ladder Logic

Ladder logic programming has its roots in electrical relay control systems that dominated industrial automation before the advent of programmable controllers. In the 1960s, automotive manufacturers needed a more flexible alternative to hardwired relay panels that required extensive rewiring for production changes.

In 1968, General Motors issued a specification for a programmable controller, leading to the development of the first PLC by Modicon (Model 084). The programming language needed to be familiar to plant electricians who understood relay ladder diagrams, so ladder logic was born as a graphical representation of relay control logic.

foundationLadder Logic Fundamentals

Ladder logic programs consist of rungs arranged between two vertical power rails, resembling a ladder. Each rung represents a control statement, and power flows from left to right when conditions are met.

The Anatomy of a Rung

Left Rail    Input Logic         Output      Right Rail
   |                                          |
   |------[ ]------[ ]-------( )--------------|
   |                                          |

Components:
- Left Rail: Represents positive power supply
- Input Logic: Contacts that must be TRUE for power flow
- Output: Coil that energizes when power flows through
- Right Rail: Represents negative/ground return

Power Flow Concept

Understanding power flow is essential to ladder logic. Power flows from the left rail through contacts (inputs) to coils (outputs) and returns to the right rail. For an output to energize, there must be a continuous path of TRUE conditions from left to right.

Series (AND Logic):
|--[ A ]--[ B ]--( Output )--|
Output is TRUE only when A AND B are both TRUE

Parallel (OR Logic):
|--[ A ]--+
          |--( Output )--|
|--[ B ]--+
Output is TRUE when A OR B is TRUE

Combined Logic:
|--[ A ]--[ B ]--+
                 |--( Output )--|
|--[ C ]--[ D ]--+
Output = (A AND B) OR (C AND D)

electrical_servicesContacts and Coils Deep Dive

Contacts and coils are the building blocks of ladder logic. Mastering their behavior and proper usage is fundamental to creating reliable control programs.

|--[ StartButton ]--( Motor )--|

|--[/EmergencyStop]--( Motor )--|

|--[ Input ]--( OutputCoil )--|

|--[ Start ]--( L Motor )--|
|--[ Stop ]---( U Motor )--|

BAD - Do Not Do This:
|--[ A ]--( Motor )--|
|--[ B ]--( Motor )--|  <- Last scan wins!

GOOD - Use This Instead:
|--[ A ]--+
          |--( Motor )--|
|--[ B ]--+

timerTimer Instructions

Timers are essential for controlling time-dependent operations. Modern PLCs support three main timer types, each suited for specific applications.

|--[ StartButton ]--[TON Timer1]--|
                     Preset: T#5s
                     Elapsed: T#0s
                     Done: FALSE

|--[Timer1.Done]--( Light )--|

Operation:
- Press StartButton: Timer begins counting
- After 5 seconds: Timer1.Done goes TRUE
- Release StartButton: Timer resets immediately

|--[ Sensor ]--[TOF Timer2]--|
                Preset: T#10s

|--[Timer2.Q]--( Fan )--|

Operation:
- Sensor TRUE: Fan runs immediately
- Sensor FALSE: Fan continues for 10 more seconds
- After 10s: Fan stops

|--[ TriggerButton ]--[TP Timer3]--|
                       Preset: T#2s

|--[Timer3.Q]--( Valve )--|

Operation:
- Press TriggerButton: Valve opens for exactly 2s
- Hold button: Valve still closes after 2s
- Multiple presses ignored until pulse completes

calculateCounter Instructions

Counters track the number of events or cycles in industrial processes. They are essential for production counting, batch processing, and maintenance scheduling.

|--[ ProductSensor ]--[R_TRIG]--[CTU Counter1]--|
                                  Preset: 100
                                  Count: 0

|--[Counter1.Done]--( BatchComplete )--|

|--[ ResetButton ]--[CTR Counter1]--|

Operation:
- Each product triggers count increment
- At count = 100: BatchComplete energizes
- ResetButton clears counter back to 0

(* Count bottles into cases *)
|--[BottleSensor]--[R_TRIG]-[CTU CaseCount]--|
                              Preset: 24

(* Stop filler when case full *)
|--[CaseCount.Done]--( StopFiller )--|

(* Eject full case and reset *)
|--[CaseCount.Done]--[TON T#2s]--(EjectCase)--|
|--[EjectCase]--[CTR CaseCount]--|

|--[ LoadButton ]--[LD Counter2]--|
                    Preset: 50

|--[ DispensePulse ]--[CTD Counter2]--|

|--[Counter2.Done]--( AllowDispense )--|
|--[/Counter2.Done]--( EmptyAlarm )--|

Operation:
- LoadButton sets count to 50
- Each dispense decrements counter
- At count = 0: Done goes FALSE, alarm activates

|--[EntryGate]--[CTUD InventoryCount]--|
|--[ExitGate]---+    Preset: 1000

|--[InventoryCount > 900]--( FullWarning )--|
|--[InventoryCount < 100]--( LowWarning )--|

Application: Parking garage vehicle counting
- Entry gate increments count
- Exit gate decrements count
- Warnings at high/low occupancy

compareComparison and Math Operations

Comparison instructions enable conditional logic based on numeric values, while math operations process analog signals and perform calculations.

(* High Temperature Alarm *)
|--[Temperature > HighLimit]--( HighTempAlarm )--|

(* Low Temperature Alarm *)
|--[Temperature < LowLimit]--( LowTempAlarm )--|

(* Temperature in Normal Range *)
|--[Temperature >= LowLimit]--[Temperature <= HighLimit]--(NormalRange)--|

(* Deadband Control - Prevent Rapid Cycling *)
|--[Temperature < (Setpoint - Deadband)]--( HeaterOn )--|
|--[Temperature > (Setpoint + Deadband)]--( CoolerOn )--|

(* Analog Scaling - Convert 0-10V to 0-100% *)
ScaledValue := (AnalogInput - 0.0) / (10.0 - 0.0) * 100.0;

(* Flow Rate Calculation *)
FlowRate := TankVolume / FillTime;

(* Production Rate per Hour *)
ProductionRate := (ProductCount * 3600) / ElapsedSeconds;

(* Average of Multiple Sensors *)
AverageTemp := (Sensor1 + Sensor2 + Sensor3 + Sensor4) / 4.0;

(* Efficiency Calculation *)
Efficiency := (ActualOutput / TheoreticalMax) * 100.0;

auto_awesomeAdvanced Programming Patterns

Professional PLC programmers use proven design patterns that solve common control challenges reliably and efficiently.

(* Method 1: Using R_TRIG Function Block *)
|--[ Sensor ]--[R_TRIG EdgeDetect]--( Pulse )--|

(* Method 2: Manual Implementation *)
|--[ Sensor ]--[/SensorOld]--( Pulse )--|
|--[ Sensor ]--( SensorOld )--|  (* Update old state *)

Benefits:
- Prevents multiple triggers from continuous signals
- Critical for accurate counting
- Reduces unnecessary processing

(* 1 Second Flasher *)
|--[/Flash1s]--[TON FlashTimer T#1s]--( Flash1s )--|
|--[ Flash1s]--[CTR FlashTimer]--|

(* Alarm with Flashing Light *)
|--[ AlarmActive ]--[ Flash1s ]--( AlarmLight )--|

Applications:
- Warning lights and beacons
- Attention-getting HMI elements
- Periodic sampling or logging
- Heartbeat signals for diagnostics

(* First Scan Bit *)
|--[/FirstScanDone]--( FirstScan )--|
|--( FirstScanDone )--|  (* Set permanently after first scan *)

(* Initialize Default Values *)
|--[ FirstScan ]--[MOVE 75 TO TempSetpoint]--|
|--[ FirstScan ]--[MOVE 50 TO SpeedSetpoint]--|
|--[ FirstScan ]--( ResetAlarms )--|

(* Load Recipe on Startup *)
|--[ FirstScan ]--[CALL LoadDefaultRecipe]--|

(* Motor Start Logic *)
|--[ StartPB ]--+--[/StopPB]--[/EStop]--[/MotorFault]--( MotorRun )--|
                |
                +--[ MotorRun ]--[ MotorRunning ]--+

(* Fault Detection *)
|--[ MotorRun ]--[/MotorRunning]--[TON T#5s]--( MotorFault )--|

(* Runtime Accumulation *)
|--[ MotorRunning ]--[CTU RunHours]--|  (* Increment every hour *)

(* Maintenance Due *)
|--[ RunHours > MaintenanceLimit ]--( MaintenanceDue )--|

linear_scaleSequential Control Logic

Sequential control manages multi-step processes where operations must occur in a specific order. This is fundamental to batch processing, machine cycles, and automated sequences.

(* Automated Wash Cycle Example *)

(* State 0: Idle *)
|--[ State = 0 ]--[ StartButton ]--[MOVE 1 TO State]--|

(* State 1: Fill Tank *)
|--[ State = 1 ]--( FillValve )--|
|--[ State = 1 ]--[ LevelHigh ]--[MOVE 2 TO State]--|

(* State 2: Wash Cycle *)
|--[ State = 2 ]--( AgitatorMotor )--|
|--[ State = 2 ]--[TON T#120s]--[MOVE 3 TO State]--|

(* State 3: Drain *)
|--[ State = 3 ]--( DrainValve )--|
|--[ State = 3 ]--[ LevelLow ]--[MOVE 4 TO State]--|

(* State 4: Rinse Fill *)
|--[ State = 4 ]--( FillValve )--|
|--[ State = 4 ]--[ LevelHigh ]--[MOVE 5 TO State]--|

(* State 5: Rinse *)
|--[ State = 5 ]--( AgitatorMotor )--|
|--[ State = 5 ]--[TON T#60s]--[MOVE 6 TO State]--|

(* State 6: Final Drain *)
|--[ State = 6 ]--( DrainValve )--|
|--[ State = 6 ]--[ LevelLow ]--[MOVE 7 TO State]--|

(* State 7: Dry Cycle *)
|--[ State = 7 ]--( SpinMotor )--|
|--[ State = 7 ]--[TON T#180s]--[MOVE 0 TO State]--|

(* Emergency Stop - Any State *)
|--[ EStop ]--[MOVE 0 TO State]--|

speedCode Optimization Techniques

Optimized ladder logic executes faster, uses less memory, and is easier to maintain. Apply these proven optimization strategies.

error_outlineCommon Mistakes to Avoid

Learn from these frequent programming errors to write more reliable ladder logic from the start.

WRONG:
|--[ A ]--( Motor )--|
|--[ B ]--( Motor )--|  <- Overwrites previous rung!

RIGHT:
|--[ A ]--+
          |--( Motor )--|
|--[ B ]--+

WRONG:
|--[ Sensor ]--[CTU Counter]--|  <- Counts every scan!

RIGHT:
|--[ Sensor ]--[R_TRIG]--[CTU Counter]--|

ALWAYS INCLUDE:
|--[ Start ]--+--[/EStop]--( Motor )--|
              |
              +--[ Motor ]--+

E-Stop should be hardwired AND in PLC logic