Read the full transcript below
David Greenfield: Welcome to the Automation World Gets Your Questions Answered podcast, where we connect with industry experts to get the answers you need about industrial automation technologies. And you can find even more answers by subscribing to automation world at Subscribe AutomationWorld.com
I'm David Greenfield, Director of Content for Automation World. And the question we'll be answering in this episode is how to evaluate PLC programming languages. And joining me to answer this question is Doug Yerger, Principal Engineer at Grantek an industrial automation system integrator. So thanks for joining me here today, Doug.
Doug Yerger: Thank you, David, for having me.
David Greenfield: So, so let's start off just with the understanding that there's two basic types of PLC programming languages, the textual where you program with typed out commands and graphical where you arrange logic sequences by moving objects around in the programming environment. So let's start by looking at the textual languages, what are the main differences from your point of view between instruction list and structured text? And why would a user prefer one over the other?
Doug Yerger: Okay, I guess let's start with a little description of the two languages, um, instruction list is comparing it to a computer science type background would be an assembly language, it's a very low level language mnemonic based. And, and I guess I should point out that it's actually deprecated in IEC 61131-3, and will probably not be in the next version of the standard according to the standard itself. Structured text, that's going to look more like your high level language, whether it's C or Python, or depending on the implementation. So that's gonna have your four loops and your if/or/then case statements and things like that. So it's gonna be a higher level language version of the instruction list, which gets in the puts in the very low level language. So those are the that's a description of the languages and their types. And why would one prefer one over the other structure text? If you're coming from a computer science background, it's going to be very native field for you. So that's a good reason why someone's going to want to look at that one. It's also going to be very good and powerful for doing things like looping and doing string manipulation. And if you have to parse barcodes and strip out the ASCII characters and things like that, that's so much easier to do in a high level language than trying to do it in ladder logic, where you're going to be dealing with each byte individually.
The instruction list is where that's going to be have its power is because it's a low level language, it's going to be very, very fast, if programmed effectively. The big drawback there is it's a very low level language. So you, you're dealing with memory and stuff very directly and have to keep track and be very, very detailed. So personally, myself, and talking with my peers in our company, noone's actually seen instruction list actually utilized in any of our projects; we stick to structure text in the other languages.
David Greenfield: So out of curiosity, because I didn't realize that IEC might be considering dropping instruction list: Do you have any insights from your side into why that might be? Is it just because it's so low level that nobody's really using it? Are there other reasons?
Doug Yerger: Yeah. For the standard, it says that this language is outdated as an assembler-like language, therefore, it is deprecated and will not be contained in the next edition of the standard.
David Greenfield: Interesting. Okay, thanks for clarifying that
Doug Yerger: I think what you'll see in the industry is the controllers and programming and programming software that support it now will continue to support it for quite a number of years, but I don't think you're going to see any additional processors like Rockwell adopting to put it into their product lines if it's a deprecated standard at this point.
David Greenfield: Alright, so let's look at some of the graphical languages that you alluded to in your first response. What are the main differences among those graphical languages which are ladder diagram, function block diagram, and sequential function chart languages? And as we discussed with the textual languages, why would a user prefer one over another?
Doug Yerger: Ladder diagram is usually meant when people talk about relay logic. That's what they're referring to when they're talking on the software side as opposed to hardware relay logic. But if they're referring to ladder logic or relay logic in software, they're talking about the ladder diagram format. And that's what it looks like if you've seen any old school hardware relay logic diagrams, that's what your ladder diagram is going to look like. So it's basically all Boolean math and Boolean decisions, for the most part.
Function block diagram, that's going to obviously be function blocks; it's going to take a series of inputs and give outputs based on those inputs, and you're going to arrange different function blocks together. Some function blocks will be simple. Sequential function chart is kind of the oddball of the five languages and that it's, we don't view it as a language in itself, it's a structure of the flow of the logic, because it's going to allow for branching into parallel processes—decision points based on condition. But basically, there's an action item at each block. And each action can have series of events on it. And the events are going to be what actually happens in each of those action blocks. And the events will probably be programmed in ladder from the structured text function blocks, so they're going to actually be done in one of the other languages. And it's controlling the flow saying, Do this and wait until this condition is met. And just keep doing that until those conditions met. And then it's going to keep parsing down the program flow that way. So that's where it's a little different than the other languages. And
now, why would you use one over the other sequential function chart, once again, it's that program flow, what it's great for is what we often refer to as it'd be like a state that a state machine at our, if you want to call it a stepped or discrete sequencing.
A classic example would be a batching engine, where you're going to say, Okay, you're going to add ingredients, when you might have three ingredients adding together, so they're gonna be three parallel branches. But you're not going to turn on an agitator until all three of them are complete. So you're going to have this series of steps that need to happen, some parallel, some sequential, where it's going to work its way down and wait for the conditions between them. When you get to using following my example of the agitation, once you get to that step, running that agitator and driving the motors might be done in ladder diagram, like you're going to jump to the ladder diagram, control the motor for however many seconds and it's going to look to trigger the sequential function charts running in a separate process there; when it sees the trigger of the agitations done, it's going to move on to the next action in the sequence. So that's what that one's good for ladder diagram. Here in North America, you're gonna see probably over 90% of your programming done in ladder. It's great for discrete logic systems, meaning if it's a whole bunch of Boolean algebra, which, if you have a lot of limit switches, and on/offs and things like that, it's going to be great for that. It's very easy for electricians to understand because they're coming from that hardware reading. Doing relays, especially older, more experienced electricians just because they've been through all the starting with all the old mechanical relays, growing through the introduction of PLCs in the 70s and 80s. And continuing through today, with everything being automated, they've seen that progression, and they're still very familiar with that. The newer technicians that have learned C or other high level ones are probably going to lean toward that structure text, just because it's more familiar to where they're coming from. Function block diagram, where they excel at is what we call process blocks are continuous process where you're taking an analog input and you're scaling it. Function block is great for that a PID Loop. So you can have all those individual faceplates. That's where we see basically tying into the faceplate that you're going to have on your pop up on your HMI. We've also seen function blocks used quite extensively for things that have latches and unlatches. And just some tie backs on those, there are several safety systems that use function blocks solely as their programming methods. So they're out there, they're well used and usually, as you're kind of seeing by my descriptions here, we typically don't have a program that has just purely one type, we might have one that's only a ladder. But typically, if it's a large program, we're going to have routines and programs in them that use a variety of them, the majority might be in ladder, but if we have a big array processing to do, we're gonna have a structure texture tuned to handle those arrays. We're not going to stick to just one unless, of course our customer has that requirement. There are a number of customers out there that do say ladder only, we usually try and talk them out of that and moving to a little more modern philosophy of using the right tool for the job. But some of them do have that requirement.
David Greenfield: There are preferences Absolutely. Based on I guess a lot of that has to do with what their staff is trained to work on and what they're more familiar with. I imagine that comes into some of that decision process as well.
Doug Yerger: Yes, I worked with a company one time very briefly, and they were 100% structured text. That was over 10 years ago. So it was quite a quite an interesting philosophy to have adopted already back then.
David Greenfield: So looking at across all five of these IEC 611 31 PLC programming languages. Why would a user or would a user prefer a textual language over graphical one? I mean, I can see the appeal of the graphical ones for all the various reasons that you've mentioned as well as others. But is there a reason to prefer textual over graphical or vice versa?
Doug Yerger: For engineers, and I'll even say technicians for that point, are a very graphical bunch. One article I read asked: Can you explain something without a piece of paper and a pencil?
So it's kind of like, well, no, I don't know if I could actually do that. It's all about being very graphical. And also, from a troubleshooting standpoint, if you do have that discrete system that we were talking about, where ladder logic comes in it makes it very easy to see where that process is going and to see where that process flow is. Same thing as in my example of a batching sequence. Using a sequential function chart, you can see very quickly where your batches and where a step might be held up very quickly in that graphical language.
I don't know if I'd ever program everything 100% in a textual language, because as you it's very difficult to see where is the process held up using a structured text language, because you're looking through all the if statements and trying to figure out which if statement is not executing right now and passing the program through, though it can be done. And they've added quite a number of great tools there. But it's still not doesn't seem as intuitive to see what's blocking things as the graphical languages because they're designed around showing that process flow very quickly.
David Greenfield: Okay, understood. Thanks for that explanation there. So the introduction of programmable automation controllers for more complex automation tasks, expanded the realm of controller languages to go beyond the IEC 61131 languages and get into languages more connected with the IT world such as C and C+. Are you seeing these programming languages use more and control operations with the Programmable Automation controllers and industrial PCs? Or do users still tend to prefer the IEC 611 31 languages?
Doug Yerger: There was a big push a number of years ago of bringing in those C programming languages to the plant floor. What's been our experience at Grantek is that we've seen those fade away again in favor of the IEC languages. But where we're seeing those languages still be very prevalent is moving out of the that programmable controller level and moving into the SCADA system. Whereas if we need to do high level C, or Python processing, or even Java processing, we're going to take it up to the SCADA level, do it actually on computer hardware that has all that power designed specifically for those languages, and then move it back down to that automation level from there as opposed to actually doing it in the automation level.
David Greenfield: So it seems like, especially the graphical languages, are still holding on and look to be used beyond just the near term and some time. I that a correct assessment?
Doug Yerger: I think that's a very correct assessment. And I think if we're going to look at the future of what might fade away, But I think structured text would be the one they would replace first, since they basically are one of those other languages, just in the PLC mindset.
So I think that would be the first place we might see it coming into play and saying, oh, instead of structured text we're gonna allow you to use pure C syntax versus our old school syntax for structured text, which they're very similar. But of course, even C compilers have slightly different between them. So there are they were synchronicities between them all. But they might go to a more standard one on that first, before going to a full C ladders, I think they’re gonna be around for a very long time. And sequential function charts just because they're very powerful. Block diagrams have great, great uses as well. And they all have their goals in life have what they were designed to fulfill, and the multipurpose languages like C and Python, and that aren't going to fill that niche quite as well. So I think they're going to be around for quite a while.
David Greenfield: So we've covered these programming languages in a fairly decent amount of detail here in our discussion here, But I was wondering, are there any final thoughts on evaluating controller programming languages that our listeners should keep in mind as they assess new controller options?
Doug Yerger: Break down the functions that you're looking at doing and decide which ones make the best sense for what you're trying to accomplish. But also looking at who's going to be maintaining it and what their technology levels are.
David Greenfield: Well, thank you for joining me for this podcast, Doug. And thanks, of course, to all of our listeners. And please keep watching this space for more installments of Automation World Gets Your Questions Answered. And remember that you can find us online at AutomationWorld.com. And subscribe to our print magazine at SubscribeAW.com to stay on top of the latest industrial automation technology insights, trends, and news.
