Bench Talk

(Source: Libor / stock.adobe.com)

The history of the programmable logic controller (PLC) is one of the Industrial Revolution converging with the Information Revolution. Ever since the advent of the moving assembly line in the early 1910s, there has been a constant push to make manufacturing fast, reliable, and consistently repeatable. Factories in the First Industrial Revolution used purely mechanical and electrical horsepower to tackle the problem of mass production. This worked great if the assembly line was not reconfigured regularly. But by the 1960s, the automotive industry needed help reconfiguring their assembly lines with every model year—a manual process requiring technicians to rewire sensors and solenoids by hand. At the same time, the fledgling computer industry had matured enough to offer a physically robust and cost-effective solution. Automakers began installing the hardware precursors to the modern PLC; instead of needing to completely rewire the assembly lines, technicians could simply upload new code to change the manufacturing processes.

Or rather, that was the theory.

This article examines the various options for programming a modern PLC as defined by the international standard IEC 61131-3. However, every PLC manufacturer offers software to program their particular hardware, so there will be nuances in coding techniques between manufacturers.

Early Programming of Automation Technology

While these PLC precursors—a variety of mechanical, electrical, and electronic control systems and pneumatic and hydraulic controls—worked well initially, they suffered one serious flaw. Reprogramming them required knowledge of assembly or Fortran programming languages, but the electricians and mechanics tasked with maintaining and updating these systems were not programmers. They instead spoke a language called ladder logic. The electronics engineers went back to the drawing board and returned with the first generation of what we call a PLC today. In the intervening decades, additional programming methods have been introduced; but to this day, ladder logic remains the dominant programming method in the industrial world.

Ladder Logic

Ladder logic was initially written to visually document the design and construction of relay racks used in manufacturing and process control (Figure 1). It resembles the schematic diagrams of relay logic hardware. A ladder diagram begins with the power rails drawn as two vertical lines. Horizontal lines, or rungs, between these power rails represent an atomic logical operation. The input symbols, called contacts, represent sensors, switches, and push buttons. They are kept to the left and center of each rung. Whereas outputs (referred to as coils) such as motors, relays, indicator lamps, or sirens are kept to the right of the rungs. The system's control logic is implemented by arranging the contacts and coils to create logical relationships (e.g., AND, OR, NOT) between the inputs and tie them to the outputs.

Figure 1: An example of a ladder logic diagram. (Source: Green Shoe Garage)

Two common input logic symbols are "examine on" or EON (sometimes also referred to as "examine if closed" or XIC) and "examine off" or EOF (or "examine if open" or XIO). EON can represent either a normally open contact or a buffer. Alternatively, EOF can represent either a normally closed contact or an inverter. Lastly, the output logic symbol is referred to as output energize, or OUT (Figure 2). It has only one meaning: to provide power to whatever output device the output coil controls.

Figure 2: Common ladder logic symbols. L to R: examine on (EON), examine off (EOF), and output energize (OUT). (Source: Green Shoe Garage)

When organized in parallel, inputs are arranged in a way equivalent to the logical expression OR. Conversely, when arranged in series, the inputs form an AND relationship. Another essential thing to keep in mind is that outputs should appear only once in a ladder diagram to ensure there is only one sequence of inputs controlling the state of each output.

A PLC works in what is referred to as a program scan cycle and executes the program repeatedly. On average, it takes several tens of milliseconds for a PLC to evaluate all the inputs against the instructions and change the outputs to reflect the current machine state. The ladder logic representation of the control program is typically read left-to-right and top-to-bottom. In general, the scan cycle follows this flow:

1. Read the inputs
2. Execute the program
3. Write output bits

Some final rules for programming with ladder logic:

• Organize your ladder logic code so that it flows logically and is easy to follow. Group related functions together and use subroutines to modularize your code.
• Limit rung size, as excessively large rungs can be challenging to troubleshoot. Break down complex logic into smaller, more manageable steps.
• Do NOT program emergency stops in the PLC software. Consider how your program will behave in case of unexpected events like sensor failures—design for fail-safe operation to minimize risks. The emergency stops must be hardwired into the machine's electrical distribution system. Never rely on the PLC itself for life and safety concerns.
• Connect inputs to a buffer or inverter to allow software-based changes instead of rewiring machines. Remember, in the industrial world, downtime has significant financial and workforce implications. Changing code is easier than rewiring.
• Apply consistent logic principles throughout your program. For example, if you use normally open (NO) contacts for start conditions, continue using NO contacts for similar functions unless there is a specific reason to do otherwise. Also, if you use counters, consistently use count-up versus count-down timers.
• Understand memory maps, also sometimes called the data table. Because PLC is a memory-limited device and uses hardwired memory addresses for I/O, successful programming requires a developer to have in-depth knowledge of internal memory structure, more so than other types of software development, such as desktop applications. Furthermore, different data types (some manufacturers refer to these as file types) are represented by different amounts of bits. Special characters are used to denote the various components of memory, such as:
  
  O:3.1/0
  [File Type or Number] : [Element Number] . [Word Number] / [Bit Number]
  
  The file type/number represents the type of data, such as an input, output, or counter. The element number represents the I/O slot. If a data type is multi-word, then the word number represents which word to access. And lastly, bit number represents which bit in a word to access. Thus, this example represents the first bit of the second word of the third output slot.
  
  Again, these formats will vary from vendor to vendor, but in general, it’s important to have an intimate knowledge of where individual bits are set, especially for external I/O.

Beyond the Ladder

In addition to ladder diagrams, IEC 61131-3 provides governance on two other graphical PLC programming methods: the function block diagram (FBD) and the sequential function chart (SFC). It also details a text-based method called structured text, a block-structured programming language that syntactically resembles Pascal. Note that Arduino has also introduced an Arduino-based (itself a wrapper of C) method for programming their Arduino Opta family of PLCs. Other PLC vendors have begun to move away from proprietary programming languages, adopting instead languages such as Python, Java, and C++.

Structured text methods of programming PLCs are becoming increasingly popular among organizations looking to make their manufacturing processes Industrial Internet of Things (IIoT)-compatible. The IIoT (whether connected to the internet or larger private wide-area networks) offers some advantages that may appeal to some manufacturers (as well as some risks) over traditional, non-networked factory automation technologies.

With the advent of the IIoT, modern PLCs now include more advanced networking capabilities, allowing them to easily connect to the internet and communicate with other devices in the IIoT ecosystem. This includes support for various communication protocols, such as MQTT, AMQP, and OPC UA, which are essential for real-time cloud connectivity and data exchange. This is desirable for several reasons, including enterprise resource planning (ERP) system integration, digital twinning, predictive maintenance, and remote monitoring.