why use structured text and function block over Ladder

[TConnolly]

Ron's picture is an excellent illustration of using the right tool for the job.

A two button basic start/stop control is a good candidate for something to be done in ladder. But if I were going to calculate the volume of material in a frustum shaped tank or parse a string or prescan a recipe to check all the values then I would rather use ST.

After you get the extensions installed and as you become more familiar with the new tools you'll find there are times when you will prefer using one over another.

 

[iant]

Hi Alaric I Agree totally and as I stated earlier =
All programming methods have their uses - Use what ever suits the environment.

 

[WildeKurt]

I do a lot of higher level programming (VB, java, .NET, etc) as well as PLC stuff. I like Structured Text for some things such as math, text manipulation etc. or for repetitive tasks that once debugged are unlikely to change. However, for machine control, etc I like good old ladder logic. Fistly, in AB at least, it's easier to troubleshoot. Additionally, it's easier for our techs. to troubleshoot the machine if basic control is handled in ladder logic. My $0.02 worth.

 

[JHarbin]

I do a lot of higher level programming (VB, java, .NET, etc) as well as PLC stuff. I like Structured Text for some things such as math, text manipulation etc. or for repetitive tasks that once debugged are unlikely to change. However, for machine control, etc I like good old ladder logic. Fistly, in AB at least, it's easier to troubleshoot. Additionally, it's easier for our techs. to troubleshoot the machine if basic control is handled in ladder logic. My $0.02 worth.

I'll add my 2 cents too.

If the logic is programmed correctly and completely, troubleshooting should be a matter of checking to see if inputs and outputs are working. You may say this is simplistic, but I've been both a field technician and a PLC programmer for over 25 years. Once the program is correct, troubleshooting is a breeze.

Believe me, I know that there is a lot more to it than that, but honestly, it doesn't matter what the programming language is, if the program is correct, troubleshooting is easy and if it isn't correct, troubleshooting is hard.

What we need is better programming.

 

[WildeKurt]

In our machines here, a lot of small changes are made over time, mostly to address customer concerns, product quality issues, etc. Usually there are left up to the techs. I agree that the program shouldn't need troubleshooting once a machine is in production. In fact, with modern HMI's, machine faults and such should be painfully obvious. With many of the machines we buy from OEM's this is not the case however.

 

[JHarbin]

In our machines here, a lot of small changes are made over time, mostly to address customer concerns, product quality issues, etc. Usually there are left up to the techs. I agree that the program shouldn't need troubleshooting once a machine is in production. In fact, with modern HMI's, machine faults and such should be painfully obvious. With many of the machines we buy from OEM's this is not the case however.

And where is the OEM programming done?

 

[WildeKurt]

Lot's of different OEM's. Some have a history of what I'd consider good programming: Well structured programs, consistant style, etc. Others just suck.

 

[iant]

OEM's quote jobs, but if it is not fully scoped then it is done cheaply.
simple example only - NOT SPECIFING CORRECT METHODS -
a m/c has 25 stop devices going through safety relays.
Using 1 input in a PLC and 1 alarm msg is the cheapest option.
But 25 Inputs and Programming screen alarms and display take a lot longer.
the price goes up considerably.
It is too late once the machine is at site when the company realises they need all this additional information - and it isn't Scoped.

Apples for Apples

 

[intradave]

My 2 cents.
I've read that the relay ladder logic (RLL) language was essentially forced on the auto industry by the trade unions as a way to keep union electricians employed when factories were automating; as stated earlier, it was so "regular" electricians could understand the programming and enhance maintenance.
Surprisingly, though, it has become a very simple and (dare I say) ELEGANT way to graphically represent logic constructs. Even a moderately trained RLL programmer can very quickly understand the logic controlling machinery. Why this isn't focused on in the schools I have never been able to figure out.
Since it isn't focused on in the schools, most of the "kids" coming into the industry, if given a choice, will naturally gravitate to what is most comfortable to them. In my opinion (I'm old and been doing this for 30 years), there is more and more an industry-wide shift away from the usage of RLL, even when it is the best tailored logic format for the application.
I am experiencing this directly at the present. I am REALLY liking the new Beckhoff products, and have been working with the local Beckhoff programming support guy to learn these products. Problem is, this guy (young guy recently graduated) greatly prefers structured text programming, and I greatly prefer RLL. So when he very kindly sends me program examples for the Beckhoff equipment (usually based on some RLL example) I sent, it takes me more time to interpret the ST code BACK into the RLL. This is actually hurting my ability to implement this equipment (which I like) into my equipment. I don't mind (in fact, rather enjoy) learning the newer techniques, but time is always a factor, so it's taking longer to reach my goal of using this equipment effectively.
I absolutely recognize the proper choice of language to fit the application. BUT, let's give RLL the respect it deserves, and teach the new folks WHERE and WHY it is most effective.

Can I get a "Whoa Bundy" on this?

 

[gmferg]

I absolutely recognize the proper choice of language to fit the application. BUT, let's give RLL the respect it deserves, and teach the new folks WHERE and WHY it is most effective.

When you have at least a little knowledge of all the different programming methods, you are able to choose the best one for the job. Just keep in mind who will need to support it in the future as well. The newbies should learn RLL, it's not just pretty pictures for the simple minded, it's still the best fit in most cases IMO.

Can I get a "Whoa Bundy" on this?

Absolutely agree, "Whooooooaaaa Bundy"

 

[iant]

My 2 cents.
I've read that the relay ladder logic (RLL) language was essentially forced on the auto industry by the trade unions as a way to keep union electricians employed when factories were automating; as stated earlier, it was so "regular" electricians could understand the programming and enhance maintenance.
Surprisingly, though, it has become a very simple and (dare I say) ELEGANT way to graphically represent logic constructs. Even a moderately trained RLL programmer can very quickly understand the logic controlling machinery. Why this isn't focused on in the schools I have never been able to figure out.
Since it isn't focused on in the schools, most of the "kids" coming into the industry, if given a choice, will naturally gravitate to what is most comfortable to them. In my opinion (I'm old and been doing this for 30 years), there is more and more an industry-wide shift away from the usage of RLL, even when it is the best tailored logic format for the application.
I am experiencing this directly at the present. I am REALLY liking the new Beckhoff products, and have been working with the local Beckhoff programming support guy to learn these products. Problem is, this guy (young guy recently graduated) greatly prefers structured text programming, and I greatly prefer RLL. So when he very kindly sends me program examples for the Beckhoff equipment (usually based on some RLL example) I sent, it takes me more time to interpret the ST code BACK into the RLL. This is actually hurting my ability to implement this equipment (which I like) into my equipment. I don't mind (in fact, rather enjoy) learning the newer techniques, but time is always a factor, so it's taking longer to reach my goal of using this equipment effectively.
I absolutely recognize the proper choice of language to fit the application. BUT, let's give RLL the respect it deserves, and teach the new folks WHERE and WHY it is most effective.

Can I get a "Whoa Bundy" on this?

you obviously have problems with unions - I am not a member -
But - YOU ARE WRONG -
when PLC's did not exist, earlier to 1976, only two forms of automation were available - TTL (transistor Transistor Logic) and hard wiring
try to show the wiring of a machine with out using RLL when the machine logic is wired with relays - lots of luck.

 

[iant]

I appologise for not mentioning - Hydraulic and pnuematic control.
Even the 10 pin bowling equipment (80 ~ 100 Y/O) was chiefly mechanical - pulleys etc.
But some relay control was still necesary

 

[WildeKurt]

I've read that the relay ladder logic (RLL) language was essentially forced on the auto industry by the trade unions as a way to keep union electricians employed when factories were automating; as stated earlier, it was so "regular" electricians could understand the programming and enhance maintenance.

This sounds a lot like urban legend to me. It's my understanding that RLL was developed hand in hand with the original PLC (Modicon I believe) at the request of the auto industry.

 

[PeterW]

I appologise for not mentioning - Hydraulic and pnuematic control.
Even the 10 pin bowling equipment (80 ~ 100 Y/O) was chiefly mechanical - pulleys etc.
But some relay control was still necesary

You also forgot plug-in logic modules, where the panel was full of AND, OR, XOR, etc plug in modules to create the circuit.

End of 70's more or less.

 

[intradave]

you obviously have problems with unions - I am not a member -
But - YOU ARE WRONG -
when PLC's did not exist, earlier to 1976, only two forms of automation were available - TTL (transistor Transistor Logic) and hard wiring
try to show the wiring of a machine with out using RLL when the machine logic is wired with relays - lots of luck.

Whether I am a fan of union labor or not isn't really the issue. The "union" thing could indeed be urban legend; as I stated, it's just what I HEARD, and concede it may not have been the primary driver, but I'll bet it WAS a factor.

When the conversion to "computer control" was desired by the auto industry, there were already existing programming languages available (cobol?, fortran?, others?...) that could have been implemented. It would be been "easier" for the advocates of those languages to adapt them to automation. Heck, even machine language (you know, mnemonics, etc...) could have been implemented. Some of the funkier little dedicated devices I work with TODAY use mnemonic code.

So WHY develop a language that "looks like" the existing relay/wiring schematics? It certainly makes sense to develop something the current labor pool (both engineering AND maintenance) could more easily support. Kudos to Modicon and Morley for their foresight.

So my BASIC (no pun intended) point was, in spite of the reasons (maintenance continuity, etc..) this funky little "new" language became the leading language in the control industry, AND has proven itself to be a very effective language for the control of industrial machinery. I'm a real big fan of it, and think the "new batch" of engineers, as well as academia, don't give it the respect it deserves or can appreciate the power and, I repeat, ELEGANCE it provides.

I MAY be a dinosaur.........but if I am, I'm a Raptor