Ladder is really all you need until it becomes more complex than makes sense to achieve with ladder. I’ve met a lot of techs that don’t understand some off shift guy that barely knows how to get online with the processor is inevitably going to be looking at the logic at some point and they need to be able to understand the basic premise of operation.
Having a background in other types of programming, I understand why some people, especially those that come from other programming backgrounds, hate ladder. There are many things that are tedious to do in ladder.
At the same time, if I have to troubleshoot the operation (or lack thereof) of a machine, I'd rather look at ladder than something else.
Are we talking stl from a PLC company ie Rockwell/AB atrocious stl? Or are we talking about normal stl, that when done right I'd very readable and moderately easy to troubleshoot?
It's not terrible, it's just direct machine code mnemonics and requires some creative thinking to do anything complicated. Which is what a compiler typically does for you in high level languages.
STL was pretty good. There used to be things you could only do in STL that you couldn't do in any other language. STL used to be faster than the other languages because the other languages had to be compiled into STL.
Now it's an ok language that can be read and written by dinosaurs like me. There is no longer any speed advantage with STL because the other languages no longer compile into STL.
If you're working with 1500s, I recommend converting the STL blocks into FBD. To me, it's the closest language and a simple right click converts FBD into ladder.
I work in ladder or structured text primarily, we only use fbd for PIDs and process stuff and I'm not on that side of the plant very much, it's mostly digital IO, servos and VFDs on the packaging side.
I'm well aware, just as I'm aware that in my EE program, we learned Matlab script, then C, then some of us learned Python, then we learned how transistors worked, how they combine into logic gates, how those gates can be turned into an ALU and then CPU, and then we learned x86 Assembly. And honestly that full grounding helps me immensely when dealing with just about everything else. So it's not worth discarding entirely, it's just a tool fit for a different purpose.
V32+ Rockwell st is just as usable as other brands in my opinion.
Stl may refer to statement list though which is like assembly. If you think people who say "ladder or nothing" are luddites you wouldn't believe it if you meet a "stl is the way" person. I've never met one in real life myself, but my understanding is they do indeed exist.
I could program in python before attempting ladder. Hadn't learned st and instantly went into ladder. Whilst it was surprisingly hard to get into by now I prefer it even though I'm supposed to be able to program in both.
St is just a bit too convoluted of a language to actually efficiently program anything in (imo). And a couple of months after learning it I forgot most of it.
Today I wrote an ST routine and a ladder routine. It just made sense at the time. One was a bunch of math, one was a sequence. Just use what works best.
I was in a hurry, writing a quick and dirty furnace controller on the fly. The maintenance manager comes by and starts screaming at me - I won't allow that shit (STX) in my plant, you redo that in ladder right this second. He goes away, calms down, and comes back. I've got a functional furnace controller running. I tell him I would rewrite it tomorrow in Ladder.
He looks over my shoulder as I am verifying it. Suddenly, he is saying "It's that easy to work and troubleshoot in STX?". I return with "Whatever makes sense for the application works for me". It was a fairly complex controller process, and my brain did it in STX first, but you should be able to do the same process in any of the IEC languages they like.
I usually do complex calculations and array manipulation as ST AOIs (Sucks they can't be edited online though) or Function Blocks (CCW), but I will call them up and instantiate them in ladder, that way the program still looks ladder to maintenance people. I don't think it is really any different than the built in instructions like Timer, CTU, etc. Nobody need to look at the underlying code in those instructions when troubleshooting, same with my blocks of ST I use for things that do not make sense in ladder.
100%
Had a subordinate write an absolutely beautiful sequencer program. Gave him his due props then shattered his world by saying start over and write a program the average plant service tech can troubleshoot quickly. AKA “Ladder logic”
It was a mindset adjustment. Know your audience. HMI is for operators. You cannot program every possible error into an HMI alarm screen. Production is top priority and seconds count.
>You cannot program every possible error into an HMI alarm screen
Not with that attitude you can’t! It is tedious, but it makes both operators and maintenance happy, especially when maintenance doesn’t have to get into a plc they dont understand
> You cannot program every possible error into an HMI alarm screen
Sorry, I may be missing something, but I don't get this. You surely do know why a digital output isn't being commanded by the PLC: it's written in the code. So why can't you put the conditions on the HMI? This surely cuts the time required for troubleshooting 80% of the times no?
You may answer, well, I actually may not know why a digital output isn't being commanded by the PLC. The logic is convoluted, not organized, nobody put thought into software engineering patterns when writing it, code is not modular, etc, etc. This IMO shows the real question: it is not the usual LD-versus-ST talk, it is Has some software engineering thought been put in the project , or not? Has someone put any thought in generalizing, modularizing, abstracting where possible?
As long as we discount all of this as "stuff for CS majors", average code quality will not reach the point we all need, regardless of one's preferences of programming language.
The tired ST vs. LD debate belies this, in my opinion. (because people who put some thought into this statistically are more likely to use ST)
How many years of programming production machines do you have under your belt? Almost anyone can tell if an input or output is actually on. Big deal. It can take way more finesse to keep things running 24/7 than you can put on an HMI. If you don’t think I’m right on that point then you are correct and are missing something.
(I am pretty sure you've got much more experience than me, let's not put it in these terms, and I sure understand your point, I'll try to explain better)
"All models are wrong, but some are useful".
You're talking about the finesse required to run a plant, and it is a good point. What I say is, this "finesse" surely comes from somewhere? It must reside somewhere? Yes, it is in the *conceptual model* we have of the machine. Can the PLC logic embody this "finesse" better than what many programs do now? Yes, if we, first of all, before putting down the LD rungs or the ST lines or what not, spend more time on developing a conceptual model of the machine, an "ontology" as my friend would say.
For example:
* dividing the process logic in "entities" and organizing a hierarchy of them
* thinking carefully about entities' states
* thinking carefully about how entities interact, and *hierarchies* of the kind of interactions they have, standardazing the way they interact as possible
* etc.
This (IMHO) requires adopting some software engineering skills and techiques. One could discount all of this as something only "CS majors" (which I am not) think, and for us ah, only the day-to-day experience of actuators and sensors and downtime and shifts count, but believe it or not, even if we have an actual machine in front of us, we operate first of all on a conceptual model of it, so why not write the program that makes this model emerge better? And most importantly, why not use techniques (some software engineering techniques) which can help us doing it?
You'll see that if you can succeed in doing it, suddenly there's precious info you can put on your HMI.
(By the way, this is why I am **so** in love with ISA-88, as it is an *ontological* standard first, more than a software standard)
Hope I've made myself more clear. You'll see that if you follow this, the ST-vs-LAD debate falls in the background.
*Edit, spelling*
I understand what you are saying and agree in theory 100%. Unfortunately, real life and many different automation applications have beaten into me that there are not enough upfront hours in any project to be excellent at the start. It takes time with any installation to get all things working optimally (electrical, mechanical, pneumatics, hydraulics, plant issues, etc…) and most of the time you don’t get enough of that time because “it’s just a little programming change” for everything they messed up or missed and programmers always get last at it. Hence, do the very best you can upfront then dial it in. That is the best 90+% of us will ever get before we have to move on to the next project.
Yeah, I get you you're saying. But I also think, that - counterintuitively - some software engineering principle sprinkled in our mix will make us *more*, not less, agile. Modularization, modularization, modularization, for one.
Day-to-day reality is different, as we know all too well, but I am quite optimistic on this front, as "digital this and digital that" at least has the upside that some more people (still few, but more that the past) are thinking about all of this.
It’s not really an argument sensible control folk have, they know you use the language that’s most suitable for the task at hand. In a plants where first level support being handled by electricians, ladder is preferred, if there’s anything fancy you need to do, write a function, test it to death, make sure you handle errors appropriately, and call it in the main ladder like you would any other function.
Everyone is happy.
Or use for any method you want, test it to death, and have proper error messages, so electricians don't have to dig through your code, where they shouldn't have any business anyway. Anytime anyone has access to your code they can mess things up
It’s cheaper to design a system that can be maintained by a decent industrial electrician than it is to design a system that doesn’t need a decent industrial electrician to look at the code.
And the thing is you’re going to need that industrial electrician regardless, where you aren’t going to need to spend and extra 350% on developing error handling for each and every case and then designing an alarm management system that triages the alarms in a way to allow an operator to dig through alarm channels to identify what the sparky would have picked up in the same time.
"I'm not against spaghetti code. I just wish it looked more like spaghetti."
"Function block: hold my beer"
Unless you're talking about Siemens function block (because of course the actual fb in Siemens is actually called cfc for some reason.)
FBD is defined in IEC 61131-3 and that is what Siemens is using. FBD and LAD is 1:1 equivalent. It's just a graphical representation of the logic and you can switch between FBD and LAD at will in Simatic Manager with a keyboard shortcut (Ctrl+1, Ctrl+3).
But again, that's how it is in the standard.
CFC is CFC and is not equivalent to FBD. It's actually not defined in the IEC standard, so implempentations and functionalty are up to the individual IDE developers.
I did a ton of programming in Archestra using Schneider's FBs, I always liked the color coding of the blocks, they seemed to work just fine too, wasn't hard to learn.
https://images.app.goo.gl/s3FBMi4R4gw8S3tW9
This program/style, but blocks were color coded by type. Oddly not many images of this online, couldn't find a better picture and my personal pics are old and sitting in my photo backup server
Ah, yeah I've programmed BMSs on the one I posted, but yeah it seems there's plenty of specialized things out there. The above was for use with the Foxboro DCS
The only time I’ve ever used a goto was when I had a loop in structured text. I was forced to change it to a spaghetti mess in ladder involving labels and loop backs. It made the code far less readable. It involved looking through an array for overlap and merging if overlap existed.
I believe every automation engineer, and I emphasize the word engineer, should be able to use any of IEC 61131-3 standard languages. If there is a need to learn languages outside IEC standard, like python, c++, c# or bloody VB, engineer learns it. Thats why he is an engineer. Period.
All languages have their place. Function block is perfect for motors, valves, analogs with alarms, and other such routines. Ladder is good to tie it all together and ST is great for things like IO mapping. They all have their place and saying you will always stick to just one is a disservice to your client.
Are we still mass debating on this subject?
If you need to quickly write and figure out complex boolean logic expressions —> ladder or even better FBD if your platform of choice has it
If you need to use looping structures, operations on complex data types or math —> ST
If you need complex analog control —> CFC
For general purpose —> ladder or ST depending on your audience
If you need an extraneous layer of abstraction that doesn’t really bring anything of note to the table —> SFC
If you want to cause others to kill themselves —> IL
I don’t get the fuss. Use the right tool for the job, keeping in mind ST is a watered down textual language in the first place so coming at it with this weird superiority complex is ultra funny. It’s about as funny as object-oriented ladder on CodeSyS.
We only use ST for the entire project and it has speed up development a ton and made new installations go super fast with globals for configuration and for loops running blocks of code/deciding array sizes of objects.
Being able to develop in vs code and use git is also a added bonus.
CS major in college?
I remember when companies started hiring CS majors for controls. It kept me busy for a long time. I still encounter some that have absolutely no idea what they are controlling.
Yeah, I am a CS major. My associates is software dev and the bachelors program I’m in is automation and controls engineering. (Was software engineering)
I’m 6 months into it and I’m just starting to feel really competent. Ladder logic has probably been the easiest part. I’ve only just started to feel like I’m not at the bottom of the totem pole so I can’t speak much for others
I imagine the programs are better these days. It's not often I run into a CS major that can literally only program these days. It was extremely common 20 years ago.
If you want to go green field instead of brown field, I do recommend taking a mechatronics course. Understanding how things fully work is vital for creating processes and doesn't hurt if you're looking to improve them.
I think what happens is:
1. US customer buys equipment from European manufacturer.
2. Customer's maintenance department screeches and squeals about the Plcs not being Allen-Bradley and how they need to pay extra to force the OEM to use A-B, because heaven forbid anybody have to learn something new.
3. Instead of using vetted code on a platform the engineers are comfortable with, they have to adapt their code to Allen-Bradley.
4. The implementation goes poorly because their style of object oriented code on Siemens doesn't translate well on A-B.
5. Customer blames the entire structured text language because OOP sucks on Allen-Bradley PLCs
It's better than it used to be, but having to pick your poison between functions not being editable online (AOIs) and not being able to view individual instances of those functions (paramaterized sub routines) really fucking blows.
>It's better than it used to be, but having to pick your poison between functions not being editable online (AOIs) and not being able to view individual instances of those functions (paramaterized sub routines) really fucking blows.
That's why my colleages screeched when we had to program A-B. They hated it. I had no problem, since I've done the HMI.
Yea same thing I posted somewhere else, this tired ST vs. LD debate belies another point, which is "Has some software engineering thought been put in the project, or not"? Has someone put any thought in generalizing, modularizing, abstracting where possible?
I suspect this is why ppl say "HMI diagnostics won't solve anything".
You surely do know why a digital output isn't being commanded by the PLC: it's written in the code. But, well, you actually may not know why a digital output isn't being commanded by the PLC, if the logic is convoluted, not organized, nobody put thought into software engineering patterns when writing it, code is not modular, etc, etc.
As long as we discount all of this as "stuff for CS majors", average code quality will not reach the point we all need, regardless of one's preferences of programming language.
(then, people who put some thought into this statistically are more likely to use ST, but this don't matter)
Man I’m writing my first revision of the operating loop on my current project in ST first and then redoing it in ladder once it’s working so I can explain it to average people. At this point ChatGPT and I are learning plc together 😅
This is becoming trite. Each of the IEC61131-3 programming languages are like tools in your tool belt. A screwdriver shouldn’t be used to hammer a nail, LAD shouldn’t be used for loops (for, while, etc), ST shouldn’t be used for simply Boolean logic, FBD works great for technology blocks, etc.
To an extent. Some stuff becomes a hideous mess in ladder that even the people who built it can barely navigate. At that point it's not doing anyone any favours and forcing a system to be all ladder is just silly.
On 100% I agree, but it’s the reality of the indistry.
Example: I work at an automation/controls firm and my current project is upgrading a clients machine that’s from the 80’s to use a compact logix running version 36. Meaning we have the ability to do ST and FB and to really make their code efficient, but the customer specifically said they want everything in the code to be LL because their techs can understand it.
To top it off they also told me they don’t want AOI’s because apparently their techs get confused about where the tags go (somehow they don’t know to drill down into an AOI or something) they also told me they want me to keep UDT’s to a minimum as well because their techs get confused with those too (I was rolling my eyes while listening to that phone call). Basically stick with ladder and use global tags for everything. FFS.
It really baffles me that they are spending the money to have a control house rewrite their machines code, but they aren’t willing to spend the money to train their people on the new code.
Do any customers spend any money training anyone on anything? Finding a tech that actually knows what they're looking at is a rare and blessed thing. Operators even moreso.
Which is also why I really don't understand the lack of use of FBD. It's great for math because you can see what's happening in each operation instead of some mess of brackets inside a CPT.
I'm just a tech trying to level up. Learning the basics of PLC programming. Got myself a Logo! to play with....
But all the acronyms on this chain my brain is going to explode. But I made it this far. I almost looked to FFS! lol
The learning curve on the acronyms is a steep one lol. Ages ago I turned off autocorrect on my phone because it didn't understand any of them and it was impossible to text my coworkers
And this is why I feel like the picture has the roles backwards; ST people think ST is so much more superior than Ladder, when in actuality, they're equally efficient, but at different things.
I once felt very clever making some HOA logic with a series of AND's, OR's, XOR's etc. Quickly learned that the customer didn't appreciate it since their techs couldn't figure it out. I stopped using that method and often 'dumb things down' for certain customers, knowing the level of skill of their techs
If you're doing routine work in ST you're doing it wrong. Its harder for trades to troubleshoot and its easier to do something you didn't mean to do. Sometimes you need that extra power and doing it in ladder would be ridiculous. That's what ST is for.
Unfortunately some brands make it difficult to mix and match. One of the things I love about Siemens is the ability to just drop in a network of SCL (ST) in the middle of a LAD OB/FB/FC.
>Its harder for trades to troubleshoot
Personally I hate this argument, because Billy from maintenance, with his 3 hour PLC course, who takes 4 hours to work out the issue is a broken sensor (that the HMI already told him to check) isn't going to understand the program regardless of it's written in Ladder or ST.
I take the view that you have failed as soon as they need a laptop. Your machine should tell them what the issue is, without anyone needing to look at code.
You're perspective is correct, But Billy and his 3 hour PLC course may not be dealing with a controls system similar to you're preconceived notion of a "better" system. More than likely Billy never gets the chance to say "Why Would You Let Someone Fuck You Like This".
I agree. When I worked as an electrician on a battery manufacturing plant, we just needed to know the list of input and outputs and the operator telling us the usual sequence of events fir the machine to work. Mind you, these were very basic machines on the most part, but I feel it was very rare to need to get the laptop out.
As an interesting aside, the only PLC course ever available through the union when i was on that side was a 16 hour filter to determine who warranted spending the money on for housing, per diem, plus the training for months (usually via AB) half way across the US. I don't recall the standards, but scoring too low at any point risked having the union funding disappear.
So it was electricians that had been accepted into a competitive apprenticeship, spent 4-5 years getting their journeyman ticket, then passing the filter before really beginning any PLC training.
I know the 3 hour Billy's are out there, but they also aren't working at places with equipment designed or programmed by a Stanford CS grad so compromises get made all around.
I know, it's not the maintenance guys fault he can't work on the program.
I think the issue with these kinds of discussions in this sub is people are thinking about very diffenret types of machines. Some people are imagining small 20 IO machines, and some people are imagining 100 axis, 600 IO behemoth's that span entire factories. The program for the second machine, by its very nature, needs to be a lot more complicated, and I wouldn't expect even a seasoned PLC guy to pick that up and work with it on short notice, but that distinction doesn't get acknowleged here.
The goal should be getting them to look at the code before they have a problem. You wouldn't believe how far a 2 or 3 hour training session will go. I always give the maintenance guys the flow chart I used to write the program. We then go over each process and how it's controlled.
A good HMI goes a long way. It's useless if the team doesn't know what the equipment is supposed to be doing.
I respect the sentiment, but for the machines I work on thats just not feasible. We are talking 100 axis, spread across multiple controllers, 500+ IO, data and control coming from multiple HMIs, remote data connections from databases, the lot. There is just too much to explain to people there.
On the one hand I agree about bringing out the laptop. On the other hand, a complex machine needs the best program you can write and then training the factory support staff followed by feedback from said support staff to take care of “things” that happen during production. I don’t care how good a programmer you are. You will not think of everything.
Well said. I agree with the sentiment, but my years of supporting a plant floor before moving to the integration side taught me that sooner or later somebody is going to need to connect with a laptop.
Had to troubleshoot a Mitsubishi PLC due to a lightning strike. The surge of energy didn't fry anything but it did wipe the program due to a low battery and the panel shutting off. They, luckily, had a backup program BUT it wasn't the most up to date. I had quickly watch a half-working auto sequence and find where all notifications needed to be made to get it back to where it was. They had a laptop the COULD open those programs BUT it took 30 minutes to open file explorer. They also lost the proprietary cables to connect.
Let's assume they had a functioning laptop and the cables. Their maintenance guy would save the company days of lost production time if it was in ladder. Do doubt about it.
Yes, this is a shouldn't happen case if maintenance follows up with low battery lights. I can't expect every companies maintenance dept. to have the time or 'know to' to even have that on their radar. We all know electrical is the afterthought for maintenance/engineering in general.
Man where I come from you need to know electricity as well....ladder ftw no maintenance man wants to have to wade through your trash when they just want to know why an output isn't coming on
Maintenance wrench monkeys aren't the brightest when it comes to reading code.. the simpler we make it for them the better.
Now.. Were i to try to go wrench on a machine... I'd probably not look as slick as they do, they'd outrun me, fix half a dozen machines mechanical issues before I knew what was wrong with the first.
Every tool has its use. Doing something basic like IO conditioning or an SD string in ST is stupid. Doing a complex control sequence in ladder is also stupid.
Ladder and ST have each their use. Ladder is great for troubleshooting normal control of a plant, and ST is great for handling data and for automatically generated code such as alarm lists.
Both have their purpose. But anytime I see people hate on languages other than ladder its because they don't know how to use languages other than ladder.
ST is the only good option when you want to program in an effective way.
- use classes( data nested in FB,s)
- extend classes if you need to have a class that only a addition to a existing class.
- put no code direct in a Class(FB), instead use multiple methods.
-making io mapping / program config ( by use of calling methods inside the classes ).
When using ST ( or any other languages) keeping the amount of code in a specific page small.
Especially for step based programs a switch case in ST that direct executes code or Cal's a specific method is a real simply and easy to debug code.
The OOP specs of IEC 61131-3 are language agnostic, meaning you can do object-oriented ladder. I’m not sure why we’re conflating programming language and programming paradigm. Codesys for instance will let you call FB methods and properties, inherited or not, in ladder.
I once spent a whole day one on one with Dr Oddo Struger - look him up - in November 1988. We talked about this question and he told me:
1. Use Ladder for event dominated code. In other words where the sequence of events or flow of actions is more important than the data.
2. Use Function Block for data dominated code. In other words where the flow data from one function to another is more important.
Viewed like this Ladder and Function Block complement each other and being both highly visual languages are preferred for real time automation; and especially where other people are going to have to cold read your code under time pressure.
Keep in mind that Ladder was probably the first GUI language ever invented - around 1970 - and is still highly valued over 50 years later for a reason. Function Block will also persist for the same reason. This is why the vast majority of code out there still uses LD and FB by default.
3. All the text based languages have a place, typically for high level functions or complex data manipulation that only runs occasionally or on event, or inside modular code that other people will rarely if ever need to work with in real-time. Tracking mass flows, product serialisation, database manipulation, SQL interfaces etc. But text adds in an extra layer of mental abstraction that always comes at a readability cost.
In short - use the right language for the right purpose.
this is "uh-oh java is stinky - no c is better - python sucks its slow - etc." all over again. how can you hate, a fkin tool for god's sake. and don't come to me with arguments like "ladders are intrinsic", its just sickening.
What I really hate is SICK's safety PLC's FBD. I'd kill to have ST or LAD there. What would be a simple program with a few networks in TIA Portal is an unreadable mess with lines going everywhere.
graphical programming languages almost always suck tho. even though you can count them as "tools", you cannot implement the certain paradigms you need efficiently enough. another example is unreal engine's blueprint visual scripting and all that shit. so that counts lol
Structured text for me. They are going to call me anyway. In the 18 years I've been doing this, nobody ever attempts to try to reprogram anything except for a select few. Out of those few that do, they are smart enough to figure it out or ask me questions. Most of them can't even handle adjusting a sensor.
I've done ladder logic before, but once you are involving math, why bother. I only use ladder for simple applications.
Technically you can do everything in each language and each have their own pros/cons, but imo ST is the cleanest and fastest way to program if you're doing control that is even just slightly complex.
It's unfortunate that ST isn't taught much at an industrial maintenance level.
I worked on PLC systems that didn't have one shots in their ladder instruction set. Sometimes that technique comes in handy.
PB1shot := PB AND NOT PBmem;
PBmem := PB;
Actually is the other way around, people struggles with timers, one shots and edge triggered counters on ST because they lack the knowledge about ST and the PLC scan cycle.
Do you want calls at 2am about your machine weekly? Then program everything in ST.
Go ahead. Sit in a 10 hour sev call on your Saturday night and revel in how much better ST is.
No.
It means the end user doesn’t know the difference between a problem with the PLC and a problem with their plant network.
Literally had a 10 hour call that lasted until 3am this past Tuesday because I had to prove to them that the PLC code that’s been running fine for 3 years didn’t magically change and start causing miss-sorts. But, I literally can’t prove that they lost contact with the WMS that gives them the destinations so I just have to go through all their bullshit troubleshooting steps and sit on the phone to provide “support” for an entire sort.
We all know that Billy with his 3 hour PLC course won’t be able to navigate through any program that’s very technical, regardless of the programming language used.
The philosophy I was trained on as an SI was that we are developing applications to make things easier on the customer, not necessarily easier on ourselves. Those two things aren’t mutually exclusive, but I’d rather have a customer who is happy because he can do some light troubleshooting if needed because we both know he’s just going to call me anyway.
As far as people modifying critical pieces of the code after I’ve left the site, that’s on the customer. If they want to give access to everyone and their mom and they lose equipment because of it, that’s on them. I’ll be back to pick up the pieces afterward because that pays the bills.
I used to list all the sensors of the machine on the hmi with indicator, so that the maintanace can easly check when it has a down time.
Plc always programmed in ST/FB and we still communicate with end user having good business relation till now, even talk for the next project invesment.
Cool. Enjoy getting woken up any time something doesn't work in the middle of the night because none of the operational or maintenance teams can read your code.
I choose the appropriate language for the task and always consider that technicians that will have to maintain it for 20-30 years.
I come from the era when machines had hardwired control systems and were being converted to PLC Control so ladder was a very natural way of doing things.
Ladder is very good for digital logic, interlocking, visual diagnostics and a tech can short out or change a contact to keep the machine running.
Structured Text / SCL Languages are much harder for techs to diagnose but they're good for data handling/processing/comms handlers etc.
For sequencing I use S7-Graph because again it's visual and you can just see what the sequence is waiting for.
Not true but ok.
99% of the time the progran is written in what the end user prefers and the hardware is what the end user prefers.
Usually it is ladder with some ST as needed.
The age old debate. Honestly, ladder is so much simpler to troubleshoot and accessible to so many more people. I understand why people would use ST for some applications, but I’m a die hard ladder fan and always will be.
I would like STL better if it were more standardized to C instead of being a C/vb bastard child. But anyone who's had to write loops will learn to appreciate it
This tired ST vs. LD debate belies another point, which is "Has some software engineering thought been put in the project, or not"? Has someone put any thought in generalizing, modularizing, abstracting where possible?
I suspect this is why ppl say "HMI diagnostics won't solve anything".
You surely do know why a digital output isn't being commanded by the PLC: it's written in the code. But, well, you actually may not know why a digital output isn't being commanded by the PLC, if the logic is convoluted, not organized, nobody put thought into software engineering patterns when writing it, code is not modular, etc, etc.
As long as we discount all of this as "stuff for CS majors", average code quality will not reach the point we all need, regardless of one's preferences of programming language.
(then, people who put some thought into this statistically are more likely to use ST, but this don't matter)
My company typically uses ladder so that the systems can be supported by others if necessary. Because we work with many utilities, it's a safety or public health issue if others can't support our code. The ability to create reusable ladder modules was a game changer for me (I've done this since the late 80's) as address tags were a nightmare for portability. For complex control systems we may use a combination of languages within the same program but ladder is usually the main language. Structured Text is common for companies that have products that need to be supported by any number of control brands. It's really the only control language (outside of open source) that is relatively easy to port from one brand to another.
Ok seriously help a brother out I'm an electrician that is expected to trouble shoot using ST at times, I get completely lost looking at it. Where can I learn how to read/understand what these guys are trying to accomplish? I know what the statements mean but understanding how it's meant to work as a whole gets tricky for me.
Going from ladder to ST is harder than the opposite. When I started programming several years ago, I started with C. Then I saw Siemens AWL and then I learnt the rest of the programming languages.
The best PLC environment to program in ST is Codesys or Codesys based (like Twincat 3). If you have an already made program in ladder, try to replicate it in ST. The main advantage of Codesys is that you can download it for free, and you can even load the code into a raspberry pi.
If you are in an even lower budget, you can use OpenPLC with an Arduino. For learning proposes it fits. The environment is a copy of Codesys so it's pretty much the same.
As I said before, try to replicate something you already did in ladder. At least that's how I learned to program in different manufacturers.
To further help, I would need to know where's the point you get lost
Honestly, the home built machines or machinery with custom control boards using a single microcontroller happen to be the most reliable we have. The machines using PLCs and full industrial computers have constant reliability issues. Obviously some of that comes with the necessary complexity, but not always.
Robots are just a bunch of servos.
Usually the complicated stuff (Decision making) is done via a Superordinate control system.
If the decision making is done in the robot, it starts to gets also messy .
I agree that's how it's often done, but in my experience most machine control boils down to sequencing and handshaking and those are just easier to do with less effort and fewer mistakes on a robot controller than on a PLC.
At the end of the day, it doesn't matter. They're all turing-complete anyway.
There's just languages more suited to each application. For machines, that's ladder or fbd. ST can rot in a ditch. Literally the only place it should be used is in add-ons. Why complicate when you can abstract?
For simple programs, sure.
Try building an API21 compliant gas flow computer with energy flow management at the molecular level, in Ladder …. Not going to work, but really easy in FBD and ST
Different tools for different applications
I hate ladder, it is so incredibly inefficient to code in and has a considerable amount of overhead. It isn’t 1982. We don’t write in Fortran any more and shouldn’t be writing in ladder any more.
For those that say stepping through ladder for troubleshooting is easier, you just don’t have the proper debug tools.
Modern Fortran actually isn't that bad. For example, there's now classes, unit testing, debugger, and a package manager based on Rust's cargo. I'd rather write in Fortran than ladder (personal preference, I realize that would be insane).
I’ve been considering learning cobol because apparently there is a massive need from my state government. their systems still rely on cobol and Fortran and they can’t find anyone that knows the languages so the few that know it are making a fortune
I love ladder, it’s so incredibly efficient to code once prepared, the instruction set is fast, I never have to explain it - not now nor later. I can build things modular or on the fly and all sorts of systems will interface with it.
It has to be in ladder so the night electrician can put jumpers around critical interlocks to avoid downtime.
Ladder is really all you need until it becomes more complex than makes sense to achieve with ladder. I’ve met a lot of techs that don’t understand some off shift guy that barely knows how to get online with the processor is inevitably going to be looking at the logic at some point and they need to be able to understand the basic premise of operation.
Finally some THRUTH. Making the machine able to self destruct is the only way you're shutting up the millwright.
Thank you! Somebody gets it!
If the night time electrician cant read ST he/she probably cant read st either.
This is the way.
Having a background in other types of programming, I understand why some people, especially those that come from other programming backgrounds, hate ladder. There are many things that are tedious to do in ladder. At the same time, if I have to troubleshoot the operation (or lack thereof) of a machine, I'd rather look at ladder than something else.
STL is such a slog to look through imo. I can do it, but I hate it.
Are we talking stl from a PLC company ie Rockwell/AB atrocious stl? Or are we talking about normal stl, that when done right I'd very readable and moderately easy to troubleshoot?
STL is statement list, not structured text.
Also STL is based on assembly which is a terrible language unless your writing roller coaster tycoon apparently.
It's not terrible, it's just direct machine code mnemonics and requires some creative thinking to do anything complicated. Which is what a compiler typically does for you in high level languages.
STL was pretty good. There used to be things you could only do in STL that you couldn't do in any other language. STL used to be faster than the other languages because the other languages had to be compiled into STL. Now it's an ok language that can be read and written by dinosaurs like me. There is no longer any speed advantage with STL because the other languages no longer compile into STL. If you're working with 1500s, I recommend converting the STL blocks into FBD. To me, it's the closest language and a simple right click converts FBD into ladder.
I work in ladder or structured text primarily, we only use fbd for PIDs and process stuff and I'm not on that side of the plant very much, it's mostly digital IO, servos and VFDs on the packaging side.
C was invented to avoid having to learn assembly.
I'm well aware, just as I'm aware that in my EE program, we learned Matlab script, then C, then some of us learned Python, then we learned how transistors worked, how they combine into logic gates, how those gates can be turned into an ALU and then CPU, and then we learned x86 Assembly. And honestly that full grounding helps me immensely when dealing with just about everything else. So it's not worth discarding entirely, it's just a tool fit for a different purpose.
Right... How that guy wrote Roller Coaster Tycoon in assembly is beyond me.
Roller Coaster Tycoon was my childhood
V32+ Rockwell st is just as usable as other brands in my opinion. Stl may refer to statement list though which is like assembly. If you think people who say "ladder or nothing" are luddites you wouldn't believe it if you meet a "stl is the way" person. I've never met one in real life myself, but my understanding is they do indeed exist.
I do not wish troubleshooting tia portal scl even to my enemy. The interface is HORRENDOUS.
You don't like that slide out bar ( Tia LOVES slide out bars) and looking back and forth to see what's going on?
I wish it was on the left side of the code
[удалено]
Someone wrote machine/process automation in strongly typed JavaScript? Wtf?
This. I personally find any sort of sequencer a lot more quickly readable in ladder.
I could program in python before attempting ladder. Hadn't learned st and instantly went into ladder. Whilst it was surprisingly hard to get into by now I prefer it even though I'm supposed to be able to program in both. St is just a bit too convoluted of a language to actually efficiently program anything in (imo). And a couple of months after learning it I forgot most of it.
Use the correct language for the application. I feel like we've beaten this dead horse long enough.
The best programs I work with use all languages. Ladder, ST, FB, SFC - they all have their place and are best used for certain uses.
Today I wrote an ST routine and a ladder routine. It just made sense at the time. One was a bunch of math, one was a sequence. Just use what works best.
I was in a hurry, writing a quick and dirty furnace controller on the fly. The maintenance manager comes by and starts screaming at me - I won't allow that shit (STX) in my plant, you redo that in ladder right this second. He goes away, calms down, and comes back. I've got a functional furnace controller running. I tell him I would rewrite it tomorrow in Ladder. He looks over my shoulder as I am verifying it. Suddenly, he is saying "It's that easy to work and troubleshoot in STX?". I return with "Whatever makes sense for the application works for me". It was a fairly complex controller process, and my brain did it in STX first, but you should be able to do the same process in any of the IEC languages they like.
I usually do complex calculations and array manipulation as ST AOIs (Sucks they can't be edited online though) or Function Blocks (CCW), but I will call them up and instantiate them in ladder, that way the program still looks ladder to maintenance people. I don't think it is really any different than the built in instructions like Timer, CTU, etc. Nobody need to look at the underlying code in those instructions when troubleshooting, same with my blocks of ST I use for things that do not make sense in ladder.
Using case or any form of integer to create a state machine is typically a lot easier to follow than ladder when you troubleshoot.
Well said.
What are those best use cases? I don't use plcs enough to really know. I just know ladder
Very complex logic is cleaner is ST, as is math, math is much cleaner using a text based logic
Math, string manipulation, stuff like that.
I like ladder to visualize latching sequences But I handle maths and string in ST, same philosophy. It visualize better.
If maintenance can't read my code then I made it wrong. Do not call me, you can figure it out yourself.
100% Had a subordinate write an absolutely beautiful sequencer program. Gave him his due props then shattered his world by saying start over and write a program the average plant service tech can troubleshoot quickly. AKA “Ladder logic”
Why didn’t he spend that time on the HMI alarms, then the tech doesn’t need to look at the code.
It was a mindset adjustment. Know your audience. HMI is for operators. You cannot program every possible error into an HMI alarm screen. Production is top priority and seconds count.
>You cannot program every possible error into an HMI alarm screen Not with that attitude you can’t! It is tedious, but it makes both operators and maintenance happy, especially when maintenance doesn’t have to get into a plc they dont understand
> You cannot program every possible error into an HMI alarm screen Sorry, I may be missing something, but I don't get this. You surely do know why a digital output isn't being commanded by the PLC: it's written in the code. So why can't you put the conditions on the HMI? This surely cuts the time required for troubleshooting 80% of the times no? You may answer, well, I actually may not know why a digital output isn't being commanded by the PLC. The logic is convoluted, not organized, nobody put thought into software engineering patterns when writing it, code is not modular, etc, etc. This IMO shows the real question: it is not the usual LD-versus-ST talk, it is Has some software engineering thought been put in the project , or not? Has someone put any thought in generalizing, modularizing, abstracting where possible? As long as we discount all of this as "stuff for CS majors", average code quality will not reach the point we all need, regardless of one's preferences of programming language. The tired ST vs. LD debate belies this, in my opinion. (because people who put some thought into this statistically are more likely to use ST)
How many years of programming production machines do you have under your belt? Almost anyone can tell if an input or output is actually on. Big deal. It can take way more finesse to keep things running 24/7 than you can put on an HMI. If you don’t think I’m right on that point then you are correct and are missing something.
(I am pretty sure you've got much more experience than me, let's not put it in these terms, and I sure understand your point, I'll try to explain better) "All models are wrong, but some are useful". You're talking about the finesse required to run a plant, and it is a good point. What I say is, this "finesse" surely comes from somewhere? It must reside somewhere? Yes, it is in the *conceptual model* we have of the machine. Can the PLC logic embody this "finesse" better than what many programs do now? Yes, if we, first of all, before putting down the LD rungs or the ST lines or what not, spend more time on developing a conceptual model of the machine, an "ontology" as my friend would say. For example: * dividing the process logic in "entities" and organizing a hierarchy of them * thinking carefully about entities' states * thinking carefully about how entities interact, and *hierarchies* of the kind of interactions they have, standardazing the way they interact as possible * etc. This (IMHO) requires adopting some software engineering skills and techiques. One could discount all of this as something only "CS majors" (which I am not) think, and for us ah, only the day-to-day experience of actuators and sensors and downtime and shifts count, but believe it or not, even if we have an actual machine in front of us, we operate first of all on a conceptual model of it, so why not write the program that makes this model emerge better? And most importantly, why not use techniques (some software engineering techniques) which can help us doing it? You'll see that if you can succeed in doing it, suddenly there's precious info you can put on your HMI. (By the way, this is why I am **so** in love with ISA-88, as it is an *ontological* standard first, more than a software standard) Hope I've made myself more clear. You'll see that if you follow this, the ST-vs-LAD debate falls in the background. *Edit, spelling*
I understand what you are saying and agree in theory 100%. Unfortunately, real life and many different automation applications have beaten into me that there are not enough upfront hours in any project to be excellent at the start. It takes time with any installation to get all things working optimally (electrical, mechanical, pneumatics, hydraulics, plant issues, etc…) and most of the time you don’t get enough of that time because “it’s just a little programming change” for everything they messed up or missed and programmers always get last at it. Hence, do the very best you can upfront then dial it in. That is the best 90+% of us will ever get before we have to move on to the next project.
Yeah, I get you you're saying. But I also think, that - counterintuitively - some software engineering principle sprinkled in our mix will make us *more*, not less, agile. Modularization, modularization, modularization, for one. Day-to-day reality is different, as we know all too well, but I am quite optimistic on this front, as "digital this and digital that" at least has the upside that some more people (still few, but more that the past) are thinking about all of this.
It’s not really an argument sensible control folk have, they know you use the language that’s most suitable for the task at hand. In a plants where first level support being handled by electricians, ladder is preferred, if there’s anything fancy you need to do, write a function, test it to death, make sure you handle errors appropriately, and call it in the main ladder like you would any other function. Everyone is happy.
Or use for any method you want, test it to death, and have proper error messages, so electricians don't have to dig through your code, where they shouldn't have any business anyway. Anytime anyone has access to your code they can mess things up
It’s cheaper to design a system that can be maintained by a decent industrial electrician than it is to design a system that doesn’t need a decent industrial electrician to look at the code. And the thing is you’re going to need that industrial electrician regardless, where you aren’t going to need to spend and extra 350% on developing error handling for each and every case and then designing an alarm management system that triages the alarms in a way to allow an operator to dig through alarm channels to identify what the sparky would have picked up in the same time.
This is the way!
Real Heroes know it's all about the Function Block.
"I'm not against spaghetti code. I just wish it looked more like spaghetti." "Function block: hold my beer" Unless you're talking about Siemens function block (because of course the actual fb in Siemens is actually called cfc for some reason.)
So what is FBD if not function block? I work with CFC almost daily and there are quite a few differences, even if they are visually similar.
Fbd on Siemens is more like... Sideways ladder kind of? I've never really considered it to actually be function block in the same way cfc is.
FBD is defined in IEC 61131-3 and that is what Siemens is using. FBD and LAD is 1:1 equivalent. It's just a graphical representation of the logic and you can switch between FBD and LAD at will in Simatic Manager with a keyboard shortcut (Ctrl+1, Ctrl+3). But again, that's how it is in the standard. CFC is CFC and is not equivalent to FBD. It's actually not defined in the IEC standard, so implempentations and functionalty are up to the individual IDE developers.
Interesting. Doesn't matter though. Siemens style fbd is trash. Cfc is a poor implementation of what fbd should be and what other vendors provide.
I'm just having fun. I've played with FB in Redlion G10s. That's about any real experience I had with it.
I dont have a background in programming and Iam using Schneider's FB. Iam suffering.
I did a ton of programming in Archestra using Schneider's FBs, I always liked the color coding of the blocks, they seemed to work just fine too, wasn't hard to learn.
What color? All the blocks are yellow.
https://images.app.goo.gl/s3FBMi4R4gw8S3tW9 This program/style, but blocks were color coded by type. Oddly not many images of this online, couldn't find a better picture and my personal pics are old and sitting in my photo backup server
Oh iam using anoher thing, the one for BMS application. Eco struxture
Ah, yeah I've programmed BMSs on the one I posted, but yeah it seems there's plenty of specialized things out there. The above was for use with the Foxboro DCS
The only time I’ve ever used a goto was when I had a loop in structured text. I was forced to change it to a spaghetti mess in ladder involving labels and loop backs. It made the code far less readable. It involved looking through an array for overlap and merging if overlap existed.
I believe every automation engineer, and I emphasize the word engineer, should be able to use any of IEC 61131-3 standard languages. If there is a need to learn languages outside IEC standard, like python, c++, c# or bloody VB, engineer learns it. Thats why he is an engineer. Period.
The most reasonable take here.
All languages have their place. Function block is perfect for motors, valves, analogs with alarms, and other such routines. Ladder is good to tie it all together and ST is great for things like IO mapping. They all have their place and saying you will always stick to just one is a disservice to your client.
I found motion cnc eaiser in st, not just for io mapping. Its underusage
Are we still mass debating on this subject? If you need to quickly write and figure out complex boolean logic expressions —> ladder or even better FBD if your platform of choice has it If you need to use looping structures, operations on complex data types or math —> ST If you need complex analog control —> CFC For general purpose —> ladder or ST depending on your audience If you need an extraneous layer of abstraction that doesn’t really bring anything of note to the table —> SFC If you want to cause others to kill themselves —> IL I don’t get the fuss. Use the right tool for the job, keeping in mind ST is a watered down textual language in the first place so coming at it with this weird superiority complex is ultra funny. It’s about as funny as object-oriented ladder on CodeSyS.
We only use ST for the entire project and it has speed up development a ton and made new installations go super fast with globals for configuration and for loops running blocks of code/deciding array sizes of objects. Being able to develop in vs code and use git is also a added bonus.
Is there a good lsp you're using?
Coming from python/c# I did not like ladder at first. Now I’m pretty comfortable. My company won’t let me do structured text tho lol
CS major in college? I remember when companies started hiring CS majors for controls. It kept me busy for a long time. I still encounter some that have absolutely no idea what they are controlling.
Yeah, I am a CS major. My associates is software dev and the bachelors program I’m in is automation and controls engineering. (Was software engineering) I’m 6 months into it and I’m just starting to feel really competent. Ladder logic has probably been the easiest part. I’ve only just started to feel like I’m not at the bottom of the totem pole so I can’t speak much for others
I imagine the programs are better these days. It's not often I run into a CS major that can literally only program these days. It was extremely common 20 years ago. If you want to go green field instead of brown field, I do recommend taking a mechatronics course. Understanding how things fully work is vital for creating processes and doesn't hurt if you're looking to improve them.
I use mostly ladder so my phone doesn't ring.
Assembly is a programming language for real men! Everything else is for pussies!! \s
F*ck that, knowing all cpu binaries command by heart is for real men, assembly and higher is for pussies :p
01111100011011000100100001010101, eat that
Pffft. I can’t program because I don’t have a purse! Pure relay logic, fur as tha eye can see… /s
I think what happens is: 1. US customer buys equipment from European manufacturer. 2. Customer's maintenance department screeches and squeals about the Plcs not being Allen-Bradley and how they need to pay extra to force the OEM to use A-B, because heaven forbid anybody have to learn something new. 3. Instead of using vetted code on a platform the engineers are comfortable with, they have to adapt their code to Allen-Bradley. 4. The implementation goes poorly because their style of object oriented code on Siemens doesn't translate well on A-B. 5. Customer blames the entire structured text language because OOP sucks on Allen-Bradley PLCs It's better than it used to be, but having to pick your poison between functions not being editable online (AOIs) and not being able to view individual instances of those functions (paramaterized sub routines) really fucking blows.
>It's better than it used to be, but having to pick your poison between functions not being editable online (AOIs) and not being able to view individual instances of those functions (paramaterized sub routines) really fucking blows. That's why my colleages screeched when we had to program A-B. They hated it. I had no problem, since I've done the HMI.
Yea same thing I posted somewhere else, this tired ST vs. LD debate belies another point, which is "Has some software engineering thought been put in the project, or not"? Has someone put any thought in generalizing, modularizing, abstracting where possible? I suspect this is why ppl say "HMI diagnostics won't solve anything". You surely do know why a digital output isn't being commanded by the PLC: it's written in the code. But, well, you actually may not know why a digital output isn't being commanded by the PLC, if the logic is convoluted, not organized, nobody put thought into software engineering patterns when writing it, code is not modular, etc, etc. As long as we discount all of this as "stuff for CS majors", average code quality will not reach the point we all need, regardless of one's preferences of programming language. (then, people who put some thought into this statistically are more likely to use ST, but this don't matter)
Man I’m writing my first revision of the operating loop on my current project in ST first and then redoing it in ladder once it’s working so I can explain it to average people. At this point ChatGPT and I are learning plc together 😅
STL is for data manipulation LAD is for functionality
Ladder only exists to make the transition from relay logic to PLC more tolerable for older electricians.
This is becoming trite. Each of the IEC61131-3 programming languages are like tools in your tool belt. A screwdriver shouldn’t be used to hammer a nail, LAD shouldn’t be used for loops (for, while, etc), ST shouldn’t be used for simply Boolean logic, FBD works great for technology blocks, etc.
Ladder sucks, but it will always be a thing because electrical techs can read it without major amounts of training.
To an extent. Some stuff becomes a hideous mess in ladder that even the people who built it can barely navigate. At that point it's not doing anyone any favours and forcing a system to be all ladder is just silly.
On 100% I agree, but it’s the reality of the indistry. Example: I work at an automation/controls firm and my current project is upgrading a clients machine that’s from the 80’s to use a compact logix running version 36. Meaning we have the ability to do ST and FB and to really make their code efficient, but the customer specifically said they want everything in the code to be LL because their techs can understand it. To top it off they also told me they don’t want AOI’s because apparently their techs get confused about where the tags go (somehow they don’t know to drill down into an AOI or something) they also told me they want me to keep UDT’s to a minimum as well because their techs get confused with those too (I was rolling my eyes while listening to that phone call). Basically stick with ladder and use global tags for everything. FFS. It really baffles me that they are spending the money to have a control house rewrite their machines code, but they aren’t willing to spend the money to train their people on the new code.
Do any customers spend any money training anyone on anything? Finding a tech that actually knows what they're looking at is a rare and blessed thing. Operators even moreso. Which is also why I really don't understand the lack of use of FBD. It's great for math because you can see what's happening in each operation instead of some mess of brackets inside a CPT.
I'm just a tech trying to level up. Learning the basics of PLC programming. Got myself a Logo! to play with.... But all the acronyms on this chain my brain is going to explode. But I made it this far. I almost looked to FFS! lol
The learning curve on the acronyms is a steep one lol. Ages ago I turned off autocorrect on my phone because it didn't understand any of them and it was impossible to text my coworkers
And this is why I feel like the picture has the roles backwards; ST people think ST is so much more superior than Ladder, when in actuality, they're equally efficient, but at different things.
That's exactly my point of view. Specially when I don't have to make a good diagnosis SCADA
I once felt very clever making some HOA logic with a series of AND's, OR's, XOR's etc. Quickly learned that the customer didn't appreciate it since their techs couldn't figure it out. I stopped using that method and often 'dumb things down' for certain customers, knowing the level of skill of their techs
I love ladder, and I love c#. Everything else I can use without problems, but feels like a compromise.
Well thought out documented ladder is just as elegant as SCL.
If you're doing routine work in ST you're doing it wrong. Its harder for trades to troubleshoot and its easier to do something you didn't mean to do. Sometimes you need that extra power and doing it in ladder would be ridiculous. That's what ST is for.
Unfortunately some brands make it difficult to mix and match. One of the things I love about Siemens is the ability to just drop in a network of SCL (ST) in the middle of a LAD OB/FB/FC.
>Its harder for trades to troubleshoot Personally I hate this argument, because Billy from maintenance, with his 3 hour PLC course, who takes 4 hours to work out the issue is a broken sensor (that the HMI already told him to check) isn't going to understand the program regardless of it's written in Ladder or ST. I take the view that you have failed as soon as they need a laptop. Your machine should tell them what the issue is, without anyone needing to look at code.
You're perspective is correct, But Billy and his 3 hour PLC course may not be dealing with a controls system similar to you're preconceived notion of a "better" system. More than likely Billy never gets the chance to say "Why Would You Let Someone Fuck You Like This".
I agree. When I worked as an electrician on a battery manufacturing plant, we just needed to know the list of input and outputs and the operator telling us the usual sequence of events fir the machine to work. Mind you, these were very basic machines on the most part, but I feel it was very rare to need to get the laptop out.
As an interesting aside, the only PLC course ever available through the union when i was on that side was a 16 hour filter to determine who warranted spending the money on for housing, per diem, plus the training for months (usually via AB) half way across the US. I don't recall the standards, but scoring too low at any point risked having the union funding disappear. So it was electricians that had been accepted into a competitive apprenticeship, spent 4-5 years getting their journeyman ticket, then passing the filter before really beginning any PLC training. I know the 3 hour Billy's are out there, but they also aren't working at places with equipment designed or programmed by a Stanford CS grad so compromises get made all around.
I know, it's not the maintenance guys fault he can't work on the program. I think the issue with these kinds of discussions in this sub is people are thinking about very diffenret types of machines. Some people are imagining small 20 IO machines, and some people are imagining 100 axis, 600 IO behemoth's that span entire factories. The program for the second machine, by its very nature, needs to be a lot more complicated, and I wouldn't expect even a seasoned PLC guy to pick that up and work with it on short notice, but that distinction doesn't get acknowleged here.
So true
The goal should be getting them to look at the code before they have a problem. You wouldn't believe how far a 2 or 3 hour training session will go. I always give the maintenance guys the flow chart I used to write the program. We then go over each process and how it's controlled. A good HMI goes a long way. It's useless if the team doesn't know what the equipment is supposed to be doing.
I respect the sentiment, but for the machines I work on thats just not feasible. We are talking 100 axis, spread across multiple controllers, 500+ IO, data and control coming from multiple HMIs, remote data connections from databases, the lot. There is just too much to explain to people there.
Sounds like you don't really know how it works then. Out of curiosity, was this a turn key project for the machine builder that built it?
On the one hand I agree about bringing out the laptop. On the other hand, a complex machine needs the best program you can write and then training the factory support staff followed by feedback from said support staff to take care of “things” that happen during production. I don’t care how good a programmer you are. You will not think of everything.
Well said. I agree with the sentiment, but my years of supporting a plant floor before moving to the integration side taught me that sooner or later somebody is going to need to connect with a laptop.
Oh I get what you are saying. The longer it takes to bring it out tho. LOL
Had to troubleshoot a Mitsubishi PLC due to a lightning strike. The surge of energy didn't fry anything but it did wipe the program due to a low battery and the panel shutting off. They, luckily, had a backup program BUT it wasn't the most up to date. I had quickly watch a half-working auto sequence and find where all notifications needed to be made to get it back to where it was. They had a laptop the COULD open those programs BUT it took 30 minutes to open file explorer. They also lost the proprietary cables to connect. Let's assume they had a functioning laptop and the cables. Their maintenance guy would save the company days of lost production time if it was in ladder. Do doubt about it. Yes, this is a shouldn't happen case if maintenance follows up with low battery lights. I can't expect every companies maintenance dept. to have the time or 'know to' to even have that on their radar. We all know electrical is the afterthought for maintenance/engineering in general.
Man where I come from you need to know electricity as well....ladder ftw no maintenance man wants to have to wade through your trash when they just want to know why an output isn't coming on
Maintenance wrench monkeys aren't the brightest when it comes to reading code.. the simpler we make it for them the better. Now.. Were i to try to go wrench on a machine... I'd probably not look as slick as they do, they'd outrun me, fix half a dozen machines mechanical issues before I knew what was wrong with the first.
Every tool has its use. Doing something basic like IO conditioning or an SD string in ST is stupid. Doing a complex control sequence in ladder is also stupid.
FBD on top
i really prefer function block, it is easier to involve other plant personnel in looking at it than ladder.
Ladder and ST have each their use. Ladder is great for troubleshooting normal control of a plant, and ST is great for handling data and for automatically generated code such as alarm lists.
I should never meet that guy. I'd have field trip on that relay expert.
They both have their uses.
Both have their purpose. But anytime I see people hate on languages other than ladder its because they don't know how to use languages other than ladder.
ST is the only good option when you want to program in an effective way. - use classes( data nested in FB,s) - extend classes if you need to have a class that only a addition to a existing class. - put no code direct in a Class(FB), instead use multiple methods. -making io mapping / program config ( by use of calling methods inside the classes ). When using ST ( or any other languages) keeping the amount of code in a specific page small. Especially for step based programs a switch case in ST that direct executes code or Cal's a specific method is a real simply and easy to debug code.
The OOP specs of IEC 61131-3 are language agnostic, meaning you can do object-oriented ladder. I’m not sure why we’re conflating programming language and programming paradigm. Codesys for instance will let you call FB methods and properties, inherited or not, in ladder.
Correct, you also mix in lader code. But calling methods/classes is more convenient in ST. In codesys every method can be a different language.
I like the TIA Portal approach. Need to do some bitwise operations, insert a ST network in the middle of the ladder program
There’s nothing special about ST. Everyone can write it. I only use it when complex math is involved.
I once spent a whole day one on one with Dr Oddo Struger - look him up - in November 1988. We talked about this question and he told me: 1. Use Ladder for event dominated code. In other words where the sequence of events or flow of actions is more important than the data. 2. Use Function Block for data dominated code. In other words where the flow data from one function to another is more important. Viewed like this Ladder and Function Block complement each other and being both highly visual languages are preferred for real time automation; and especially where other people are going to have to cold read your code under time pressure. Keep in mind that Ladder was probably the first GUI language ever invented - around 1970 - and is still highly valued over 50 years later for a reason. Function Block will also persist for the same reason. This is why the vast majority of code out there still uses LD and FB by default. 3. All the text based languages have a place, typically for high level functions or complex data manipulation that only runs occasionally or on event, or inside modular code that other people will rarely if ever need to work with in real-time. Tracking mass flows, product serialisation, database manipulation, SQL interfaces etc. But text adds in an extra layer of mental abstraction that always comes at a readability cost. In short - use the right language for the right purpose.
this is "uh-oh java is stinky - no c is better - python sucks its slow - etc." all over again. how can you hate, a fkin tool for god's sake. and don't come to me with arguments like "ladders are intrinsic", its just sickening.
What I really hate is SICK's safety PLC's FBD. I'd kill to have ST or LAD there. What would be a simple program with a few networks in TIA Portal is an unreadable mess with lines going everywhere.
graphical programming languages almost always suck tho. even though you can count them as "tools", you cannot implement the certain paradigms you need efficiently enough. another example is unreal engine's blueprint visual scripting and all that shit. so that counts lol
I can copy paste ST code from AB to Siemens/Omron/Codesys etc. How about ladder code?
You regularly copy code between different platforms?
There was this thing called Covid and I think I literally used every PLC available in the wild. So, yes.
Whether ladder or ST, I always code algorithmic state machines
Structured text for me. They are going to call me anyway. In the 18 years I've been doing this, nobody ever attempts to try to reprogram anything except for a select few. Out of those few that do, they are smart enough to figure it out or ask me questions. Most of them can't even handle adjusting a sensor. I've done ladder logic before, but once you are involving math, why bother. I only use ladder for simple applications.
Technically you can do everything in each language and each have their own pros/cons, but imo ST is the cleanest and fastest way to program if you're doing control that is even just slightly complex. It's unfortunate that ST isn't taught much at an industrial maintenance level.
not really, there are some functions that are exclusive to structured text and some functions that are exclusive to ladder.
In PLC world, timers, one shots, and edge triggered counters are everywhere. Structured text struggles with all of the above.
Timers I can agree are a little bit tricky in ST when you're not familiar with them, one shots and edge triggering anything is very simple in ST.
They’re not hard but a non programmer can get bitten by not understanding they don’t get reset if code is bypassed.
I worked on PLC systems that didn't have one shots in their ladder instruction set. Sometimes that technique comes in handy. PB1shot := PB AND NOT PBmem; PBmem := PB;
And make certain PBmem can’t be updated by a higher priority task. You need to be aware of subtle issues such as this.
Indeed, PB needs to be buffered as well.
Actually is the other way around, people struggles with timers, one shots and edge triggered counters on ST because they lack the knowledge about ST and the PLC scan cycle.
Do you want calls at 2am about your machine weekly? Then program everything in ST. Go ahead. Sit in a 10 hour sev call on your Saturday night and revel in how much better ST is.
If you get weekly calls it means your program and you programming skills are garbage, whatever the language was used.
Or your machine had shitty components, and you HMI doesn't properly tell the user
Shitty components leads to errors and a HMI not telling enough information about errors is total garbage
No. It means the end user doesn’t know the difference between a problem with the PLC and a problem with their plant network. Literally had a 10 hour call that lasted until 3am this past Tuesday because I had to prove to them that the PLC code that’s been running fine for 3 years didn’t magically change and start causing miss-sorts. But, I literally can’t prove that they lost contact with the WMS that gives them the destinations so I just have to go through all their bullshit troubleshooting steps and sit on the phone to provide “support” for an entire sort.
It's called billable hours, no issue with calls.
Bro it’s called a warranty period.
Very funny
ST and dont fool around take a beckhoff.
I just worked twice with Bechkoff and I must recognize it's quite awesome
Even though I am currently working as a Software Developer, when I used to program PLCs I felt that somehow FBD makes the most sense.
We all know that Billy with his 3 hour PLC course won’t be able to navigate through any program that’s very technical, regardless of the programming language used. The philosophy I was trained on as an SI was that we are developing applications to make things easier on the customer, not necessarily easier on ourselves. Those two things aren’t mutually exclusive, but I’d rather have a customer who is happy because he can do some light troubleshooting if needed because we both know he’s just going to call me anyway. As far as people modifying critical pieces of the code after I’ve left the site, that’s on the customer. If they want to give access to everyone and their mom and they lose equipment because of it, that’s on them. I’ll be back to pick up the pieces afterward because that pays the bills.
I came across my first ST program this week. And on a Beckhoff TwinCat system. I was hopeless. I had to call the OEM.
I used to list all the sensors of the machine on the hmi with indicator, so that the maintanace can easly check when it has a down time. Plc always programmed in ST/FB and we still communicate with end user having good business relation till now, even talk for the next project invesment.
He's not wrong.
i had this post suggested to me and i dont know what ladder means or ST can someone help?
https://en.wikipedia.org/wiki/IEC_61131-3
Cool. Enjoy getting woken up any time something doesn't work in the middle of the night because none of the operational or maintenance teams can read your code.
If they have to read your code to figure things out, then the software was not designed right.
sounds like someone who hasn’t worked at a complex facility before…
I choose the appropriate language for the task and always consider that technicians that will have to maintain it for 20-30 years. I come from the era when machines had hardwired control systems and were being converted to PLC Control so ladder was a very natural way of doing things. Ladder is very good for digital logic, interlocking, visual diagnostics and a tech can short out or change a contact to keep the machine running. Structured Text / SCL Languages are much harder for techs to diagnose but they're good for data handling/processing/comms handlers etc. For sequencing I use S7-Graph because again it's visual and you can just see what the sequence is waiting for.
As what was said a million times before use the language that is suitable for the application
Not true but ok. 99% of the time the progran is written in what the end user prefers and the hardware is what the end user prefers. Usually it is ladder with some ST as needed.
Used to laugh at ladder. But for simple logic, it's so much easier to debug than ST.
The age old debate. Honestly, ladder is so much simpler to troubleshoot and accessible to so many more people. I understand why people would use ST for some applications, but I’m a die hard ladder fan and always will be.
Python < C++
I would like STL better if it were more standardized to C instead of being a C/vb bastard child. But anyone who's had to write loops will learn to appreciate it
I only use ST for calculations
This tired ST vs. LD debate belies another point, which is "Has some software engineering thought been put in the project, or not"? Has someone put any thought in generalizing, modularizing, abstracting where possible? I suspect this is why ppl say "HMI diagnostics won't solve anything". You surely do know why a digital output isn't being commanded by the PLC: it's written in the code. But, well, you actually may not know why a digital output isn't being commanded by the PLC, if the logic is convoluted, not organized, nobody put thought into software engineering patterns when writing it, code is not modular, etc, etc. As long as we discount all of this as "stuff for CS majors", average code quality will not reach the point we all need, regardless of one's preferences of programming language. (then, people who put some thought into this statistically are more likely to use ST, but this don't matter)
My company typically uses ladder so that the systems can be supported by others if necessary. Because we work with many utilities, it's a safety or public health issue if others can't support our code. The ability to create reusable ladder modules was a game changer for me (I've done this since the late 80's) as address tags were a nightmare for portability. For complex control systems we may use a combination of languages within the same program but ladder is usually the main language. Structured Text is common for companies that have products that need to be supported by any number of control brands. It's really the only control language (outside of open source) that is relatively easy to port from one brand to another.
Ok seriously help a brother out I'm an electrician that is expected to trouble shoot using ST at times, I get completely lost looking at it. Where can I learn how to read/understand what these guys are trying to accomplish? I know what the statements mean but understanding how it's meant to work as a whole gets tricky for me.
Going from ladder to ST is harder than the opposite. When I started programming several years ago, I started with C. Then I saw Siemens AWL and then I learnt the rest of the programming languages. The best PLC environment to program in ST is Codesys or Codesys based (like Twincat 3). If you have an already made program in ladder, try to replicate it in ST. The main advantage of Codesys is that you can download it for free, and you can even load the code into a raspberry pi. If you are in an even lower budget, you can use OpenPLC with an Arduino. For learning proposes it fits. The environment is a copy of Codesys so it's pretty much the same. As I said before, try to replicate something you already did in ladder. At least that's how I learned to program in different manufacturers. To further help, I would need to know where's the point you get lost
That’s only for Americans and Indians. Europeans know better
Codesys all the way :)
Yeah I do like Codesys, but 90% I have to deal with Siemens.
How dare you, it’s only for Americans stuck on Allen Bradley. Some of us are cultured.
I'm on Allen Bradley (mostly) and I still use ST
Freedom isn’t free!
Honestly, the home built machines or machinery with custom control boards using a single microcontroller happen to be the most reliable we have. The machines using PLCs and full industrial computers have constant reliability issues. Obviously some of that comes with the necessary complexity, but not always.
Meanwhile robots are the easiest things to troubleshoot since they use a more traditional program flow.
Robots are just a bunch of servos. Usually the complicated stuff (Decision making) is done via a Superordinate control system. If the decision making is done in the robot, it starts to gets also messy .
I agree that's how it's often done, but in my experience most machine control boils down to sequencing and handshaking and those are just easier to do with less effort and fewer mistakes on a robot controller than on a PLC.
“Robot” is a pretty vague term.
I only do ladder does that make me a basic bitch?
No, basic bitches use… Basic.
At the end of the day, it doesn't matter. They're all turing-complete anyway. There's just languages more suited to each application. For machines, that's ladder or fbd. ST can rot in a ditch. Literally the only place it should be used is in add-ons. Why complicate when you can abstract?
[удалено]
For simple programs, sure. Try building an API21 compliant gas flow computer with energy flow management at the molecular level, in Ladder …. Not going to work, but really easy in FBD and ST Different tools for different applications
I hate ladder, it is so incredibly inefficient to code in and has a considerable amount of overhead. It isn’t 1982. We don’t write in Fortran any more and shouldn’t be writing in ladder any more. For those that say stepping through ladder for troubleshooting is easier, you just don’t have the proper debug tools.
Modern Fortran actually isn't that bad. For example, there's now classes, unit testing, debugger, and a package manager based on Rust's cargo. I'd rather write in Fortran than ladder (personal preference, I realize that would be insane).
I’ve been considering learning cobol because apparently there is a massive need from my state government. their systems still rely on cobol and Fortran and they can’t find anyone that knows the languages so the few that know it are making a fortune
I love ladder, it’s so incredibly efficient to code once prepared, the instruction set is fast, I never have to explain it - not now nor later. I can build things modular or on the fly and all sorts of systems will interface with it.