PLCs "Programmable Logic Controllers" and Structured Text

Factual Questions
1

Four questions about PLC’s or Programmable Logic Controllers and programming them with IEC 61131-3 “structured text”:

  1. Does “structured” refer to “structured programming”, the 70’s development which emphasizes subroutine structures and avoiding the GOTO statement, used by Pascal and Modula-2 and most others since?

  2. Many sources say structured text is most nearly like Pascal but some say it is most nearly like Modula-2. Both languages were developed by Niklaus Wirth, and Modula-2 is approximately like Pascal with the addition of modules. A module is a subroutine with internalized data fields that accomplishes data encapsulation with only predetermined ways of accessing the data outside the module. This is also a feature of object oriented programming. Does structured text programming of PLCs support modules?

  3. Structured text source is, I hear, written and stored as ASCII text. Often, PLCs have an RS232 port used to program the thing. Could it possibly be that they designed PLCs elegantly enough that one could, if one wished, write a structured text program in a text editor, and transfer it to the target PLC with a coms program? I realize a development environment is nice for lots of reasons this question sets aside; I’m just wondering how clean the setup can be if you want.

  4. Suppose a young fella wanted to start learning this field, and his company used Allen Bradley / Rockwell Automation PLCs, which he can get some access to. If he wanted to supplement this learning with other, cheaper brands, perhaps even used or surplus ones, and they supported IEC 61131-3, would he find they all worked similarly enough to make the early learnings reasonably extensible? Or would their compliance and similarity be so perfunctory and even incomplete that this would be more frustrating than educating. Note, the young fella in question figures that hardware details like how they package and sell add on inputs, and the use of the development environment (if he’s using it), would probably differ between brands and year to year, and maybe there are libraries that differ too.

Thanks!

2

I don’t know enough about programming to touch your first two questions. I learned Fortran and Cobol when I was in school and can use structured text programming to troubleshoot equipment but I don’t program with it. Most of the programming I do is using ladder logic.

The big companies like Siemens and Allen-Bradley are big on forcing everyone to use their software. I mostly work with A-B and you need one of their Logix platforms depending on the specific model of PLC being used and some version of RSLinx to talk to the PLC.

From what I’ve seen of other brands they are very similar in terms of the structured text programming. I have four different brands of PLCs in the plant and they are all quite similar in that respect but the programmers don’t use a whole lot of ST programming. Some use it more than others but most of our equipment uses very little structured text. Sometimes the routine for communicating with the HMI is ST but that’s about it. I think if someone were strong with A-B programming they could switch fairly easily to another brand.

For a question like this you may get a better response from this forum. There are a lot of engineers, technicians, and developers there. A lot of experience is available there.

3

I’m not the strongest in Siemens, but if I recall correctly the logic is almost completely backward from A-B and not something easily figured out, even with a strong A-B background, but that could be because of the German programmers.

4

If it’s backwards, it’s those reverse Poles at it again. Hewlett-Packard must have let them out.

God help us if they try to fly. It’s always hell finding a simple Pole in a complex plane.

5

The Siemens programming is hard to work on and especially to troubleshoot because they insist on using Statement List programming where ladder logic is easier to follow. They will use 20 lines where they could have done it in one line with ladder logic.

Things also get backwards sometimes when a system is retrofitted from one brand to the other because Allen-Bradley insists on defining sinking/sourcing modules differently from the rest of the world and the programming gets twisted around to make everything work properly.

6

Absolutely,that’s what i was trying to say. I have been away from that stuff for about five years now and it’s a little foggy. I remember going to Toronto to do a week of Siemens training and scratching my head for the first two days because of statement lists and never complaing about A-B again. lol. It was ok once I got used to it though.

7

1) Does “structured” refer to “structured programming”, the 70’s development which emphasizes subroutine structures and avoiding the GOTO statement, used by Pascal and Modula-2 and most others since?

I don’t know where the name comes from, but the language does support subroutines and is typically programmed using this sort of design philosophy. Like all IEC 61131-3 programming languages, structured text was designed as a way of making the programming a bit more uniform between various PLC vendors. Prior to the IEC 61131-3 standard, different PLCs had different programming languages, some of them variations of something standard like BASIC or C, but some of them were proprietary. It made it more difficult to switch from one PLC to another. Structured text uses a more modern style of programming, and is designed to be much more portable across different PLC platforms.

2) Many sources say structured text is most nearly like Pascal but some say it is most nearly like Modula-2. Both languages were developed by Niklaus Wirth, and Modula-2 is approximately like Pascal with the addition of modules. A module is a subroutine with internalized data fields that accomplishes data encapsulation with only predetermined ways of accessing the data outside the module. This is also a feature of object oriented programming. Does structured text programming of PLCs support modules?

Absolutely. Generally speaking, when you are dealing with a segment of structured text you are working on some small subset of data. Some PLCs are more object oriented than others. Allen Bradley PLCs tend to be the most object oriented, out of the PLCs that I have experience with. Everything in a modern AB PLC is tags and structures, with global data and local encapsulated data. Other PLCs aren’t necessarily as restrictive with respect to limiting your data scope. PLCs vary quite a bit.

3) Structured text source is, I hear, written and stored as ASCII text. Often, PLCs have an RS232 port used to program the thing. Could it possibly be that they designed PLCs elegantly enough that one could, if one wished, write a structured text program in a text editor, and transfer it to the target PLC with a coms program? I realize a development environment is nice for lots of reasons this question sets aside; I’m just wondering how clean the setup can be if you want.

Usually the structured text module has to be compiled within the PLCs development environment.

4) Suppose a young fella wanted to start learning this field, and his company used Allen Bradley / Rockwell Automation PLCs, which he can get some access to. If he wanted to supplement this learning with other, cheaper brands, perhaps even used or surplus ones, and they supported IEC 61131-3, would he find they all worked similarly enough to make the early learnings reasonably extensible? Or would their compliance and similarity be so perfunctory and even incomplete that this would be more frustrating than educating. Note, the young fella in question figures that hardware details like how they package and sell add on inputs, and the use of the development environment (if he’s using it), would probably differ between brands and year to year, and maybe there are libraries that differ too.

The whole point of IEC 61131-3 is to do exactly this. It makes the programming between various brands of PLCs much more uniform so that you don’t have such a steep learning curve when you change from one brand of PLC to another. It also means that generic IEC 61131-3 programming can be taught in schools, and much less on the job training. There are a lot of differences in the details (as evident in the last couple of posts above this one), but once you get the point behind ladder logic, structured text, etc. switching from one vendor to another isn’t that difficult. It’s not like the old days where you had to learn something with a completely different design philosophy from the ground up.

I haven’t looked lately, but it used to be that all of the big guys (Rockwell, Siemens, Modicon, etc) had demo or limited versions of their software which you could download. You wouldn’t be able to run a plant with the free stuff, but you could usually program a built in PLC simulator with it so that you could learn how to use that vendor’s software. A young fella who wants to build up his skills could download software from a bunch of different places and get familiar with all of them.

Structured text has its uses, but most of the real work is done by ladder logic. If you want to get into PLC programming, make sure you learn ladder logic first.

8

Interesting question. I’ve only ever seen ladder logic used in my industry – that goes for competitors that I’ve worked at as well as suppliers. In many, many PLC courses, the instructors have never, ever gone over structured text, other than to mention that it exists.

There were many occasions where I felt that I could handle a PLC problem more elegantly if only I had the ability to use procedural programming, functions, and subroutines! But of course that type of thinking was heavily influenced by my not-too-little experience in computer programming.

In the end, I prefer the company of robots. They each have their varieties of nice, procedural programming languages that make me happy.

9

PLC Software Engineer here.

I have never, outside of proof-of-concept demos or training labs, seen ST in the wild. In fact, I know next to nothing about it and really have no desire to learn. Ladder logic rules the roost, with Function Block a distant second. With AB PLCs (and Control/Compactlogix in particular) the programming software is geared towards FBD and Ladder programming and many useful and time saving features are not available in ST (afaik). (Side Note: An ABB plc I saw awhile ago used only FBD, no ladder logic. We’d never use it because it would cause the technician or electrician to have a heart attack should he ever need to make modifications…)

10

Wow - thanks! This is great.

I used ladder logic quite a bit a while ago, when it was still done with relays, in the early 70’s. It was horrible, and we all told each other that microprocessors would soon get rid of all this. When years later I learned they had made microprocessor programming tools imitate the relays, I could hardly believe my ears. I’d rather drive my car with reins. I’m sure they have done some things to improve it, but when an AB engineer working in our plant mentioned that he knows they have a bunch of scientist types using their PLCs, and that they all like structured text, I was filled with inexpressible longing, etc etc.

Actually, I should ask: SHOULD I be interested in PLC’s? I just finished a year and a half programming a big machine with LabVIEW and think of the whole experience as a dark and life-changing event, like being displaced during a revolution or something. I still get calls every time some anonymous program interrupts an expensive test to try to sell whoever’s standing at the screen additional goods and services. I want a simple computer that is running the program I wrote, and is easy to interface to hardware, and I want tools that don’t upgrade themselves into incompatibility and melt in my hands every few months. I think the kind of power that 286-processor PCs had could be enough - a million times faster than a person who never eats or sleeps or makes mistakes. Are PLC’s my future? Balthisar, what kind of computers are in robots? Tell tell tell me more about their happy procedural programming languages. Any chance FORTH is one? But interested in either case!

11

It sounds to me like you should get into the field of embedded processors, not PLCs.

Robots can have a simple single chip “brain” like a PIC microcontroller, or they can be PLC controlled, or they can have an embedded computer or sometimes even a regular desktop type computer controlling them. It all depends on the robot.

The nice thing about embedded computers and controllers is they are powerful enough these days to run a fairly full version of linux off of a flash disk. You have full control of the software, plus you’ve got all of the features of an OS available to you. The development environments for linux embedded boards these days is excellent.

12

(Hopefully context has indicated I’m referring to proper industrial robots here, not those toys they’re always talking about in Japan.)
The languages are kind of dumbed down, and every robot has its own propriety language, with different features. Like a PLC, “variables” are global common registers similar to PLC integer files. Depending on the robot, there are CALLS and GOTOS. There’s no standard to speak off. Heck, even some robots from the same manufacturer have language flavors that differ depending on the intended application (say, material handling versus GMAW welding), although the basics will be the same. I appreciate the fact that it’s universally top down programming with branching and complex comparison statements. Mostly what I’ve used is Brown-Boveri, ABB S2/S3/S4, Fanuc, Kawasaki, and Kuka – once you know one, the learning curve for any of them is very easy, despite the different languages and philosophies.

As for what “computer” they have, it’s all proprietary, too, although there’s an optional Windows HMI for the late model ABB’s, and I think all of the Kukas now use a Windows-based HMI, but I don’t really count those as being a part of the robot.

13

It wasn’t too long ago that all of our motion control was done in ST but, as you say, ControlLogix has changed things greatly. Now the motion control is a lot more accessible to the technicians in the plant. Even if modifications aren’t often needed it’s much easier to troubleshoot equipment with the newer PLCs that also handle motion control along with the regular I/O.

This is the only thing I don’t like about *Giddings & Lewis *PLCs. They work fine but there’s too much of a learning curve for the techs in the plant on the occasions when changes are required. They’re not as intuitive as other controllers. They are reliable though, at least the ones we use have been.

14

Thanks, folks.

BTW, I worried for the last few hours that my appraisal of ladder logic could come off as pretty hostile to fans of the same, and I didn’t intend to snub anybody who is, after all, answering my plea for help in the first place.

Balthisar, I was picturing industrial assembly line robots that look like one giant blue arm reaching out of the plant floor with a spot welder or whatever. And the big tin version of the Michelin Rubber Man, the one from Lost in Space, crossed my mind too, but not as a plausible option for what you work with. I didn’t think of any toys. But, actually, since they incorporate various possible actions and some kind of programmability, creating them must actually be a bigger programming job than applying PLCs, no? Your writing style, in any case, is too advanced for end users of any robots less than a meter tall and with eyes painted on.

So, e_c_g, I always thought of embedded programming as involving design-your-own PCBs and deciding between Z-80s and 8051s, or maybe ordering some PICs and buying a softback book entitled “PIC’in Your Way Around” at Borders. I see the little PC104 boards and figure they’re some kind of really small Personal Computer, and idly wondered how you attach a mouse to one so you can get it to start running the control program in the first place. I am sadly ignorant, in other words, of the whole field; the last product I had anything to do with designing that did any computing was based on cards of 7400 series DIP packages in a card cage the size of a shoebox. Suppose I am ready to fall in love again, or ready for further punishment. Where do I go first? In particular, if I like elegant and stable more than I like early adoption and graphical programming, is there any special direction to favor???

Thanks, all, this is manna…