Structured text

You should write code for other competent PLC programmers to understand.

Why use a PLC then? Use a PC and write your code in one of those powerful programming languages using all the good approaches and techinques you mentioned.

The whole point of a PLC is that it is a programmable device that can be handled by electricians, not professional programmers. If you are building machines that your customer would need to hire and expensive engineer to troubleshoot rather than a lower-paid technician, you may eventually lose that customer due to high total cost of ownership. Of course, if your equipment never breaks down... )))

So as much I share your sentiment, I think it is a bit over the top. Everything has its proper place.
 
I believe Structured text was designed to make it transportable between platforms, yeah right. It produces near as damit the same code as a ladder in reality. I understand the idea of platform interchangeability but in practice rarely works well and I think PLC manufacturers only include it because they have to, after all not one of them want you to change platform. Even Siemens S5 to S7 conversion fails in a number of situations. Even though I have been programming in assembler, basic, c & pascal for many years for machine control I still prefer ladder, graphical ladder I think is easier to compute in the brain (well at my age) makes sense to many people who have some experience in ladder, etc. etc.
 
Obviously this thread has evolved into one that has existed in various forms on this site in an argument in support or against specific programming languages and practices. Besides, most of the others have already replied with good answers regarding the use of ST in CASE statements ...

For my two cents:

In regards the whole ST vs. LD discussion, I agree with the others that neither is 100% correct and that the language chosen should be the one that best fits the given programming task. No programmer should be "pigeon holed" into using a specific language just because an outside prefers or has an understanding of one language or another. This is exactly why the IEC 61131 standard was created. I have a computer science background so when I first arrived in the automation industry, I was of course ST dominant. I've been in automation now for almost 20 years and although ST is still my baby, I have learned to deploy LD, FBD, and SFC (still not a fan) where applicable.

If there is concern of an end user needing to "troubleshoot" a program, then perhaps consider adding easy to read I/O maps to a program so it is easy to diagnose if certain signals are active or not which is usually the majority of what user are troubleshooting when something doesn't work. If by the time a machine arrives at an end user and a whole process needs troubleshooting, then there are likely bigger issues with the program that the programmer needs to be involved with anyway.

I would add in my opinion that the statement that PLC's are intended to be a device that is "easily handled by electricians" is lets say not 100% accurate and dare I say "antiquated". This is 2019 and PLC's today have the capability to control very simple electrical process sequences to highly complex automation lines which may include thousands of I/O points, motion control systems and robotics. The machines at the higher end of this range would be more specifically the ones that benefit from the giving the programmer the freedom to develop the application in whichever language(s) fit best.
 
I would add in my opinion that the statement that PLC's are intended to be a device that is "easily handled by electricians" is lets say not 100% accurate and dare I say "antiquated".

Of course that also was a bit of overstatement on my side for argument's sake and to drive my point.
 
Why use a PLC then? Use a PC and write your code in one of those powerful programming languages using all the good approaches and techinques you mentioned.

The whole point of a PLC is that it is a programmable device that can be handled by electricians, not professional programmers. If you are building machines that your customer would need to hire and expensive engineer to troubleshoot rather than a lower-paid technician, you may eventually lose that customer due to high total cost of ownership. Of course, if your equipment never breaks down... )))

So as much I share your sentiment, I think it is a bit over the top. Everything has its proper place.

The point of a PLC was to replace all of the complex relay logic many moons ago, so that one little device could replace all of the relays, etc.. Ladder Diagram was developed, as you state, to be better understood by electricians at the time. That was a long time ago when computer textual languages had not evolved enough for just anyone to code and do it in a timely fashion. They absolutely needed Ladder Diagram PLC language back then!

Nowadays, the textual languages, especially in PLC's that use IEC61131 Structured Text, have evolved well enough to the point that anyone can easily learn them and do it fast. Joe Snuffy maintenance guy included. I've taught kids fresh out of high school ST. Within a few days, they are programming routines in a PLC trainer using ST with very little issue. In fact, I'm often surprised on how fast they pick it up! Some of them with little or no prior programming experience in high school. The never ending narrative that "LD is better for electricians and maintenance personnel to understand" just doesn't hold a lot of water for me anymore. ST is just as easy and understandable and one could argue its even more understandable than LD. I mean both languages are IF_THEN_ELSE, TRUE, FALSE, etc... But in LD, you, as the programmer have to interpret and convert that. In ST, it's literally spelled out for you. Again, how much easier does it need to be? Who doesn't understand plain English?

With all that said, a really good controls engineer selects the language most appropriate and efficient for the programming task.
 
The never ending narrative that "LD is better for electricians and maintenance personnel to understand" just doesn't hold a lot of water for me anymore. ST is just as easy and understandable and one could argue its even more understandable than LD. I mean both languages are IF_THEN_ELSE, TRUE, FALSE, etc... But in LD, you, as the programmer have to interpret and convert that. In ST, it's literally spelled out for you. Again, how much easier does it need to be? Who doesn't understand plain English?

For me (and I'm sure many will agree) graphical languages are much easier to follow than textual ones. I write in both and the choice is made by what is the strength and weakness of a language for a given task. I can guarantee that for I/O heavy logic apps that ladder is easier to read and write. There are some ladder rungs that I can't fathom writing in ST. Imagine If a and b and c or c and x and y then ........ On the other hand, math functions, array handling and such are much easier in ST. I'd much rather do sequential function chart for sequential operations, it's what it does best. Doing complicated sequencing in any other language now seems like a poor workaround.

All the languages have their strengths and weaknesses, Pick the strongest tool for the job.

Cheers
 
Last edited:

Similar Topics

Good morning. I'm doing a rehab and I need to recycle some part of the old code that won't change and that I need. This is a calculation that...
Replies
22
Views
1,166
I'm writing some structured text that's handling a data structure that comes from a PC. The PC structure is in the "new" LREAL 64-bit floating...
Replies
3
Views
439
Trying to put these equations in structured text program in a Micro 830. when I run the verify I get this error. ;:expected before this new...
Replies
4
Views
394
Hey all, Studio v20.05 Background. We are piggy backing another system to record attributes for product travelling down the line and several...
Replies
21
Views
3,418
Hi, In our company (programming mainly Beckhoff PLCs) we are establishing internal coding guidelines for ST. Until now, the conventions were...
Replies
5
Views
1,017
Back
Top Bottom