Introduction

PLC:s are a form of industrial control hardware that is very rugged in its construction. PLC:s are used to control everything from small packing machines to complete assembly lines in every imaginable industry. There is a sister category of controllers that are called RTU:s, which stands for Remote Terminal Unit. RTU:s are very similar to PLC:s but they are more aimed towards acquisition of data that later gets processed by a supervisory control system known as SCADA. Even though there is small differences between the units they are similar in their construction and many of the functions are interchangeable. The terminology is more a sign that they are built by different companies that historically operated in different industries.

The name, Programmable Logic Controller, gives you a hint of what it is meant for, it is a programmable unit that uses logic to control the physical world. When it comes to automation engineering the main focus is to control, or document, the physical world. But now you might ask your self “Can’t I use a micro-controller for that?” And yes, you can use a micro for that, because inside the PLC unit sits a micro controller that does the actual logic.

What is a Micro-controller?

A micro controller is at its core a rock we tricked in to thinking, or at least we have given it the appearance of thinking. When it comes to AI programming it is really close to actual thinking, as a side note. Don’t underestimate how amazing this is, we had to smash it and put lightning inside it but we succeeded! That is not an original quote by the way but it describes what I want to say really well.

There is a very limited amount of things a micro-controller actually can do. It can perform basic maths. We can tell it to perform comparisons, is THIS the same as THAT. We can give it digital logic instructions, this AND this OR that but NOT this. And it can remember things, but somewhere around here it starts to run out of tricks. It can do a thousand more things but all of them are based on combining these basic things in different ways, in fact the only limit is really your imagination and knowledge.

What is a PLC?

So if there is a micro inside of the PLC that does the actual logic, what is the rest of it? I think the easiest way of describing it is to say that it is an additional hardware layer for interfacing with the microcontroller.

A micro isn’t that rugged and since PLC:s are meant to be used in harsh environments something needs to protect it. Another reason is also that there are several standardized communication protocols used in industrial applications that microcontrollers can’t interface with directly.

+/-10V, 0-20mA, and 4-20mA are some used for analog signals and it isn’t hard to imagine what would happen to your Arduino if you tried to apply 10V to one of its 5V tolerant pins, some other micros can only tolerate 3.3V which would be even worse. When you consider that most digital logic in industrial systems use 24V you realize that the micro itself can’t cut it. Because of this the interface hardware generally have dedicated inputs that are surge-protected to handle both high voltage and current if it is needed. The outputs can source up to a couple of amps each if they are transistor outputs or way more if they are relay outputs with separate power, in that case you can use 240V directly from the unit with no need for any separate relays.

Layout of a PLC

Traditionally PLC:s were either called compact or modular. The compact PLC:s were sold as one unit and all the input/output capabilities it had when you bought it was what you were stuck with. This of course led to problems if you wanted to expand the control system at a later date but you didn’t have any I/O:s left. Modular PLC:s gave a solution, they come with a backplane or some other way of linking several different modules together, which meant as long as you had empty slots on the backplane you could keep adding modules. The downside was, and is, that these were a lot more expensive.

The lines between compact and modular units are today a very blurry. Almost all modern compact PLC:s I’ve seen have some expansion slots, usually 2 or 3 of them, which greatly expands their usefulness and honestly makes them a great option compared to expensive modular systems in many applications. With the rise of industrial Ethernet protocols such as Allen Bradley’s Ethernet/IP and Siemens Profinet, and before that different Modbus protocols, you are almost unlimited in the amount of I/O:s you can have on one compact PLC as long as you have a communication module connected to your unit. There are some limitations, such as the amount of addresses available in a modbus network, but a couple of hundred I/O points is usually enough for most applications. You can compare this to the vast amount of shields you can buy for the Arduino system of Development kits, where each shield adds capability to your microcontroller.

Configuration and programming environment

Each manufacturer of PLC:s have their own software, in some cases you can hardly get a hold of it and in other cases it is free. What most of them have in common is that it is used for much more than only programming the logic. It is here that you set up the networks and define all the addresses and units in the system. Some companies, such as Siemens, have integrated HMI programming in the same software. Siemens are also at the forefront of integrating what they call Technology components directly in their TIA Portal software. These are pulse train modules (another of those communication protocols used in industry), counter modules, position detection, and even artificial intelligence modules.

You can also look at the code as it is executing, and view all the inputs live, directly on your computer. This helps greatly when troubleshooting a new machine or piece of code.

Programming languages

In my mind the biggest difference between a micro and a PLC is the programming, to describe what I mean lets take a step back for a minute. The first way to program a micro was with a parallel programmer and to use the micro controllers dedicated machine code instructions to move actual bits around and tell it which registers to compare to perform different operations. This works but you need to know the micro inside and out to do it, and if you learn how to program one kind of micro you only know that one.

Low level programming languages

This is were Assembly or Assembler code comes into play. This is a low level programming language that is close to the machine code but still more “Human Readable”. The assembly code is then translated into machine code in an assembler, that’s where the name comes from, that is executed by the micro. This was easier to learn than machine code instructions but you were still stuck with a specific micro or computer architecture, there are several assembly languages that only their specific architectur.

High level programming languages

Assembly language is still used is some special situation but have in most cases been replaced by higher level programming languages such as C/C++ and Rust, an example is the very popular Arduino language that is mostly based on C. It is a high level programming language in that it is further away from the hardware, so instead of telling the micro what bits to move where and what registers to use we instead write what we want done. For the untrained eye C code looks really confusing but it is almost as plain text for someone who works with it. To make the code readable for a micro controller however it needs to be translated and this is done by a compiler. The compiler reads the code and decides what bits to store where and what registers to use so you don’t have to. Generally you don’t need to know where a value is stored as long as it is stored where you can retrieve it. Using a higher level language also has the added advantage of being more versatile since you can use it on different micro controller architectures, all you need is a compiler that compiles the code for the architecture on the micro you want to program. So you aren’t as stuck on one specific system.

Grapical programming languages

After these higher level languages comes the languages used to program PLC:s and test equipment such as LabView, the graphical ones. If C code can be explained as “telling” the micro controller what to do, graphical programming can be explained as “showing” the micro controller what to do.

Here you draw lines to show the program how to move data and what values to add and what variable should store which value. Almost like a flow chart. This has the advantage of being quick to program and easy to learn, two things that are valued in industrial applications where time is money. There is a text based language as well, called structured text, but I consider that almost graphical. To write a logical function in C we might write something like this:

(a && b || c) && !d

But in structured text the same function looks like this:

(a AND b OR c) NOT d

I think that is as clear as it can be and still be text based.

Why PLC systems are built like this.

You can of course, if you want to, roll your own controller-board that interfaces all the same signals as a PLC and that can communicate in the same languages, Ethernet, modbus etc, and program it all in C/C++. The hardware would probably be cheaper, atleast for a small to medium sized board. But it has one huge disadvatage. The cost/time for development. I hinted at this in the section about languages, but I wanted to clarify it a bit more.

Almost all consumer products are built the way I mentioned in the first paragraph, a micro sitting on its own motherboard and the entire unit is designed to do one thing, control your dishwasher for example. How many thousands of the same model of dishwasher do think there is? This means that the manufacturer can spread the development cost over a huge number of total units so even if it took 6-12 months to develop the hardware and software combo it doesn’t impact the cost of the final product that much.

For many industrial machines and assembly lines there is only 1 of that specific combination of software and hardware and even if there are more than one the numbers are rarely in the thousands, the tens are more likely. So we essentially speed upp the development by increasing the hardware cost. PLC:are fast to program and troubleshoot, easy to learn and interface with but at the cost of being expensive.

Conclusion

In many ways the intentions that Arduino had when developing their IDE and boards are the same ideas that led to the creation if PLC:s, apart from the ruggedness factor. The system should be easy to learn and use. The hardware should be more or less universal, you should ba able to use it for a vast amount of applications. You should have the abilty to interface via a couple if standardized protocols. There are even a couple of manufacturers that sell industrialized Arduinos for use in process controll but as of this day I have not seen any of them implement the standardized PLC programming languages fully and it is really here that PLC:s stand out.

I have a couple of old PLC:s laying around that I have been thinking about doing something cool with, if you have any ideas please send me an email at offhoursengineering@gmail.com. I will make sure to document the programming in full.

Keep working hard.