Ladder Logic vs C++: Why PLC Programmers Still Choose Ladder and Why They Are Right

How's it going everyone? Welcome to this week's discussion on a variety of different industrial automation and manufacturing topics, which we will be looking at based on the highest upvoted questions on a specific subreddit.

Before we dive into that, I do want to make a brief announcement. I will be at the Ignition Community Conference, which takes place in Sacramento in the late of September, and therefore I am working on an interesting build. There's new toys at the Joltek headquarters, and here, as you can see on your screen if you're watching this in video form, I will explain in audio for those that aren't. I have the new Opto 22 groov RIO. This is the second version, which has been expanded to accommodate a variety of different hardware features, which ultimately allows it to run specific software. I am building a demo for ICC, so if you will be there, make sure to send me a note either on LinkedIn or on YouTube. It would be my pleasure to find some time to connect, talk about manufacturing, talk about automation, talk about Ignition and any other solutions in our space.

Without any further delay, let's get into some of the questions and comments.

A Siemens S7-1500 and Danfoss commissioning panel

Panel builds continue to remain a highly upvoted topic. People are obviously doing the actual work in our industry, so it's always a pleasure to look at a nice panel, give a couple of comments, talk about the workplace for those that haven't experienced this yet, or perhaps are looking to get some feedback on what they are currently doing in their own domains.

This post comes from the username Salvurian, and they say, "My office for the coming days. Siemens S7-1500 PLC, couple of Danfoss FC 302 and Danfoss IC7 drives." If we click the image we should be able to locate the PLC. The zoom, for whatever reason on Reddit, is not the best, so it seems that this is the maximum resolution that we're going to get.

The PLC is going to be on the left hand side, or I guess to the middle of the entire big panel. So that's going to be it right there. We do have a switch, which seems like it is going to all of those drives that are then daisy chained. And we have two flavors of Danfoss drives as mentioned in the post. We have some I/O points here as well. It seems that some of it is connected, I would assume. We don't see much more of the panel than that. There should be more cables in maybe some of these wire trays, or perhaps it's just the power cables that are currently lying there. It seems that all the drives have their cables installed.

The user also comments on the workplace, so we see the typical foldable table that is put either in front of the panels or on the side of the panels, and that is something you can expect to work out of if you're on the commissioning side of some of these systems. We have an extension cord, and this is a European style. Some of the signs are the Siemens presence as well as the Danfoss drives. You typically see a lot more Rockwell systems in North America.

On the second image we have the same electrical panel just from a different angle, so not a whole lot of different comments to be made here. If you haven't been in this environment, this is typically what you would see if you're commissioning this type of equipment. We now see all of the other cables, which are very neatly positioned on the right hand side of the panel.

Very good job on whoever designed this panel. There's nothing really to say. It seems that all the wire trays are in place. We have the nice lights that allow you to troubleshoot and see what's going on inside very easily. We have the power adapter, which is a nice touch for those that want to plug in a laptop or plug in any sort of appliance that is related to control systems. We do have nice vents. I'm not sure that there's a cooling system. Could be something that is either considered or maybe missing on the left hand side that we can't see of the panel. Other than that, great post. Love to see this. Interesting always to see what kind of builds are going on. It's hard to ask for drawings, but it would be cool to see what goes into these panels as well as what is outside, connected in the field.

Here we can see the wire tray from the I/O points removed. We can't really zoom in to identify what is what, but I'm assuming there's a lot of digital and a lot of analog in and outs. There's a few of what I believe to be safety, maybe it's safety relays, maybe it's just regular relays. They are red, but they seem to be floating ice cube relays here next to the I/O as well as the bottom.

First month as a control engineer

The second question that we have today warrants a bit of a story. We'll read the question first, and then I'll talk about some of my early days as a control systems engineer.

This was posted by the username Cambias Rabajadas, and they say, "First month as a control engineer. It's been the longest month of my entire life. When I think I understood something, there's always something else that comes out that makes me realize that I don't know nothing. It's hard to learn everything about each product that you can connect to a PLC. YouTube has been my greatest ally, and the boss keeps asking me that he thinks it's easy, but it's so hard to program. I just need to keep going. Wish me luck."

Switching back to myself a little bit to give you a story as to how I joined Procter and Gamble, and this is public information, it is posted on my LinkedIn profile. I was hired by Procter and Gamble, and I started in April two thousand and fourteen, which is when I relocated to the site in Maine.

My first week, what was happening is that the site was installing a new production line, and they were through the process of bringing in basically packaging equipment. So it wasn't the process side, it was more packaging. I still remember that the case packer that was going in came from Germany, a company called Schubert, and this was a very particular piece of equipment for a couple of reasons. This specific piece of equipment was the only asset in that facility, and in the grand scheme of things I don't want to say it's the only asset at P&G, but one of the only assets that was very heavy on the Siemens side.

Being a German company, Schubert has designed their case packers to be utilizing the S7-1500 series of PLCs, which communicated with the rest of the line, which was on the Rockwell side and a ton of different ControlLogix PLCs. Not to get into the architecture way too deep, but I still remember my first week, and I mentioned this in previous comments, I knew nothing about PLCs. I knew nothing about drives. I knew very little about control systems from a theoretical standpoint based on my lectures in electrical engineering.

What I was tasked with that first week is helping out with commissioning of the case packer. The engineer that was leading that specific project at the time had me do a variety of tasks that one would seem to be mundane, but ultimately allowed me to understand the standards for P&G, but also how systems needed to be commissioned.

I participated in making sure the cables from the machine are run to some of the other panels. The machine sold by the machine builder or OEM was a standalone piece of equipment, but it needed to communicate to other networks. It needed to send handshakes to other pieces of equipment. It needed to be put on the safety of the entire manufacturing line. It needed to be added to DeviceNet and ControlNet. So there was a lot of moving pieces, even when you look at something as simple as wiring, you needed to make sure that the checks are correct.

Commissioning sequence: voltages, grounding, dry run

We did a lot of documentation as part of a very regulated environment. We needed to go through and verify the voltages. We needed to go through and verify any grounding faults. We needed to make sure before we power on the machine that all those checks are satisfied, then apply the voltage, then do further checks, then start the dry run, which means just cycling the motors, making sure that everything is as expected, loading the software, then validating component by component up until actual packages are sent through and product is being delivered.

I still remember being extremely overwhelmed. I felt the exact same way as this individual because there's a lot of different disciplines to touch. There's software, there's hardware, there's wiring, and we had really good diagrams but at the end of the day I had not read diagrams in that specific format coming out of the university and landing my first job in automation and controls. So it was a quite significant learning curve.

What I would encourage everyone is to understand that when you're in that position, a lot of times your management will seem like they don't necessarily understand what you're dealing with, but the reality is they do, and they will push you to the point of, I don't want to say failure, but they will push you to the point where you're learning. You're obviously maybe having some small discomfort. You're maybe making some mistakes, but you're learning through that process, and they will hopefully protect you when it comes to making the biggest mistakes, so if there are any challenges that they don't believe you will overcome, they will pull you back and make sure that you are successful in the job. And if you do make some mistakes on the wiring side, maybe the programming side, they generally understand that those mistakes are not going to be critical to the overall system, but they still want you to experience that success or even failure because it will allow you to grow as a control systems engineer.

Vendors, OEMs and integrators as real resources

The person mentioned YouTube as being a great ally. At the time there were very few tutorials on YouTube, which was one of the reasons why I remember starting SolisPLC back in two thousand and seventeen or two thousand and eighteen and creating some of that content, because I simply could not find how to program a VFD, how to troubleshoot a servo drive. So I started creating some of that content myself.

That being said, my resources have been the engineers and my boss at the site. Both of them had a lot of years of experience and were tremendously knowledgeable on the technical side. They had also brought in most of the equipment, so they understood everything at a very technical level.

Number two, and this is going to be different from site to site, but I would also use Rockwell as a resource. The site was paying for on call service twenty four seven, so if I needed to reach out and get some information, it was always or usually available. The same goes about the OEM or machine builder. I talked a little bit about Schubert. We had equipment from very different manufacturers. Having the relationship and reaching out to them was extremely beneficial.

To be honest with you, I had not realized the value of those relationships until much later in my career. What I would recommend younger engineers do nowadays is don't waste your time always trying to find a solution on your own. Make sure that the machine builder, the OEM, or the systems integrator, even a partner that may be working with you at the site, is involved, is helping you in some way, and you build that trust, you build that relationship so that when a larger problem comes up you can lean in on them to pull in some of their resources as well, and obviously incur a lot less downtime, have a lot less stress, and be more confident in solving some of those problems.

A home test rig with Siemens, Schneider Electric and WAGO

The next question, or I would say more of a comment that we have, is around a test rig. I would recommend anyone that is working in our industry to invest in your learning opportunities and to build out, if your employer does not allow you to have access to some PLCs, some hardware, maybe some IPCs, to build something like this on your own, because you can test in an environment that isn't going to risk bringing down production.

This post comes from the username severeuse3491, and they say, "My test rig from home with Siemens PLC, Schneider Electric PLC, and WAGO Compact Controller 100." If we click on the image we can zoom in. In this case they have provided something of greater resolution. On the left hand side we have the Siemens S7-1500 series PLC, so very similar to what I have on the shelf behind me. If you haven't seen this already, this is an example of the Siemens S7-1500 PLC. In this case I have one input and one output module that communicates via the backplane.

For this user there is an ET 200SP module, which is missing a card on the right hand side, but is remote I/O from a Siemens standpoint. We then have a Schneider as well as a WAGO, and here if I scroll up a little bit we will notice that the Schneider PLC is not on the network while the WAGO is. I'm not sure what the demo or test bench is currently doing, but we do have some of the devices on the network and the other ones aren't. Maybe he's connecting directly to the PLCs. Maybe there is some cross communication, but all of that is of course possible.

We do have some power supplies here as well. Not sure why there's so many of them, but I would assume that all of this is going down from 110, and if it's in Europe, which could be the case because of the Siemens presence, maybe 240 is the voltage. Here I can't necessarily see that well, the image is a little bit blurry, but this is being stepped down to 24 volts DC I would assume.

We have a Pilz safety relay. Very typical. It is not wired in. We have an unmanaged Ethernet switch is what I would assume this is. I don't think this is a managed option. Last but not least we have this interesting module. I have never seen this in the field. It says that it is a SIMATIC HMI. I would assume that there's maybe a screen that this talks to. I don't know what's under this connector on the very bottom, but interesting setup. I will have to do a little bit more research as to what this device actually is.

We have some push buttons that are going to terminals. It looks like it's wired in most of the I/O into the Schneider PLC. I don't think any of it goes back to the Siemens side. These are only 24 volt pins on the remote I/O. We do have the power coming in into the power supplies, and everything looks relatively neat. We've got some nice crimped terminations going into the terminals, so applause to whoever designed this specific rig. We also see nice wire trays. In some of my builds I'm going to spare the space of the wire trays, but if you're looking to make this neat, that is definitely the way to go.

Why PLC programmers use ladder logic instead of C++

Next we have a very recurring and topical question around ladder logic. I've made a separate video, and many of you probably know that a lot of software related jobs have been impacted by layoffs, whether that's because of AI, whether that's because of over hiring during the COVID times, which is obviously a separate discussion. But the point is that a lot of software engineers or computer science majors are looking to understand our field better, but also trying to understand what are some of the opportunities in terms of careers and employment there for them.

We do have a question that is very topical and interesting from the username NationalLink5606, and they say, "Computer science programmers, why do PLC programmers use ladder? I'm seeing some comp science guys asking about controls, so just a Mr. Obvious comment here. Ladder logic is the de facto PLC programming language because it is, or was, designed to read like an electrical schematic top to bottom, right to left, and this is what electricians and electrical techs are trained to use for troubleshooting electrical panels, equipment, relay logic, which was the way they had before PLCs, banks and banks of relays wired through each other's normally open and normally closed contacts, which change state as relay coils energize and de-energize, and finding a wire break was enough to drive you insane.

Yes, ladder logic is an interpreted language, so it's not as memory efficient or elegant as C++ or C#, but I want you to think very carefully about every meaning of the expression 'just because you can does not mean you should' before you decide to show off your amazing coding skills coding function blocks in C++, which is technically possible, but in many cases extremely ill advised.

The technicians can troubleshoot functions and blocks written in ladder logic. Did you stop and think about how easy it would be for someone with only your compiled C++ blocks to attempt to trace a fault? Your code in anything but ladder logic, you get to be the one at 3:00 AM driving down to the plant to troubleshoot your super efficient code because the industrial maintenance techs certainly aren't going to know how. But hey, if you believe sleep is overrated and love sleeping in the factory, then knock yourself out with compiled blocks."

I have a couple of thoughts on this front. I have a less cynical approach to any of this, and what I generally mean by that is it's not because the technicians cannot troubleshoot C++ or Python or whatever. I've met some incredibly talented technicians that knew how to program better than most engineers.

However, the challenge is when you start designing logic and when you have an electrical background, and as you mentioned a little bit but I think this point was under emphasized, when you start reading electrical diagrams and you know that they are very linear, and even if they're not laid out as a ladder, so this is the old school ladder diagram which is still being released today, so it's not to say that those designs are not making it out to the plant floor. But in most cases they're drawn a little bit differently. However, when you logically look at the process that control systems need to control, you will typically have a lot more Boolean logic than you would anything else.

Boolean logic and state conditions, the real answer

What that creates is, if you look at languages, and I studied in C++ so I understand classes, I understand object oriented programming, I understand pointers, inheritance, and all sorts of advanced features, none of which are applicable to base control systems. There's of course an argument to be made if you're working on some kind of a data application or maybe you're trying to program an MES type of a view next to your PLC. That could be written in C++ or JavaScript or Rust, depending on how efficient you want to get.

But in true control system fashion, when you have if I press this button, I need this motor to start. The motor needs to stop when you have a fault. The motor needs to speed up when the sensor is made. All of that is Boolean logic, and Boolean logic I would argue has the most presence in control systems. You have different state conditions, and so if you're going to compare apples to apples, it is very easy to visualize all of the Boolean logic in ladder as opposed to structured text or C++ or Python format.

Of course if you're using PLC IDEs, they make it easier, so you can see if you for example highlight a specific variable, you can see the current state of the variable. But once again, remember the emphasis on basic Boolean logic and state diagrams as opposed to complex chunks or functions of code which are very difficult to visualize, not only for technicians, even for engineers.

If you start deploying complex systems, if you ever worked in pharma, if you worked in FDA regulated environments, you will have a ton of conditions. If you have this valve that needs to be open, it needs to be based on ten different conditions. Once again this is a Boolean sequence where it needs to be, for example, an AND gate, an OR gate, a NAND gate, so there's a lot of those sequences that are a lot better visible in ladder logic as opposed to creating if, else if switch statements, which have their place, but are very limited in visibility in terms of when you're troubleshooting some of the equipment.

So I think going back and actually deploying some of those systems allows you to realize why ladder logic is just better visually suited for these types of environments, because of their, I don't want to say basic nature, but because of their physical and mechanical nature, as opposed to software that's for example running on your phone where you have a lot more permutations, you have a lot more visuals that you need to interact with.

There is a distinction, and my personal opinion, if someone's arguing against ladder logic and they believe that the better approach is by writing that same code in C++ or JavaScript, they're missing the bigger picture. Number one, they both compile to assembly. Anything that you can do, maybe outside of a couple of percentage points, everything you can do in C++ or JavaScript or Java versus ladder logic, or let's say structured text versus ladder logic, you can do in both languages. You can accomplish, if you need for loops, if you need AOIs or function blocks, you can create them in ladder logic. So it really is just a visual representation of the software to make it easier to work with electrical or physical mechanical systems.

Of course, yes, there's the element that somebody wanted to have this representation because of the ladder blocks, but I would argue it is more than that. My point here is that you should not be afraid of learning ladder logic, and it's very easy to translate, especially with some of the new tools with AI. If you're using Claude Code or even if you're using ChatGPT, you can paste ladder logic and you can understand the sequence of events. Similarly, you can give it structured text or software and then compile it in ladder logic depending on your IDE of choice. So it should no longer be a barrier for you to say we're going to use one of the other languages or ladder logic. But you need to think of the people troubleshooting this equipment in the time of need.

An AutomationDirect CLICK pump station

We're looking at yet another panel in this next post. A lot of these get upvoted. People get excited by seeing different hardware and software solutions, rightfully so in our space, because ultimately this is what it all boils down to. You spend a lot of time designing something in AutoCAD Electrical, in EPLAN, before it gets built and put on the plant floor to ultimately run physical machines.

This panel comes from the username Hypernut79, and they say, "My first PLC experience. Very lucky to work for an employer who allows me time to research, learn, and then run with ideas. It's not perfect, but it works, and there are definitely some things I would do different if I had to do it again. The unit runs well, pumps that fill two different ponds. There are two PLCs connected remotely. One runs a third pump not hooked up yet. The other sends pond level inputs for the second pond. Before this, I did have some experience with industrial controls, and I've installed and hooked up external wiring to a fairly large system before. This is my first design build, though."

We do have some images, and if I click on the first one we'll notice that he's using the AutomationDirect CLICK line of PLCs. This is, for those who are unfamiliar with AutomationDirect, basically the cheapest option you have when it comes to PLCs, not only within the AutomationDirect lineup but also in general. Last time I purchased one of these units, if I'm not mistaken, it was something around one hundred and twenty dollars. And I say it's generally the cheapest maybe in North America. I'm sure you could do PLC and logic using an Arduino or Raspberry Pi, but that's a different conversation.

We have a couple of input and output blocks. We have three of them. I can't squint well enough to figure out the third one, what that is, but we have two input blocks and we have an output block. I would assume it is discrete or digital, but could also be analog. We have two motor contactors here on the right hand side. For those that are not familiar, this is going to be for your typically three phase VFDs, which is what he described as the pump station. We have also the check for the contactor being actually pulled in, which comes back as a signal to the PLC.

I'm not sure what this peripheral is. Could be interesting to learn a little bit more. It doesn't look like a safety relay, but it does have a couple of wires probably going to the motor. Maybe it's what allows it to go forward and reverse. Remains to be seen. We have some fuses. We have some relays from which we can tell some of the outputs or the inputs are being energized or de-energized. We have a 110 outlet, which is always a nice touch. We have a 110 to 24 VDC power supply, and we have some fuse blocks for the pumps, so we have three phase pumps as he mentioned, and that's going out to the field.

Let's see what else we've got. We've got an AutomationDirect HMI system, which is also on an Ethernet based network. Very nice. We have some push buttons on the front of the panel, which we'll maybe see in some other images. Very nicely crimped. We do have the stock ons crimped properly. We have some labels on the wires. This is a general comment, and it's relatively minor, but you want your panels to be touch safe, and usually when you have exposed terminals like that landed on the screws, it is not a good sign. So try to avoid those in the future.

HMI critique: button sizing, colour and label hierarchy

Not sure what his takeaways are. Here's the HMI, and we have pump control on and off on all three pumps. We can see the status. We have a small image as to what the valves look like. It could probably be improved a little bit. My immediate comment is to have maybe the title in the center. It's a little bit strange that the control is on the left hand side like that. I'm also curious, what are the buttons on the panel doing if they're not going to be on and off for the pumps? But let's assume that this is the control.

Number one, I would say make these buttons larger, because I think that the biggest interface with the HMI is going to be turning on and off the pumps, and you have these control navigation buttons that are much larger versus the pumps. I would have to basically be very careful if I'm pressing on and off on each one. So I would definitely make these buttons a lot larger, maybe even in this empty space that we have here. Just a larger start and stop, one underneath the other.

We then have some kind of a pond fill pump selection system. There's manual, there's auto. This is fairly standard. You see the buttons here are much larger, so it's going to be easier to interact with this HMI. But even here, this is a strange design where everything seems to be clustered in this square when you have a full rectangle. So I would just give this a little bit of spacing. These are smaller details I would say.

System status monitor, not a huge fan of this. There's just a lot going on, a lot of different colors. The labels are very small. This is where I would make the space that shows the color smaller, but the label larger, because I want to see what this, for example, what is off, and maybe if I'm in person I will be able to read this a little bit better. But it seems like the fonts are very small on the actual description of the element, and the font where it tells me that it's off but is for some reason green is massive, so again there's a little bit of confusion I would say there.

There's also different shades of blue, which makes me question what the blue means and why is there blue, green, yellow, red. So maybe some kind of a diagram that explains what those states are. They all say off. So there's a label, but there's also the color that is a little bit inconsistent I would say from what I would typically see in the environments.

We then have a photo of the pumps, and I apologize for the video not being able to scroll down enough, but the installation looks super neat. Everything would work as expected. The valves are nice and clean as you would expect, of course, of a new install.

Allen-Bradley PLC-2, PLC-5 and CRT programming terminals

We've got a lot of recurring posts and themes week after week, but this is an interesting one. It is on the historical side of Rockwell Automation. I have certainly seen a lot of these devices still on plant floors. Let's take a look at what this user is saying.

This comes from the username Akamadman203, and they say, "Allen Bradley's early days. Hello folks. What you see here is a wide collection of items I've collected from both my old company and hunting for these, and I display these old machines in an event called VCF West, Vintage Computer Festival. Now that this show is over, I'm looking to go a bit deeper with these PLCs. I'm curious if someone out there is hanging onto some PLC-2/8 machines, or specifically the core memory units and supporting hardware to connect to my racks. Also, this is a bit more of a stretch, but if someone has any original PLC-1 or 1774LA units for sale, both of these would be instrumental in my journey to teach people about the industrial manufacturing process of the '70s and '80s. If you guys have questions or anything about my units I have displayed here, I'm also happy to answer them."

We have a couple of images, and for some reason I can't scroll down, but ultimately we have a laptop that is sitting on top of a Rockwell. I believe this is a PLC-2, if I'm not mistaken. I've not seen many of these in the field. I have seen a lot more PLC-5s. We have a PLC-5. We have a couple of terminals sitting on the left hand side. We have a push button and toggle switch station, which is connected to some of the I/O. A really cool display of history as to what these controllers looked like back then, and still today there's a lot of PLC-5 installations.

I have seen some of these CRT displays at a couple of plants. They are being phased out and removed from production lines, but those HMIs are still very much operational today in some older facilities. Does it make sense to upgrade? That's an entirely different question. I am planning to create a video on modernization or migration, if you will, depending on how you categorize that.

Super interesting to see. On the second image we have a photo of ladder logic on an Allen-Bradley CRT screen that is being maybe programmed or maybe being downloaded to one of those HMIs. Maybe it is an HMI. I, to be honest with you, have not seen something like this very frequently. I know of a couple of plants that have CRT monitors, but they were not used as programming stations. So really cool to see.

We'll close off with this specific question this week. If you have any comments for this gentleman, don't hesitate to reach out. It's on the subreddit. If you have any questions for me, if you would like to talk about industrial automation, manufacturing, if you disagree with some of those comments, if you have some additional context from those posts, please make sure to leave me a comment. Make sure to reach out to me on LinkedIn. If you will be at ICC, the Ignition Community Conference later in September this year, don't hesitate to reach out. It would be my pleasure to meet up in person and discuss anything that is industrial automation, manufacturing or otherwise. In any case, that's all we have for you today. Have a great weekend and we'll see you next time.