5 Skills Every PLC Programmer Should Have

In this article PLCGurus.NET member and contributor, Tony LeRoy, is back! Get ready as Tony shares what he believes are the 5 essential skills every PLC programmer should have in order to advance their career. It will be interesting to see if you agree with Tony, or have anything to add. If so, be sure to leave Tony a comment at the end of the article…enjoy!

Each time I learn a new programming language, I often find myself asking “What exactly can I do with this, and what else can I learn?” This mostly applies to computer programming languages, but PLC programming was no different for me when I first started. In this article, I am going to explain, in detail, 5 skills every PLC programmer should have, so that they can advance to an intermediate level. You’ve learned about counters, and timers, and possibly even how to move data. Now let’s see what else we can learn!

Skill #1: Know How To Properly Map I/O

I have to give credit to another automation smasher, @Paul Lynn, for teaching me this one. When working with physical I/O, the smartest thing to do is to NEVER use your physical I/O in your control programs. Create either one subroutine, or two subroutines to tie your I/O to memory bits. Use a simple contact tied to a coil on a rung, and create as many rungs as you have I/O.

This may be a bit tedious, but it will save you in the long run. The coils can be XIO or XIC depending on which state your sensor needs to read for the program. Also, if you don’t have a normally open sensor and you use a normally closed one when replacing? Simple. Change the contact in that one spot in the program, and your program will adjust accordingly.

One thing that I recommend is that even if a controller has an instruction that will do this for you, don’t use it. The visualization of the rungs can help troubleshoot and be an aid in fixing issues.

Skill #2: Learn Multiple Languages

There are a few PLC programming languages defined by IEC 61131-3, in fact, PLCGurus.NET did a fairly comprehensive article that covers the various languages defined in the standard. While ladder logic is the most common programming language, you will more than likely run into others in your PLC career.

Learn them ALL

Function Block Diagram is used a good bit as well, and it’s relatively intuitive to read. FBD is like digital logic gates. If you can understand the inputs and outputs, the block performs the function to give an output so that the output can be chained into another input.

5-Skills-Every-PLC Programmer-Should-Have-1
Looking at the function blocks above, we have a function that divides two inputs. The output is then inserted into the next function block. After the second function executes, the number is multiplied by two and stored in the variable “result.”

The last language that I will mention, and I’m seeing used more and more, is structured text. When dealing with Allen Bradley, you’ll often hear “structured text” or “ST,” while when dealing with Siemens, you’ll hear “structured control language” or “SCL.” While they are not the same, they have their similarities.

Both of these languages serve as a medium between a PLC program, and a computer program. ST and SCL look similar to coding languages, with SCL being similar to Pascal. These types of languages are seeing more use because of the power and complex processing capability that they have. The FOR and WHILE loops are useful when working with arrays, and code can be cleaned up by using ST instead of ladder when looping. I use a lot of SCL for lookup tables and sorting algorithms.

Also, keep in mind that there will be certain times that each language will have its pros and cons. Not every language is useful in every situation. I have found that ladder is great for the majority of control schemes, but having these languages in your toolbelt can prove useful when attempting a more complex approach to a problem.

Skill #3: Acquire Networking and Communication Skills

In today’s world, we see more and more ways to send and receive data. Many times, PLCs will need to connect to other devices for diagnostics and controls. To make the two talk to each other, a common networking protocol will have to be established, and the proper connections will have to be made. Most communications are fairly straightforward when implementing them in a system, just as long as the two devices are speaking the same language.

One of the oldest protocols that is a must-know for all controls guys is Modbus RTU. Modbus has been around for over 30 years, and the list of devices that support it is enormous. Modbus is still used all around the world today, even as networking technology evolves. I have used Modbus in a countless number of applications, and it has served me well every time. Modbus RTU is serial communication, but there is also Modbus TCP/IP which is basically the same thing data wise, only it is encased in a TCP wrapper.

Other protocols that are widely used are Profinet (Siemens) and Ethernet/IP (Allen Bradley). While it is nice to understand the backend of how both of these protocols function, it is not necessary to go into great detail with them. As long as you know how to use these protocols in your controllers, and set up communications

to other devices, along with sending messages back and forth, then you will be in good hands. I do recommend exploring the fine details of Modbus, as knowing what details are being sent across the wire will give you a much better appreciation and understanding of communications.

Skill #4: Learn PID and Process Control

Proportional, integral, derivative. Math terms, right? Even scarier. Calculus terms, right? PID loops are incredibly important to process control, and it is essential to understand what they are and to understand what each term is responsible for in the control loop. I would say that it is important to know how to “tune” loops, but only practice on actual applications will help with that. PID tuning is an art.

PID loops are relatively the same through most controllers with multiple variables that can be set adjusted as Kp, Ki, Kd, bias, and sample time. All of these terms are crucial to developing a good, responsive loop without overshoot.

Without going into too much detail, a PID loop is an algorithm that will take an analog input, and try increase or decrease an analog output to a point where a process variable is at a particular setpoint. Many applications for PID loops include heating an oven, building pressure with a pump, keeping a water level in a tank, or even getting a servo to rotate the shaft to the desired setpoint while adjusting for momentum so that it doesn’t overshoot. The loop takes into account disturbances in the process and compensates by changing the output accordingly.

If you want to learn a lot about PID loops and the nitty-gritty of them, then I recommend checking out this article here. Also, be sure to check out the in-depth YouTube series developed right here on PLCGurus.NET as well. Fred does an excellent job showing you how to model, predict and tune the dynamic response of a closed-loop process, leveraging Studio 5000, Studio 5000 Emulate and FactoryTalk View Studio…it’s a great series! Below is the first video in that series to get you started:

Skill #5: Understand Indirect Addressing and Arrays

One skill, among many, that will set you apart as a programmer is knowing the power of indirect addressing. I mentioned earlier that there are different languages that a lot of PLCs have that can provide flexibility to your code. Indirect addressing primarily applies to ladder logic, but when paired with it, the amount of applications that can be used in a ladder-only environment increases exponentially. As a bonus to this article, I will do my best to explain how indirect addressing works in a PLC.

Let’s start off with the age-old example of starting multiple motors up in sequence with a time delay in between them so that the inrush current won’t explode your panel. You could have multiple rungs with the exact same logic on them, which is fine for 4, possibly 5, motors. However, what happens when you need to turn on 12 at a time or even 32? Indirect addressing is your best friend, and with indirect addressing, the task can be accomplished in around three lines of code. Here is how it works.

Another example. Let’s take an address. We will just say B3:0/0 as an example to the older AB model processors in RSLogix500. To make the address dynamic, a “pointer” needs to be added to this address. The way that is done is with brackets. B3:0/[N7:0] will be the new address. Additional information that we need is “What is the value of the pointer?” For simplicity, let’s start with zero. When the scan cycle reads the rung with the indirect address, it looks at the address B3:0/[0] or B3:0/0 and evaluates the logic.

Now, lets increment N7:0 so that now the value of the register is equal to one. Since N7:0 equals one, then the indirect address is now evaluated at B3:0/[1] or B3:0/1, which is a completely different memory bit that is evaluated on the exact same line!!!!

5-Skills-Every-PLC-Programmer-Should-Have-3
A simple indirect addressing program where O:0/0 will come on if the corresponding bit is equal

5-Skills-Every-PLC-Programmer-Should-Have-4

In the example, with just four lines of code, we turned on a light for two seconds while stepping through a B3 file for 16 separate bits. This could be considered a FOR loop, but indirect addressing can be used for much more than that. When referencing multiple arrays, if all the arrays are the same length, and the data that you need to be put together is in the same position, by using indirect addressing both of those pieces can be displayed on an HMI or worked within your code.

One application that I have used as an example is changing the way inputs are arranged. A short one-minute video can be seen with that code in it on my LinkedIn here!

Indirect addressing is powerful but can be confusing at times. Be sure to document every single step of the process you have, and when using indirect addressing, be more in-depth about what is happening in the code, as it can sometimes be difficult to troubleshoot. But to top this article off, be sure to always document ALL of your code very well!