PLC projects, programming best practices, Part 2: Case studies on address structures

In a September 14, 2023 webcast, "PLC Series: PLC projects, programming best practices" Automation Consulting LLC’s Frank Lamb joined Control Engineering to discuss PLC history and platform differences, as well as the impact of standards.

By Control Engineering February 26, 2024
Image courtesy: Brett Sayles

PLC programming insights

  • In a September 14, 2023 webcast, “PLC Series: PLC projects, programming best practices” Automation Consulting LLC’s Frank Lamb joined Control Engineering to discuss best practices related to PLC-based programming.
  • In Part 1, Lamb discusses PLC history and platform differences, as well as the impact of standards.
  • Part 2 has a case study example on address structures and their unique features and part 3 has more information on PLC-programming platform best practices and considerations.

Programmable logic controllers (PLCs) remain a strong choice for many automation applications, and programming software and practices that use standards have huge advantages over other options. Documentation is important, along with change management, and understanding use of standards to more efficiently program for certain applications. This includes the ability to bridge from operational technology (OT) applications to information technology (IT) connections. By using standards, code will be easier to update and optimize from current to future operations. In a September 14, 2023 webcast, “PLC Series: PLC projects, programming best practices” Automation Consulting LLC’s Frank Lamb joined Control Engineering to discuss these topics and more.

Below, the transcript of his presentation has been provided with minor edits and adaptations.

Programming languages and memory structure in various platforms

This platform programs in all languages, much like brand C. However, the choice of language often depends on the country, with ladder logic being the most common worldwide. All memory in this platform is mostly global, but it does include UDTs, unlike brand A.

Case study examples and address structures

Here’s a little case study on these platforms, accompanied by some pictures I’ve put together. One example, called Ladder 3, shows their routine structure. You might notice addresses like B3, N7, or N20, and I’s and O’s for inputs and outputs. In the next image, labeled FC2, you’ll see a completely different address structure, with M’s, I’s, Q’s, and many DB addresses. For this platform, specifications often recommend placing most data in these DBs, a capability not present in brand A.

Platform differences in addressing and retentivity

The third picture, from an older platform originating from Japan, shows that W addresses are non-retentive. In a program I wrote for demonstration, all W’s would be off upon download, while H’s, being retentive, would remain in their last state. The inputs and outputs are marked as X and Y instead of I and Q or I and O, which is another aspect to consider when writing specifications.

Transition to modern programming platforms

Moving on to more modern platforms, I’ve stuck with the A, B, C and D nomenclature. Brand D, which I’m less familiar with, also has a modern tag-based platform. The older version of brand D is still prevalent, and most of the classes I teach are based on that platform. Brand A evolved around 1998, introducing tasks, programs, and routines. The tasks here differ from those in brand D. For instance, there is one main task that runs continuously, unlike the other platform where you could have 16 tasks operating in turns.

Task definition and memory allocation differences

The meanings of programs and routines also slightly differ. This platform has both global and program level tags but lacks what I call private tags. In contrast, brand B has private tags specific to a routine, as does platform C. It also features local tags, termed either temp tags or stat tags, private to the routine itself, not the entire program.

Function block definitions across platforms

What brand A calls a function block may differ from the classical definition.

They call it an AOI, and there is a significant difference between an AOI and a function block. One major limitation is that you cannot edit it online, which can cause some real problems. In fact, the only way to incorporate an AOI into a working program is to modify it in a separate copy of the program and then import it. This is somewhat inconvenient, but it’s the chosen method. This platform has four of the five languages, but ladder logic remains heavily used. In North America, where I’m based, this platform is quite common, comprising about 60 to 70% of the market.

Platform popularity and specific terminologies

The widespread use of ladder logic in the United States is partly due to this platform’s dominance, although this trend is changing. Some specific terms on this platform include Alias, RPI, abbreviations like AFI, NOOP (which is common across several platforms), and others like RPI and AFI that are specific to this platform. Alias is used in classical programming, but this platform has a unique approach to it. The platform also has features like produced and consumed, and uses a network protocol known as Ethernet/IP, a deterministic Ethernet-based language.

Brand B’s programming structure and communication protocol

Brand B uses something called program organization units (POUs), with different types of programs including FCs, functions, and FBs, similar to brand C. They have global and local, and private tags, a general memory area, plus data blocks that can be built. All five languages are used, but instruction list is less common. They utilize classical programming methods like actions, methods, properties (calling their procedures “methods”). Their communication protocol is EtherCAT, a different language than Ethernet/IP, despite both being Ethernet-based.

Brand C’s features and communication protocol

Brand C, with its modern tag-based platform, employs organizational blocks (OBs) which are special-purpose and help in preventing faults, a feature not present in the other two platforms. This platform uses all five languages, but STL, their version of the instruction list, is unavailable on one of their platforms, even though it was very popular in their previous register-based program. Their communication protocol is Profinet, another Ethernet language, but incompatible with the other two Ethernet protocols mentioned.

Evolution of PLCs and examples from platform B

This segment reflects the evolution of PLCs. The languages mentioned here are all from platform B, as taken from an example program I use. Three of these languages are graphical, while two, including the instruction list (not shown here) and structured text, are text-based. I’ll also discuss why this distinction is important. Instruction list is set to disappear in the next version of IEC 61131, and a new language, continuous function charts (CFCs), will be introduced in the next update of IEC 61131-3.

Advantages of different PLC languages

Ladder logic is graphical and easily understood by maintenance personnel, especially in the United States. However, it’s difficult to perform string operations with this language.

Although brand A has developed many utilities that make handling strings easier, it can still be quite complex. You need to understand what strings are, how they’re put together, and some special words associated with them. Structured text is a big topic on many forums, with debates about the reliance on ladder logic versus structured text, which is familiar to computer coders. People with a background in computer science or experience with platform B find structured text very familiar, similar to programming in C or Python. It’s great for math and data manipulation but can be challenging for most maintenance personnel to modify. In some platforms, structured text is compiled and has to be downloaded as a separate object, which prohibits online editing, making it somewhat awkward.

FBDs and SFCs

Function block diagrams are not widely used, but they are prevalent in educational settings, particularly in laboratory-based platforms, and are common in process control. They are graphical and relatively easy to understand but can be difficult for string manipulations or complex math. The function set might also be more limited than in ladder logic, depending on the platform. Sequential function charts (SFC) are becoming more popular. They are graphical, suitable for integrating code directly into an HMI, and are particularly effective for visualizing sequences. However, coding in SFC can be time-consuming, especially without a template.

Program organization across different platforms

Program organization varies significantly from one platform to another. I’ve included examples from platform A (both old and modern versions), platform B (which only has a tag-based system and is more akin to a computer), and platform C (with both old and modern versions). The old version of platform C had the inconvenience of multiple independent windows, while the modern version offers a cleaner, more integrated environment. Program organization can also differ based on the industry, such as process control versus machine control, where standards and organizational structures vary greatly.

Differences in program organization between industries

In process control, programs are often organized according to P&ID assemblies, with the SCADA systems and HMIs following similar patterns. In contrast, machine control often requires more complex organization, grouping functions by system inputs, control sequences, outputs, alarms, faults, and optionally part tracking, data acquisition, HMI interfaces, etc. These broader groupings can make the organization more complicated.

Creating and utilizing standards in PLC programming

When considering writing a standard, the goal is to create a template. This template is a stripped-down PLC program with example code in standardized sections, serving as a model. The template I use, as shown on the left, includes tasks with different routines. Details like alphabetizing routines are specific to the brand and industry. The middle image shows a piece of ladder logic with instructions at the top of the routine, a common practice in templates. These instructions guide both the interpretation and writing of the code, essential for new hires at large systems integrators or machine builders, who must adhere to these standards.

There may be external documents dictating programming standards. To the right, we have an older version of brand C, where the organization is noticeably different. On a screen displaying this version, you would see a list of icons and details, but not the organization of the program itself. You wouldn’t know what calls what, or in what order, until you use a cross-reference or organizational guide, although there is a utility for that. On the left, the organization is evident just by opening the folders, whereas on the right, you need to use a special tool to understand the program’s structure. This is essentially what a template is — an example program.

Software coding standards and contrast with PLC programming

Let’s talk a bit about software coding standards. I’ve borrowed from classical online resources discussing programming in C, Python, Pascal, etc., focusing on naming conventions for tags and files, and the use of header files. Header files, typically not applicable in PLCs, provide a contrast to how standards might be written for PLC programming. Global variable usage varies significantly between structured texts in formal software development and PLCs. Exception processing, often irrelevant in PLCs, can lead to a complete halt in operation, unlike in computer programming where an exception might only cause a minor issue.

Handling exceptions and importance of change documentation in PLCs

Brand C, both in its old and new platforms, offers a workaround for exception processing problems through the use of OBs. Correct OBs can keep a program running despite faults, barring catastrophic hardware failures. Change documentation is crucial for standard programming, though it’s often discussed more than implemented. It’s especially vital in sectors like medical programming, where validation is critical, as opposed to industries like automotive, where changes are frequent and often undocumented or unvalidated.

Software validation and use of libraries in development

Software validation is mentioned in the context of critical industries like medical devices and pharmaceuticals, where program alterations are not done casually, unlike in industries where changes are more common. In those more regulated industries, every program alteration must be thoroughly documented and validated. Software practices also include the use of libraries, a common aspect in software development.

Library implementation across different platforms

In some cases, like platform A, you cannot implement libraries in the classical sense. Neither the old nor the new version of platform A includes what they call a library. While you can build custom code, it must be saved externally to the program itself. In contrast, brand B not only includes libraries but requires their use for any code functionality. These libraries are extensive, allowing for the integration of special code and unique features. Meanwhile, platform C, one of the largest platforms globally, offers optional libraries. Users can program without them, import built-in libraries, or create their own. However, when writing specifications, if you don’t consider the brand, users of brand A might struggle with the concept of using libraries.

Understanding the concept of a library

A library is essentially a collection of functions, function blocks, and instructions that can be imported into a project or are already present as standard libraries. This concept varies significantly across different PLC platforms.

Programming terms and implementation challenges in different languages

Some common programming terms, mostly related to ladder logic, range from basic to complex concepts. For example, implementing a hold-in circuit, commonly seen in ladder logic, can be challenging in structured text, where the only instruction might be a set. Similarly, debounce, a timer attached to I/O, is often mandated in standards, requiring special blocks with built-in debounce functionality. Back checking, another term, relates to both input and fault checking and is crucial in programming. Accumulators, used instead of counters in certain platforms, are a technique applicable in various programming languages, including ladder, statement list, and structured text.

Special functions and techniques in PLC programming

A free-running timer, used for simulations, creates pulses at set intervals and is a useful trick included in my template. Word sequences or state machines, demonstrated here in ladder logic, are adaptable to structured text, function block and SFC. Another term to note is SCL, which brand C uses for their version of structured text. Knowing these acronyms and their applications is critical in PLC programming.

Understanding functions and function blocks in programming

A function, which brings us into more object-oriented programming concepts, is a reusable section of code where variables can be passed in and out. Typically, some definitions of functions allow only one variable to be passed out, while others permit multiple outputs. Importantly, a function does not have internal memory, which is crucial when writing a function. A common example is scaling, like converting Fahrenheit to Celsius.

In contrast, a function block, which brand A refers to as an AOI, is quite different. It’s a reusable section of code like a function, but it has internal memory. Brand C uses this internal memory in the form of what they call a data block, while brand A keeps it entirely internal, creating something akin to a UDT to track it.

Programming best practices across various brands

I’ve listed some generic programming best practices, applicable regardless of brand. The choice of brand often dictates the best practice and preferred programming language. For example, brand A in the U.S. defaults to ladder logic, around which most of its functionality is built. Applying best practices like keeping logic simple, breaking it into smaller sections, and extensive commenting is advisable, though there’s debate even about the extent of commenting.

Using a template is beneficial, as it provides a structure for programming, including examples of routines, debouncing, back checking, and faults. Another important practice is to use local tags where possible. For instance, brand B advocates against using global tags. This approach is supported by programmers in other areas like C and Python, who recommend keeping everything local to avoid confusion and accidental overwriting.

Differences in code separation and tag naming conventions

Separating code by function or area is crucial and varies between process control and machine control. In one approach, you separate code by function (inputs, outputs, faults, etc.), while in another, you group all related elements into one block, specific to a P&ID cell or area. Consistency in tag naming conventions is also key. I typically use CamelCase, but brand B strongly recommends Hungarian notation, denoting types like Boolean, integers, and floating points with specific lowercase letters. In the U.S., this practice is less common due to the ability to hover over a tag to identify its type.

Balancing reusability and complexity in code

When programming in C or Python, you can’t always hover over a tag to identify its type, but this is possible in PLC programming within the software. Making code reusable is important, but it’s crucial to know when it’s excessive. Overuse of custom function blocks or AOIs can lead to confusion, as users might not understand what a block does and can’t see inside it. This can be particularly problematic if a program isn’t working and the flow through the block can’t be traced. Remember, the end customer is often the person who maintains the system, not necessarily the one who purchases it. This customer could be a maintenance person or an engineer who may not be deeply familiar with complex technologies.