PLC projects, programming best practices, Part 1: Platform history and differences

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.

Introduction to PLC history and platform differences

Frank Lamb: I thought we’d start out here with a little bit of PLC history, and this is actually leading somewhere. I’m going to talk about why some of these platforms are so different from each other and why, when you’re making specifications, you have to base it a bit on what platform you’re using. Early computers long ago used groups of four bits. You may be familiar with this if you do any programming, with some of the languages, like hexadecimal, for encoding of data. So that’s where some of the early encoding of bits and turning them into words came from.

The 8-bit microprocessor was developed in the 1970s, which was slightly after the PLC was first created in 1968. The first one was actually built in 1969 as a replacement for hardwired relay circuits, and early relay logic was designed by hand drawing circuits, similar to what you see here in this slide on the left. People would hand-draw these circuits and then wire them from contact to coil. There were electronic timers, pneumatic timers, and it was very cumbersome, with lots of wiring. At that time, computers, which had evolved over the previous 20 years or so, were turned into an automation system based on these relay circuits.

Programming early PLCs and the transition to software

That was how you would program them. You would hand-draw the program and then turn it into mnemonic code, entering that code usually using some kind of handheld controller, before the age of laptops and such. Programs were stored on magnetic tape, and non-volatile magnetic core memory, which were actually little reversible magnets, was used for processing. Most of the PLCs around today evolved from those original formats. In the 1990s, PLCs began to be programmed with software on PCs, and that’s about where I got started in my first PLC programming. We used a lot of handheld controllers for a while, and then, with the advent of Windows, things started to become more graphical rather than just typing in instructions and using function keys.

IEC 61131 standard and its impact

In 1994, early in the development of Microsoft Windows, a standard was designed for what PLCs should be, what their data types would be, how they were arranged, and how they processed things. Interestingly, at that point, all PLCs became non-compliant with IEC 61131. There were many reasons for this, some of which I’ll point out as we go through this presentation. Part three of IEC 61131, which is -3, defines the programming languages. Back then, most programming languages were still written in ladder logic. The design would be done by hand in ladder logic and then turned into mnemonics. One brand, which I’ll discuss, took that language and made it into a super language, but it still did not fully comply with 61131.

Why platform differences matter

Why does all this matter? One reason is that PLC platforms all evolved differently. They took various directions and recommendations, even though there was a standard. You’ll still find many differences between these platforms, depending on the region you’re in and the industry’s standards. For instance, process control, like in oil and gas and utilities, uses a completely different programming style than machine control. So, there are many differences here based on the kind of programming you’re doing and the standards you’re writing.

Case study on diverse PLC platforms

So, I prepared a case study here. To avoid promoting any particular brand, I just call them platforms A, B, C, and D. These are all platforms I’m very familiar with. I program probably six or seven brands of PLCs. Usually, that’s not my decision. I generally have to write programs based on what the customer wants. I also teach classes around the country and have to teach whatever the plant platform is, rather than my preferred brand. So, I’m somewhat brand agnostic.

Of course, everybody has their favorite platforms, but I’m a bit agnostic about this. I’m not going to prefer any one of these four brands, but these are four platforms that I’m very familiar with. I’ll use them to contrast the differences in programming standards and things. First, I’m going to start with the older register-based PLCs, which many of you might be familiar with. They are still widely used in the industry, even though they are mostly 16-bit or lower-based platforms originally. Most of these originated in the 1980s or 1990s, but they’re still around today with much of the same functionality.

Details on platform A: 16-bit word-based system

So, we’re going to start with brand A. This is a 16-bit word-based platform, and all of the registers in this platform are retentive. You might know what I’m talking about here. I can take a program from this platform, just a copy of the program not being online, and I can actually see the values in the registers at any time. This is somewhat unusual. None of the other platforms that I’m going to talk about, C and D, allow you to do that. When you save that program, it actually has a snapshot of what the registers were and the status of the program at the time you saved it. This platform uses programs and routines.

Platform A’s programming and memory structure

The platform programs only in ladder logic. You can convert ladder logic into an instruction list, another one of the five major IEC 61131 languages, but the intent is to use Ladder Logic. All the memory in this platform is global. It doesn’t have user-defined types (UDTs) in its original form.

Contrasting platform C: 8-bit byte-based system

Moving on to platform C, this is an 8-bit byte-based system. It uses 16-bit words internally, but its early development focused on bytes. This means all addressing, including I/O addressing, is byte-based (e.g., .0 through .7 for one word, 1.0 through 1.7 for the next). This requires understanding octal-type addressing. The retentivity of the program is assignable, which can lead to issues, such as registers holding zeros upon re-downloading a saved program. It has a general memory area and data blocks, which brand A doesn’t have. Data blocks are collections of mixed data types.

Programming languages and UDTs in platform C

Platform C can be programmed in all languages, with Ladder Logic being very popular. In Europe, the instruction list, or statement list (ST), is more dominant. Programmers in Europe who started with the instruction list often question the North American preference for ladder logic. This platform also includes UDTs, which are part of the IEC 61131 specification.

Overview of platform D: 16-bit word-based with unique retentivity

Finally, brand D is also a 16-bit word-based system. Its retentivity is different from the other platforms. It has registers specifically designed to be retentive and others that are not.

Based on the address you’re going to use, you may use an H-type register, which is retentive, and a W register, which is not retentive. If you’re not aware of this and start programming, you might get a surprise when you turn off your process or turn it back on again. All your bits could be unlatched because the system doesn’t remember where you were in the program, as nothing was retentive. Rather than using organizational blocks, functions, and function blocks, this platform utilizes tasks, programs, and sections, each with its own rules. What one brand calls a task might differ from another brand’s definition of a task. Therefore, simply writing a specification that mandates the use of tasks could be interpreted differently depending on who reads it.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.