A Question from a Newbie

Just a silly question. Why is PLC programming still done with ladder logic? Wouldn't it be WAY better to use a high-level language - you know for following the logic, naming variables and devices, etc. Could someone with way more knowledge about these things explain?

The majority of those using the PLC (both in programming and in using the program to troubleshoot) are not high level programmers. Most are still the plant electrician type. I think ladder logic will be around as long as there are ladder wiring diagrams.

The way I learned to troubleshoot and program was looking at an electrical print and the oldtimer said that blackbox does the same as these relays. I think he was in the ballpark with the young 18 year old kid chomping at the bit just to learn anything he could.

Later in life I did a little research on how and why we use ladder. I found a reference that said the first PLC started using ST to but the union electricians said that is my job to maintain the system we know ladder diagrams. So the Structured Text was replaced with ladder. Is it true I would ASSUME that it is. Can I prove it? No

feenee,

Back in November a editor for Control magazine asked the same question in this thread.
http://www.plctalk.net/qanda/showthread.php?t=42956

Actually now both Text based programing and ladder or both used. One thing that I believe keeps ladder alive is the fact it Gives a very good Interface to how a PLC program actually works.

PLC's run on scans. They start at the top of the program and work their way down (in simplest terms). Most PC based text style are event driven. Hince Text based is best for it.

When it comes to troubleshooting a program it is really hard to beat Ladder.

Ladder makes it alot easier to see what is going on.

Thanks guys. So what you're saying is that it hasn't changed yet because of it's history and the fact that there would have to be a lot of expense and time invested in training large numbers of people in using a hich level compiled language. Given the length of time that PLCs have actually been in use I though it would have changed by now given that the PLC scan is exactly the same as one loop in state machine logic in procedural programming. I just find it hard to go back to cryptic numbering of devices and memory locations. It's basically the same thing as going back to using Assembler.

The history of PLC is to replace the complexity of relay hardwire that use electrical symbol.

feenee said:

Thanks guys. So what you're saying is that it hasn't changed yet because of it's history and the fact that there would have to be a lot of expense and time invested in training large numbers of people in using a hich level compiled language. Given the length of time that PLCs have actually been in use I though it would have changed by now given that the PLC scan is exactly the same as one loop in state machine logic in procedural programming. I just find it hard to go back to cryptic numbering of devices and memory locations. It's basically the same thing as going back to using Assembler.

Click to expand...

I think your missing the point here. a PC and a PLC are NOT the same thing. If your PC locks up you reboot. If your PLC locks up several million dollars of equipment may be damaged and lives put at risk.

The numbering systems in PLC's make it so everything is standarized. The way it scans code does the same thing. Believe it or not it helps prevent alot of problems. Spend some time working on a machine with several 100 I/O and Ladder becomes a nice thing.

Also just for the record. EVERYTHING in PC's or PLC's go back to the asembler. That CPU is still 1's and 0's.

Even Siemens STL which is almost a Text based language uses the RLO ( Return on Logic Operation) Siemens also has some other languages SCL comes to mind that is text base. I think SCL is almost Pascal in form.

Higher languages have their uses but so does Ladder.

Thanks guys,

I guess I'm missing the point. I'm not talking about replacing the reliability of the PLC with something like the PC. I'm just suggesting that a high level language be used to develop the logic rather than more cryptic solutions.

All that is needed is to develop the language (take C for example) with functions designed for the world of the PLC and create a simple compiler to tranlate it into the data and machine code necessary for the PLC. It's really not that difficult. Even Obect Orientation could be built in.

Imagine: A sensor or limit switch detects a fault and by changing its state (in the program) a cascade of events take place to handle the fault effectively - in exactly the same manner as it does now - but with the added benefit of being able to maintain and expand the operation of the system in psuedo-english based text logic.

Am I totally out to lunch?

Where the beauty comes is in troubleshooting. As has been pointed out before, many times Bubba isn't highly educated. But he can look at ladder and see that something is or isn't lit up and make sense of it. For many, troubleshooting ladder is somewhat intuitive. Give Bubba some Pascal-ish code that isn't represented graphically, where all he has is an accumulator value to track the status of his logic, and he'll typically just surrender.

Ladder is still around because it's simple, because it works, and because it's easily understood.

feenee said:

Thanks guys,

lt effectively - in exactly the same manner as it does now - but with the added benefit of being able to maintain and expand the operation of the system in psuedo-english based text logic.

Am I totally out to lunch?

Click to expand...

What is the benefit over looking at rungs in real time?

Siemens uses something similar to what decribe. It is called SCL. Allen Bradley has aversion for the Control Logix's platform.

In both platforms you can do what is known as Symbolic programing. This is where you use names instead of the actual adress. It has it's uses. If your the code writer it makes things easier but for the end user who is trouble shooting the machine, the absolute adressing is handy so you can find where that sensor ties into the plc's I/O.

Think of it this way. You have a machine that fires an solenoid that moves an air cylinder.

You come into work one day and the cylinder is not moving. You get out the electrical drawings and begin looking for the problem. You find that the solenoid is not coming on. You trace that back to an output card and see the output is not turned on. So now you need to know why. So now you go to the program and find the output. In ladder logic this output will be on a rung. you look down the rung to see what is not turned on. You see that a bit is not turned on. So now you find what turns that bit on in your program. This continues until you get to the cause.
In this scenario the ladder style programing wins hands down.

Ok now lets say you have a reactor. In this reactor you are combining 2 chemicals at specifi ratios to create an end product. You have variables like heat, flow, pressure that enteract with each other. Reactor controls start going out of range, You know it has to be in your variable controls. So you get online and start looking at how these are working with each other, cascaded PID loop tuned wrong and causing an oscillating effect

In this scenario the Text based style is going to win hands down.

This what I am refering to as the end user effect. This is also why I believe Ladder will always have a place in programing. For certain types of equipment it will always be the easiest to use.

That said, TExt programing complex functions and making use of higher languages also has it's place. In alot of my programs they reside together anyway.

This is great stuff guys. Thanks for the input. I guess it's just because I've been a programmer for many years that I don't understand why even a simple ladder system can't be better understood using either procedural or object oriented programming - and when I say better understood I mean easier to follow, even for the non electrician/programmer.

If you look at the more advanced plcs,
They use a tag (symbolic) based addressing system,
They allow the programmer to define structures,
and to build user defined function blocks (object orientated programming). For example I create a motor control function block and then create an instance of this block for each motor. The function would be called from ladder or one of the other languages. Inside this block may be a ladder program (or one of the other standard langauges - function block, statement list, structured text or sequential function chart)
And all this programmed and debugged inside a gui allowing real time programming, modification and monitoring using a graphical representation.

So yes it is 'WAY BETTER' to use a high-level language, but that high level language is the plc software already used on the latest plcs

I also program using dotnet, just not for machine control

ps

In this scenario the Text based style is going to win hands down

Click to expand...

personally in a control situation I find function block program far more effective

feenee said:

This is great stuff guys. Thanks for the input. I guess it's just because I've been a programmer for many years that I don't understand why even a simple ladder system can't be better understood using either procedural or object oriented programming - and when I say better understood I mean easier to follow, even for the non electrician/programmer.

Click to expand...

Before I started programming PLCs (in ladder) professionally, I felt much the same. I saw ladder logic as some strange toy (neat to look at but not in the same league with C/C++).
Now I know better. 9 times out of 10, when something goes wrong I can trace it back to the cause without a second thought (online, with the machine running). Even better, I can describe how to do it to a technician or electrician over the phone.

The trouble with compiled high level languages is that it is much more difficult to visualize the state of the machine while it is running.

Every once and a while you get into situations where debugging gets tough (race conditions, etc) but those situations happen in high level languages just as well.