PLC Programming: Languages, Scan Cycles, and Working Ladder Logic

Key Takeaways

• Fixed Scan Cycle Execution – PLC Programming targets a fixed scan cycle: the controller reads inputs into a process image, executes your program, then writes outputs. Siemens documents cycle times measured against a default minimum of one millisecond and a default 150 ms watchdog.

• IEC 61131-3 Standardization – IEC 61131-3 defines the language suite. The current edition is 4.0, published 22 May 2025, which added UTF-8 strings and a full list of features deprecated since the 2013 edition.

• Language Selection Criteria – Ladder logic still dominates installed plant, but structured text is the practical choice for arithmetic, loops, and data handling, and instruction list is now treated as deprecated.

• Toolchain Ecosystem Isolation – The standard unifies syntax and semantics, not tooling. You still cannot program a Siemens CPU with Rockwell software, because addressing schemes, task scan rates, and file formats differ by vendor.

• Common Execution Pitfalls – Most first-year PLC bugs are not logic errors. They are scan-order assumptions, unbuffered inputs read twice in one cycle, and watchdog overruns from blocking code.

Introduction

PLC programming translates industrial control requirements into instructions that govern how machines respond to inputs, execute decisions, and operate outputs. From conveyor sequencing to process regulation, it provides the logic needed to coordinate equipment consistently and predictably. Effective PLC programming requires more than selecting instructions; engineers must understand how program execution, input updates, and output changes interact within the scan cycle of the controller.

Language selection also shapes how engineers develop, review, and maintain control logic. Ladder diagram, function block diagram, and structured text offer different approaches to expressing machine behavior, making each suitable for particular tasks and engineering workflows. Practical PLC programming connects these languages to timing, memory, interlocks, and fault handling.

This article examines PLC programming through its principal languages, the scan cycle, and practical examples. It explains how control patterns work and highlights considerations that help engineers develop clear, reliable, and maintainable programs for industrial automation.

What a PLC Is and What You Are Programming

The programmable logic controller (PLC) is a purpose-built industrial computer that interacts directly with physical equipment. In control system architecture, PLCs sit alongside operator stations and DCS controllers as field devices directly responsible for controlling physical processes. ^[8]

The hardware you write code against is consistent across vendors. PLC consists of a central processing unit (CPU), non-volatile program memory, input modules that read digital and analog sensor signals, and output modules that drive actuators. ^[4]

Because input modules read both digital and analog sensor signals, analog inputs such as temperature and pressure transmitters arrive on the same scan boundary as discrete contacts, and the scan reads all inputs into a process image together. The actuators on the output side are the plant equipment itself: valves, pumps, motor starters, and indicators. The fourth piece is the programming device, the PC running the vendor environment, which connects to the controller to download and monitor your code.

That hardware shapes the code. PLCs govern actuators, read sensor inputs, and maintain safety interlocks in nuclear power plants, water treatment facilities, chemical refineries, railway signaling systems, and automotive production lines. The consequences of a defect are physical, not merely financial.

Engineers develop, download, and monitor the application using a computer running the manufacturer’s programming software. The resulting program combines input values with timers, counters, stored variables, and control instructions to determine the required outputs. 

The availability requirements are equally unusual. Unexpected outages of systems that control industrial processes are unacceptable, and outages must often be planned and scheduled days or weeks in advance. Rebooting a component, a routine IT remedy, is usually not acceptable in these environments. ^[8]

Is a PLC Just a Computer? 

It is a computer, but the priorities are inverted. In a typical IT system, the primary concerns are data confidentiality and integrity. For operational technology, the primary concerns include safety, fault tolerance to prevent loss of life or endangerment of public health, regulatory compliance, equipment loss, and lost or damaged products. ^[8]

NIST states the design rule bluntly: any security measure that impairs safety is unacceptable. No general-purpose computing platform is engineered around that constraint.

Recommended Reading: What Is a PLC? A Complete Guide to Programmable Logic Controllers   

The Scan Cycle: The Model Your Code Runs Inside

Every line of PLC logic you write executes inside a repeating cycle. Understanding it is the difference between code that works on the bench and code that works on the machine.

What Happens in One Scan?

The conventional scan model consists of three main operations:

1. Update the Input Process Image: The controller copies input data into memory, providing buffered values for the program to evaluate.

2. Execute the Control Program: The CPU processes the programmed instructions, updating internal variables and the output process image.

3. Transfer Output Commands: The controller transfers buffered output values to the output modules, which command the connected equipment.

Communications, diagnostics, and operating-system activities also consume processing time. The controller schedules them; they do not necessarily occur in a separate phase after program execution.

For the Siemens S7-1500, cyclic processing uses process image partition 0 for automatic input and output updates. These updates occur during cyclic program execution. Other partitions can support different execution contexts. ^[7]

The practical implication is that reading a buffered input does not mean reading the physical signal at that instant. If a switch changes after its input value has been captured, logic using that snapshot will generally detect the change at the next update. Similarly, changing an output image value does not immediately change the physical output.

This model has exceptions. Direct peripheral access and asynchronous I/O updates can behave differently. For example, ControlLogix controllers update I/O data asynchronously with logic execution. Always establish the platform’s update rules before relying on a stable input snapshot.

Cycle Time, Minimums, and the Watchdog

Cycle Time is the time the CPU needs to execute the cyclic program, to update the process image of the inputs and outputs, and for all program parts and system activities that interrupt this cycle. ^[7]

It is not constant. The cycle time is not the same for every cycle because processing times vary with program loops, conditional commands, conditional block calls, different program paths, and interruptions from time-driven or hardware interrupt processing and communication.

Controllers police this with a watchdog. The following table lists the documented S7-1500 defaults, which show how the mechanism works across platforms, even though the values are Siemens-specific.

If the maximum cycle time is exceeded, the CPU goes to STOP under two conditions: if you have not loaded an OB 80, or if the cycle is still not completed after an additional maximum cycle time. ^[7] A blocking loop in your program logic is therefore not a performance problem. It is a plant stoppage.

The commercial platforms complicate this baseline further. They introduce platform-specific extensions such as multitask preemption, interrupt-driven tasks, and inter-task shared variables that complicate the basic cycle model. ^[4]

Scan Time Is Not Total Response Time

Physical response also depends on input filtering, module conversion times, network updates, output delays, and actuator behavior. The signal arriving just after an input update may wait almost another cycle before the program detects it.

Periodic tasks, interrupts, and shared variables add further timing considerations. Reliable PLC programming requires understanding both when a task executes and when the data it uses becomes available.

Suggested Reading: PID Controller & Loops: A Comprehensive Guide to Understanding and Implementation 

The Five IEC 61131-3 PLC Programming Languages

IEC 61131 is the standard for programmable controllers and has ten parts covering general information, equipment requirements, user guidelines, communication protocols, safety, and fuzzy control programming. Part 3 defines the programming languages and was first published in December 1993. [9]

The suite comprises two textual languages: instruction list (IL) and structured text (ST), and two graphical languages: ladder diagram (LD) and function block diagram (FBD), plus sequential function chart (SFC) for structuring program organization. ^[2] For these four languages, the standard defines the syntax and semantics, leaving no room for dialects. ^[3]

Ladder Logic and Ladder Diagram

Ladder diagrams represent control logic using networks, commonly called rungs, arranged between power rails. ^[6] Its resemblance to electrical relay schematics makes it particularly useful for discrete control and troubleshooting. 

There are two basic instruction types: an input instruction that checks, compares, or examines specific conditions in your machine or process, and an output instruction that takes some action such as turning a device on or off, copying data, or calculating a value.

Each rung evaluates a Boolean combination of contacts and assigns the result to one or more coils. In Rockwell notation, contacts are normally-open XIC (Examine If Closed) and normally-closed XIO (Examine If Open), and coils are output-enable OTE (Output Energize), set OTL (Output Latch), and reset OTU (Output Unlatch).

Schneider Electric describes the same structure in standard terms: code in LD is composed of contacts and coils; contacts lead the power from left to right according to their type, coils store the incoming value, and both contacts and coils must be assigned to Boolean variables. Contacts and coils are bounded on the left and right by power rails, and the left power rail is considered ON at all times. ^[12]

Parallel logic is expressed as a branch, which is two or more instructions in parallel, and there is no limit to the number of parallel branch levels you can enter. ^[6] Schneider shares that these parallel branches are also called WIRED-ORs, and every LD network must contain at least one coil, a left power rail, and a right power rail.

Rung order is program execution order: the scan executes the user program from the first rung to the last. ^[4] Logic that depends on a value computed further down the ladder will therefore act on the previous scan's value, which is a feature when you intend it and a bug when you do not.

Structured Text

Structured text is a textual programming language that uses statements to define what to execute. It is not case-sensitive, and tabs and carriage returns make your code easier to read without affecting execution. ^[5]

The assignments use :=, and statements end with a semicolon. For example, SpeedReference := RequestedSpeed; copies one value into another. Conditional constructs such as IF...THEN and CASE select execution paths, while FOR, WHILE, and REPEAT support iteration. 

Loops require particular care in PLC applications. They normally execute within the current task invocation, so excessive iterations can extend execution time. The loop should not wait indefinitely for a physical input to change; a sequence or state variable can preserve progress between task executions. 

The vendor extensions also require attention. Rockwell, for example, provides the non-retentive assignment operator [:=], with reset behavior tied to controller execution conditions. Such features should be treated as platform-specific syntax when assessing portability. 

Function Block Diagram and Sequential Function Chart

FBD suits signal flow and continuous control, where data passes between predefined blocks. In FBD, code is composed of functions and function blocks connected to each other or to variables using lines, and outputs cannot be connected to outputs. ^[12]

SFC is the state-machine language. The standard defines it for structuring the internal program organization rather than for expressing the low-level logic inside each state.

In practice, SFC is often paired with another language: the chart defines the sequence of steps and transitions, and the action inside each step is written in ladder or structured text.

Instruction List

Instruction list is a textual notation that uses short, assembly-like instructions. Engineers may encounter it when maintaining older PLC applications, where troubleshooting requires understanding instruction order and intermediate results.

IL is absent from the language suite specified by IEC 61131-3:2025. The existing applications may remain supported by their vendor tools, but new projects should use supported current languages selected around the application and the team’s maintenance needs.

Recommended Reading: Exploring Ladder Logic Programming: In-depth Exploration   

What Changed in IEC 61131-3 Edition 4.0

Tutorials that identify the 2013 edition as current are outdated. IEC 61131-3:2025, Edition 4.0, was published on 22 May 2025, updating the programming language definitions of the standard. ^[2]

The revision introduces UTF-8 strings and associated functions, expanding support for international text. Its language suite specifies structured text, ladder diagram, and function block diagram, alongside SFC structuring elements. Instruction list is no longer included in that suite.

For engineers maintaining reusable libraries or migrating applications, Annex B is the key change reference. It identifies features added, removed, or deprecated compared with IEC 61131-3:2013, helping teams assess which parts of an application require review. ^[1]

Publication of a new standard does not automatically update installed controllers or engineering software. Before adopting new features, verify support in the target development environment and controller firmware.

Worked Examples: Motor Control and Start Delay

The motor seal-in circuit demonstrates how a PLC maintains a command across scans. If you add an on-delay timer, it shows how the same application can introduce a delay without blocking program execution.

Both examples use Start_PB, which is true when the start button is pressed, and Stop_OK, which is true while the normally-closed stop circuit is healthy and unpressed. Pressing Stop makes Stop_OK false. Motor_Run represents the motor command, not confirmation that the motor is physically running.

Example 1: Motor Seal-In Circuit

The requirement is straightforward: pressing Start activates the motor command, releasing Start leaves it active, and pressing Stop clears it.

In ladder logic, place an XIC Stop_OK contact in series with a parallel branch containing XIC Start_PB and XIC Motor_Run. Connect the branch to an OTE Motor_Run coil. The following schematic shows the branch arrangement:

flowchart LR

    A["XIC Stop_OK"] --- B["XIC Start_PB"]
    A --- C["XIC Motor_Run"]
    B --- D["OTE Motor_Run"]
    C --- D

The Motor_Run contact provides the seal-in path around Start. XIC is appropriate for Stop_OK because it tests for a true input value, even though the physical stop button is normally closed.

In structured text, the equivalent logic is:

Motor_Run := Stop_OK AND (Start_PB OR Motor_Run);

Assume Motor_Run starts false; this logic executes once per scan, and no other code writes the variable. When Start is detected, the expression becomes true. During subsequent scans, the stored Motor_Run value maintains the command after Start is released. When Stop is detected, Stop_OK becomes false and clears the command.

Example 2: Motor Start with a Three-Second Delay

For delayed starting, latch an internal request before timing. Sealing in through the delayed motor output would lose the request if Start were released before the delay finished.

Declare the internal request and timer instance:

VAR
    Run_Request : BOOL := FALSE;
    Start_Delay : TON;
END_VAR

Execute these statements in order during each scan:

Run_Request := Stop_OK AND (Start_PB OR Run_Request);

Start_Delay(
    IN := Run_Request,
    PT := T#3s
);

Motor_Run := Stop_OK AND Start_Delay.Q;

Pressing Start sets Run_Request and enables the timer. The request remains active after Start is released, while the motor command stays false during timing. Once the timer recognizes that three seconds have elapsed, its Q output becomes true and enables Motor_Run.

Pressing Stop clears the request. On that execution, the timer receives a false input, resets its elapsed time and output, and clears the motor command. Call the timer every scan, including when its input is false. 

The PLC continues executing other logic throughout the delay. Physical starting also depends on task timing, I/O updates, and equipment response. Timer syntax varies between platforms.

These examples illustrate normal operating control, not emergency-stop functions. Define startup behavior explicitly; if Start remains pressed when Stop is released, the basic logic accepts another start request.

Program Organization: POUs, Tasks, and Configurations

Beyond a single rung, IEC 61131-3 defines how programs are structured.

The programs, function blocks, and functions are collectively called program organization units, or POUs. ^[3] Functions and function blocks are the most common POUs, and you can bundle recurring tasks into them and call them when needed. ^[9]

Above the POU sits the software model. The entire software required to solve a particular control problem can be formulated as a configuration at the highest level. Within a configuration, resources contain tasks, and tasks control program and function-block execution. ^[3]

This structure is what enables modular design. Splitting sub-tasks into POUs makes programs and their verification easier, and produces legible, coherent code rather than a monolith.

PLC Programming Software by Vendor

Here is the part the standard does not solve. Software used to program PLCs from one vendor typically cannot program PLCs from another because of differences in addressing schemes, task scan rates, array sizes, string lengths, and file formats. ^[9]

Rockwell Automation: Studio 5000 Logix Designer

Studio 5000 Logix Designer configures, programs, and maintains supported Logix controllers, including ControlLogix and CompactLogix. It supports applications spanning discrete control, process automation, motion, and safety. ^[6]

Rockwell describes Logix Designer as the rebranding of RSLogix 5000. Older installations may still require an earlier software version, so an RSLogix 5000 reference is not automatically incorrect. Always check compatibility with the controller firmware and existing project. 

Siemens: SIMATIC STEP 7 in TIA Portal

SIMATIC STEP 7 provides PLC programming and configuration within the broader TIA Portal engineering environment. It supports controller families such as the S7-1200 and S7-1500, bringing program development, hardware configuration, and online diagnostics into a common workspace. ^[4]

Engineers use this environment to configure I/O, organize program blocks, and establish execution settings. Understanding these settings is essential because they determine how the application interacts with the controller hardware.

Schneider Electric: EcoStruxure Engineering Software

Schneider Electric uses different programming environments for different controller families. EcoStruxure Machine Expert serves machine controllers such as the Modicon M241, M251, and M262. EcoStruxure Control Expert serves families including the Modicon M340 and M580. 

The distinction matters when selecting software or following a tutorial. Instructions for one EcoStruxure product may not apply to another, and you must check safety programming capabilities for the specific tool and controller.

CODESYS Development System

CODESYS provides an engineering environment used across devices from multiple manufacturers. Its portability depends on compatible runtimes and device packages; it does not automatically support every PLC.

The environment also supports PLCopen XML exchange, helping engineers transfer supported programming objects between compatible tools. Hardware configuration and vendor libraries can still require adaptation.

Program Exchange and Portability

PLCopen XML provides a standardized format for exchanging programming objects, but support varies by tool and object type. The XML export alone does not establish compatibility: L5X format, for example, should not be assumed to be PLCopen XML. 

Successful migration requires more than importing source code. Engineers must review I/O mappings, library dependencies, data types, variable retention, and task timing to confirm that the application behaves correctly on the destination controller.

Open-Source Programming Tools

Open-source tools offer another development path. MATIEC translates supported IEC 61131-3 textual code into C, while OpenPLC provides an editor and runtime ecosystem for control applications. The compiler translates the program; the runtime supports its execution. ^[4]

Check the implementation version before following installation guides. OpenPLC Runtime v3 has reached end of life and has been replaced by v4, so older tutorials may refer to the earlier platform.

Recommended Reading: What Is a Programmable Automation Controller (PAC)?   

Communication: Fieldbus, EtherNet/IP, and Modbus

PLC systems rarely work alone. Fieldbus networks eliminate the need for point-to-point wiring between a controller and individual field sensors and actuators. Industry groups commonly use standard industrial communication protocols, such as Modbus and Fieldbus, on control and fieldbus networks.

EtherNet/IP uses the Common Industrial Protocol (CIP) for its upper layers and relies on standard TCP/IP, with UDP support enabling real-time cyclic data transmission. It runs on standard, unmodified Ethernet, so facilities do not need special hardware or expertise, and it supports star, linear, and device-level ring (DLR) topologies. Conformance-tested EtherNet/IP devices work with any other, regardless of supplier. CIP itself covers control, safety, security, energy, synchronization and motion control, information, and network management. ^[10]

Modbus is maintained by the Modbus Organization, which describes itself as the steward of the world's most widely adopted industrial communication protocol. The Modbus application protocol specification, version V1.1b3, describes the function codes used in Modbus transactions. ^[11] For serial links, the organization recommends the Modbus Serial Line Protocol and Implementation Guide V1.02 for new implementations and marks the 1996 document for legacy applications only. 

Above the controller layer, SCADA systems and HMI stations supervise the wider PLC system. In a rail control example, a SCADA system polls field sections for status and feeds that information to operator consoles at HMI stations within the control center. ^[8]

Recommended Reading: PLC and SCADA: Understanding the Differences in Industrial Automation Systems   

Common Mistakes and Troubleshooting

These failure modes consume commissioning time, and each follows from the runtime model rather than syntax.

Below are the common mistakes and troubleshooting tips:

1. Reading an Input Twice in One Scan without Buffering: I/O module data updates asynchronously to the execution of logic, so if you reference an input multiple times, it could change state between separate references. 

2. Blocking Inside the Cyclic Program: A long loop pushes the cycle time past the maximum, which calls the time error OB; without an OB 80 loaded, the CPU goes to STOP.

3. Assuming Outputs Act Immediately: Outputs are written from the process image at the end of the scan, not at the instruction. ^[7] Logic that expects a field device to respond within the same scan will not behave as written.

4. Overusing High-Priority OBs: Communication tasks run at priority 15, and too many runtime-intensive blocks above that priority degrade communication functionality.

5. Expecting Portability the Standard Does Not Provide: The languages are standardized, but addressing schemes, task scan rates, array sizes, string lengths, and file formats are not. 

6. Ignoring the Security Posture: Legacy control systems often lack encryption capabilities, error logging, and password protection. ^[8] The Stuxnet incident demonstrated that PLC programs are a viable attack surface.

7. Treating Verification as Testing: Formal verification proves the presence or absence of a property across all possible execution traces, rather than testing a finite sample. For interlocks, the distinction matters.

How to Learn PLC Programming

Learning PLC programming combines control logic, an understanding of execution timing, and familiarity with the software used to configure and troubleshoot the controller.

Start with Ladder Logic

Learn contacts, coils, Boolean conditions, timers, and counters. Build small applications such as a motor seal-in circuit, a delayed start, and a conveyor sequence. Identify what activates each output, what maintains it, and what stops it.

Understand the Scan Cycle

Study input updates, program execution, and output updates alongside your first exercises. Trace values across successive scans to understand instruction order, stored states, and response timing. Include startup behavior and variable retention early.

Practice in Simulation

Use a simulator or compatible software runtime before connecting physical equipment. Test normal operation, simultaneous commands, missing inputs, and interrupted sequences. Simulation helps identify logic errors, but hardware timing, wiring, and actuator behavior still require physical verification.

Add Structured Text

Use structured text for calculations, arrays, conditional logic, and repeated operations. Recreate a ladder exercise in ST to compare both approaches. Keep loops bounded, and use state variables for operations that span multiple scans.

Learn the Target Engineering Environment

Choose software that matches the controllers you expect to support. Practice configuring I/O, organizing routines, monitoring variables, and interpreting diagnostics. Language knowledge transfers between platforms, but hardware configuration, libraries, and execution settings require platform-specific understanding.

Recommended Reading: What is Programmable Automation? 

Conclusion

PLC programming rewards engineers who internalize the scan cycle first and the syntax second. The languages are standardized by IEC 61131-3, now in edition 4.0 as of May 2025, and that standardization is real: for the core languages, syntax and semantics are fixed, leaving no room for dialects.

It is better to write logic around the execution model of the controller. Buffer inputs when an operation requires consistent values, keep task execution within its timing limits, and organize code into clear, reusable program units. Use ladder diagram for readable discrete control and structured text where calculations and data handling benefit from textual expression. 

Buffer your inputs, keep the cyclic program short enough to stay well inside the watchdog, structure logic into POUs, and treat ladder and structured text as complementary rather than competing. The plant will tell you quickly whether you got the model right.

Frequently Asked Questions

Q. What is PLC programming?

A. PLC programming is writing control logic for a programmable logic controller, an industrial computer that reads sensor inputs and drives actuators on a repeating scan cycle. IEC 61131-3 defines the languages, specifying the syntax and semantics of programming languages for programmable controllers.

Q. What are the five PLC programming languages?

A. Ladder diagram (LD), function block diagram (FBD), structured text (ST), instruction list (IL), and sequential function chart (SFC). IL is now treated as deprecated.

Q. Is a PLC just a computer?

A. It is a computer with inverted priorities. Where IT systems prioritize data confidentiality and integrity, operational technology prioritizes safety, fault tolerance, and availability, and any security measure that impairs safety is unacceptable.

Q. Which PLC programming language should I learn first?

A. Ladder logic is the dominant PLC programming notation in installed plants, so most existing programs are written in it. Structured text is the natural second language, since it's documented for complex algorithms and data manipulation.

Q. How long does a PLC scan take?

A. Cycle times typically range from 1 ms to 100 ms. Siemens sets a default minimum cycle time of one millisecond on the S7-1500 and a default maximum, or watchdog, of 150 ms.

Q. What happens if my program takes too long to execute?

A. On an S7-1500, exceeding the maximum cycle time calls the time error OB (OB 80), and the CPU goes to STOP if no OB 80 is loaded or if the cycle still does not complete within an additional maximum cycle time.

References

[1] IEC. IEC 61131-3:2025, Programmable Controllers, Part 3: Programming Languages [Cited 2026 September 08] Available at: Link

[2] PLCopen. IEC 61131-3 and PLCopen [Cited 2026 September 08] Available at: Link

[3] OPC Foundation. General Information on IEC 61131-3 and OPC UA [Cited 2026 September 08] Available at: Link

[4] arXiv. ESBMC-PLC: Formal Verification of IEC 61131-3 Ladder Diagram Programs Using SMT-Based Model Checking [Cited 2026 September 08] Available at: Link

[5] Rockwell Automation. Logix 5000 Controllers Structured Text Programming Manual [Cited 2026 September 08] Available at: Link

[6] Rockwell Automation. Logix 5000 Controllers Ladder Diagram [Cited 2026 September 08] Available at: Link

[7] Siemens. SIMATIC S7-1500 Cycle and Response Times Function Manual [Cited 2026 September 08] Available at: Link

[8] NIST. Guide to Operational Technology (OT) Security [Cited 2026 September 08] Available at: Link

[9] Control. PLC Programming: Overview of IEC 61131-3 in Industrial Automation Systems [Cited 2026 September 08] Available at: Link

[10] ODVA. EtherNet/IP [Cited 2026 September 08] Available at: Link

[11] Modbus Organization. Modbus Specifications [Cited 2026 September 08] Available at: Link

[12] Schneider Electric. Programming Languages, EcoStruxure Machine Expert Safety, IEC 61131 Implementation [Cited 2026 September 08] Available at: Link