theColonel26
Lifetime Supporting Member
So Let continue this because it was shaping up to be a lot of fun. It was High Jacking the other thread so lets continue it here.
I am not sure what your application will be, but; please remember who your end user is when programming a plc. It is maintenance. you need to know what their capabilities are in regards to programming and what they are used to.
Wrong, this kind of mind set is how we end up with such terribly written PLC code in the US. You should write code for other competent PLC programmers to understand. That doesn't mean make an inconsistent mess with a whole lot of "clever" logic, but it does mean take full advantage of the Programming tools that the environment provides you and try to maintain good DRY (Don't Repeat Yourself) and SOC (Separation of Concerns) practices. I see so much code that is written by Controls "Engineers" that is a giant knot of spaghetti with glue sauce, when I try to explain DRY and SOC practices to them I might as well be speaking Klingon. Anything other than Copy/Paste throw a NO there, put a NC there is to scary to try to grasp.
I'm not a degree-ed Engineer (no BS in Engineering that is), but I do consider myself to be an engineer. Engineering is a mind set and a way of thinking. I have encounters controls engineers that have real Engineering Degrees and I don't consider them engineers because they create messes.
This topic may need it's own thread.
Wrong, this kind of mind set is how we end up with such terribly written PLC code in the US. You should write code for other competent PLC programmers to understand. That doesn't mean make an inconsistent mess with a whole lot of "clever" logic, but it does mean take full advantage of the Programming tools that the environment provides you
I whole-heartily agree with the above. Take advantage of the tools that are provided, including the programming languages. Use the language that is best for the routine you're coding.
"Keep the maintenance people in mind when writing PLC code" is essentially implying to write it all in LD so the maintenance people can understand. If one cannot understand IF_THEN_ELSE, then that person should be nowhere near the PLC in my opinion. It's written in plain English (IF_THEN_ELSE). How much easier does it need to be? Okay, so you might have to learn what a CASE statement is and a FOR loop. No different than the numerous instructions outside of a XIC, XIO, and OTE in a RSLogix ladder program that one had to learn!
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 would like to pre-order a subscription to this thread.
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.
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.
Of course that also was a bit of overstatement on my side for argument's sake and to drive my point.
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.
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
We write code so the machines works and we get paid. The rest is fluff.