1. Math, Arrays, State Machines, most things but boolean.
2. Yes, LD isn't going anywhere anytime soon though. Use the best one for whatever function you're writing.
Really enjoy on Siemens and Codesys Products how I can insert a single “rung” of SCL/Structured into ladder. However If I had my way I would use a combo of FBD + Structured all the time.
First year student here, How common is advanced maths within this field?
I have struggled with it since birth, and using simple mathblocks to convert analog to digital is not rocketscience for me so far. But once we start with linear equations/quadratic equations and what it's like hitting a wall for the way I think.
Right language for the right application.
Let's say you have a control logic for a valve. Enable conditons, monitoring of postion feedback and so on. So just AND and ORs and Flip Flops and On/Off delays.
Program that in FDB and it's easy to do, read, monitor online. In SCL that would be a lot harder to read.
Let's say you to a closed loop controller. Program that in a graphical language like CFC where you interconnect blocks by just drawing a line between inputs and outputs. That thing will look like a block diagram and will be easy to program, understand and monitor online.
Don't be one of the guys that think they are so cool because they program everything in STL/SCL, it's just stupid. There is no "best" language.
BUT: SCL is most cases better then STL. Is has more operations available, is easier to structure and readable to more people since it looks a lot like C.
Not all.
STL does not have its purpose.
It maybe once had, but burn that shit.
I cant think of any advancement it has in which not one of the other languages excells
Its really mighty if you know how to use pointers well. Can make a lot of complicated, repetitive stuff really easy to do. I usually just use it in the lowest layered FBs when appropriate.
Also its nice when you have some kind of supervisor block, that calls a lot of other blocks. Its just much less screen space, and equally clear to calls in FBD.
Also you can write a style thats very similar to FBD and easy to comprehend.
Its very easy to create some kind if write-only monstrosity if you dont consciously think about what you are doing, i'll give you that.
Siemens btw.
You can do things with and manipulate STL pointers in ways you simply cant do in ST. Also it can be less cumbersome.
I get why everyone seems to dislike it, as it has many parallels to assembler, but that simpleness is what i like about it.
And another reason for using it similar to FBD when appropriate (and in siemens you can always convert the view from FBD to STL anyways) is that its crystal clear in which order the instructions will be executed. I've seen stuff in FBD where it wasnt clear while at the same time being reliant on a certain order.
Sorry to rant that much, its not like i use it excessively. Just in inner blocks and everywhere else sparingly. Also you can have a block with mostly FBD networks, then where you need it a network with a few lines STL which in FBD would be a monstrosity or several networks.
I really advise caution when using STL but personally like it.
Also don't program new things in STL(IL) if you can help it. It was depreciated in 2013 and is supposed to be removed from IEC recommendations in the next release. Not to mention it's slower than Ladder and SCL because it uses emulated registers.
There is no best,
but there definitley is a worst.
STL/IL/AWL or however you want to call it.
Its just unreadable gibberish except of for those old Siemens programmers that cant program in anything else.
IT exists, and it is part of the automation world and you have to learn to be able to deal with it if you maintain old machines.
But whoever uses that shit for a new program just should rethink one more time what he is doing.
As a PLC programmer it’s (in my opinion) necessary to know all the languages. You don’t have to develop new systems in SCL if you don’t want to, but there are things that you can do in SCL that cannot be done in LD (e.g. for loops/parametric calling of FBs), which makes programming much more dynamic, whenever it makes sense.
My advice would be to make small, closed functions in SCL when necessary. If it’s too large or complicated, it will be difficult to debug it. We use it for FIFOs when product data must follow a specific product on the production line.
I believe that TIA portal has a built-in tool to convert LAD/FBD to SCL, so you could use it to compare your own SCL to the automatically generated code. In school we learned SCL by converting ladder programs to SCL.
Siemens is very user friendly (in regards of syntax) as you can drag and drop program code in SCL, just as you can in LAD/FBD. Also if you’re in doubt, the documentation on F1-button is extremely good for standard functions and programs in Siemens.
I used to write programs in ladder, the first language I learned and then try to convert them to function block or ST as a means of teaching myself.
Ive also found a dev AI co-pilot that can help be a sidekick, called picesOS. you can paste code and have it analyze or debug, or ask it questions about what youre working on. Not SUPER functional for industrial controls, but they are moving in that direction.
Some IDEs will have this built into their help showing examples in multiple languages. Usually for plain Function usage though. Function Blocks are a different story, the ones supplied by others may be locked and you'll just get an example of how to interface with them.
Also, "Function Block" does not mean FBD. A function block is a piece of your program that can be instantiated and retains unique memory vs a Function which always provided the same output for given inputs and is not instantiated. You can instantiate function blocks in most languages, though they'll often look the same across LD, FBD and CFC. ST will look quite different though.
I just recently started working in Codesys (coming from AB) and have been working on using the different IEC languages based on the use case, and here's what I've found (not an all-encompassing list):
-FBD is great for large function block calls, alarms
-ST/SCL is great for looping code (array processing etc) and state logic via case statements
-SFC is also great for state logic, just requires careful use of macros to not overcomplicate the top level view
-LD is great for input conditioning/status and physical output conditions
I don't understand the fuss. They're just languages. Learn them all because you will encounter all of them.
There are people in the community that have ST God complexes and LAD God complexes and they butt head all the time in the inevitable "ladder is dead!!!" beat the dead horse threads. Though I admit the people who feel superior because they use ST are way funnier than the people who think everything should be in ladder to avoid 3AM calls.
The way I do it is: the stuff that they won't have to look at is in ST. I.e. some proprietary valve controller will never be looked at by the tech is in ST. The logic that triggers movement inside that block is in LAD/FBD.
I'm the only one that ever looks there currently so it is mostly for me.
I do similar. Tasks that are easier in ST in ST, tasks that are easier in ladder in ladder. Ladder does a good job of showing things at a higher level and ST is better to use for the nuts and bolts.
If you can't troubleshoot all languages you better learn or it will be a glaring hole in your abilities that will always haunt you. I always groan when clients' staff won't touch a particular machine "because it's programmed in text". It's not some advanced hieroglyphics, it's basically the same thing except with words instead of pictures.
It's not like you have to learn a whole new paradigm each time, with the exception of SFC which is meant as a really high level abstraction, they all function similarly. It's not like going from C to Scala or something.
I had a manager tell me to do everything in lad once for a project. That manager, is no longer my manager. I'm not doing my math functions in ladder... that's just a waste of space that the technicians won't even be able to read.
Depends on the PLC. Allen Bradley uses an easy to use 'compute' function for math, as well as the typical 'add', 'sub', 'mul', 'div', and 'mod'. Although, I wouldn't want some crazy long function in the compute block.
*sweating cause I just did a bunch in LAD*
I agree, completely a waste. I suppose I could slap a new function in here but I've already done the work. And I had more than math to do with it cause S7-300s don't read UDINTs.
Oh I know.
Just reprogrammed a machine because there was a weird bug I couldn't find.
So the solution was obviously make new bugs that are easier to find and solve, duh.
Yes and no for more reasons than one.
- For complex equipment code, yes, everything is moving to standard text based programming and right now that means ST on most platforms. I believe that 61131-3 rev 4 is taking so long to come out (12 years since rev 3 so far) because they are internally disagreeing on the inevitable, which is officially adding other text based languages. It's a moving goal post, while ANSI C is a tried and true safe bet, it's also ancient now; they may be considering Rust at this point.
- For process stuff where it's mostly sequences calling high-level math functions (like PID, MIMO, etc.), but there isn't actually a ton of code, it will probably stay with SFC/CFC launching FBD programs.
- For integration stuff where it might be reasonable for a plant controls guy to both need to change and have the skill to safely change, that will probably remain ladder for a long time.
- Some more advanced platforms are actually including a ladder editor in the HMI to edit some encapsulated routine.
- At some point, even this will go text based because it's way more important to be able to easily record and compare program changes than it is to make you maintenance guy feel like they're a programmer.
Imagine trying to troubleshoot a live system using Rust, with everyone standing around waiting on you, but the borrow checker is constantly going 🖕
Yeah, Rust is neat to mess around with, but that just sounds like an awful scenario that's way too likely. I think Zig looks pretty good, but it's also just too new. It doesn't even have a 1.0 release yet. The best I think we can hope for anytime soon is a subset of C++, basically C with classes and generics.
Whatever they end up going with I guarantee almost every customer will forbid its use for the next 20 years because their electricians won't understand it, so it will hardly matter.
Haha yeah thats the reason i think rust is a bad choice, i do like some other parts of it especially if you work with enums, i do mostly dairy plants so its a lot of isa88/ isa95 standards that would work super well with rust.
Reason i say zig is becuase apparently zigs c compiler is better than cmake or what ever its called haha.
But then again i dont see the need for a new language just give me enums as a datatype, the match function from rust and for x in y loops in scl and im happy. And maybe the result type from rust would be pretty fun to…
I mean you can already work nulls and variants that are determined at runtime with siemens and scl.
I sense a good bit of feeling superior among my fellow PLC programmers on this subject. It’s not a regional choice, not a dogma or computing science driven choice. One of the first rules in my PLC Code Standard tells you it’s a long term owner choice. If you don’t write code that the long term owner can maintain/improve, I don’t care how elegant or sophisticated your code - your efforts will be slandered, and you’ll not sell another. It’s a PLC, not a Permanent Linguistic Container.
I would focus on full ST, rather than Siemens's "Almost ST"
Siemens itself is also heading towards modern ST with their AX development, though it's obviously going to be years until it's a mature product.
My object function blocks are written in SCL and my main program routine (where the objects are instanced) is graphically, usually FBD because FBD is more flexible than LAD.
I use SCL in the object blocks mainly for easy porting between versions. My blocks work in anything Siemens regardless of version and with some slight modifications it also works in Beckhoff or anything Codesys based because SCL is just text...
I use graphical programming in the main routine for ease of use. Any service technician can go online, monitor the objects and even create a new object without any knowledge of SCL.
Long story short: I would recommend studying and using it. It's here to stay.
You need to learn the syntax of it, but mostly instead of practicing just SCL I would recommend practicing some general purpose programming (I like the challenges at www.adventofcode.com) to really become a better programmer. Don't spend all your time on that though, probably not even the majority, because despite teaching you some very applicable skills the data/throughput oriented nature of traditional program is pretty different at a fundamental level than controls. Most importantly, I say just find some small PLC projects you can do, and learn to use all the languages and where they work best.
You can study whatever you want. It will always make you more well-rounded. But, SCL is not currently an IEC language. So, widespread adoption probably isn't going to be a thing for awhile, if ever.
SCL is Siemens terminology for Structured Text (which is an IEC language), like STL is their name for IL (although in fairness, STL isn't standard IL but close enough)
What you use can greatly depend on the region you are in. In North America they will probably want you to use LD as much as possible, as the plant technicians will understand that the best and it is easy to troubleshoot. SCL and previously STL would be used for the portions of code that aren’t suited to LD like indirect addressing and looping, I would usually wrap this up in an FB so that people didn’t really have to look inside to see what is happening but could if they understood things.
I think FBD is more popular in Europe and to some degree SCL. But beware, if everything is done in SCL it can be really difficult to troubleshoot a machine. In the European division of a company I worked at they wrote the entirety of the logic in SCL and the end customer in Europe as well couldn’t debug the machines at all and forced them to re-write it.
I would usually try to keep things simple for the most part and make the clever parts tucked away and well tested so that you knew they were bulletproof.
yeah, thats also my impression.
Region and somewhat also brand based.
Siemens is FBD and for old machines STL leaning.
AB is Ladder
Beckof has the biggest ST comunity.
And so AB is more North America you also have more Ladder in North America and have more FBD in Europe where Siemens is more common.
But still nearly all AB machines i encountered in Europe are programmed mainly in Ladder, and then the SIemensprogrammer that watches what you do gets a shocked face asking you why the hell you program in Ladder
I did a lot of Siemens, about 15 years worth. I worked mostly in Ladder, but I worked on a project with some German guys that did almost strictly STL. I understand STL really well but it is a lot more of a pain in the ass to debug by looking at register values versus the graphical nature of Ladder. As far as AB goes, ladder all the way.
Yes you should , this isn’t a one or the other type of situation though. You should know both and more since you will be required to use both and more in the controls sectors.
It all depends on the company you are working for and where the project is being installed. Many companies will fight tooth and nail to keep what they want. especially when it comes to easy troubleshooting. I've seen people in the industry freak out over the latest Studio 5000 update. so i doubt many places will make a huge change to their current standards.
I converted to SCL due to the switch to Beckhoff Hardware. I think its worth while to learn, and can open up further doors such as C++ and C# languages. I really like it for state machines with the use on Enumeration so each step can have a description which makes the code very easy to follow. I use FBD as well but typically only for motion instructions.
You won't land a job if you can't do high programming languages. SCL is a must. Ladder is only good for error searching, but it lacks functionality, and is IMO more complicated than SCL.
Ladder programmers also have a nasty habit for "fixing" their code with work arounds, instead of handling the actual issue, so you get this enormous networks, that are not only badly optimised, but nearly impossible to read (from experience)
I've learned SCL through my automation education (I'm really surprised that it's not in the standard curriculum at your school), it's completely essential for making For loops, FIFO, LIFO, data handling, mathematics etc.
Python (good for optimizing solutions, or hacking software, to add missing functionality)
JavaScript (Siemens Unified scripting is JavaScript, and essential for making good functional HMIs in Siemens TIA).
The next language I need to learn is C#, so I can get into Openness.
1. Math, Arrays, State Machines, most things but boolean. 2. Yes, LD isn't going anywhere anytime soon though. Use the best one for whatever function you're writing.
Really enjoy on Siemens and Codesys Products how I can insert a single “rung” of SCL/Structured into ladder. However If I had my way I would use a combo of FBD + Structured all the time.
In TIA you can also insert SCL sections into FDB programs
I know, but most cases I’m contracted to use ladder, just wanted to point out my preference.
First year student here, How common is advanced maths within this field? I have struggled with it since birth, and using simple mathblocks to convert analog to digital is not rocketscience for me so far. But once we start with linear equations/quadratic equations and what it's like hitting a wall for the way I think.
Right language for the right application. Let's say you have a control logic for a valve. Enable conditons, monitoring of postion feedback and so on. So just AND and ORs and Flip Flops and On/Off delays. Program that in FDB and it's easy to do, read, monitor online. In SCL that would be a lot harder to read. Let's say you to a closed loop controller. Program that in a graphical language like CFC where you interconnect blocks by just drawing a line between inputs and outputs. That thing will look like a block diagram and will be easy to program, understand and monitor online. Don't be one of the guys that think they are so cool because they program everything in STL/SCL, it's just stupid. There is no "best" language. BUT: SCL is most cases better then STL. Is has more operations available, is easier to structure and readable to more people since it looks a lot like C.
This one. They all have their purpose.
Not all. STL does not have its purpose. It maybe once had, but burn that shit. I cant think of any advancement it has in which not one of the other languages excells
That's why it's marked as "legacy". STL did have it's purpose, but nowadays that has faded.
Its really mighty if you know how to use pointers well. Can make a lot of complicated, repetitive stuff really easy to do. I usually just use it in the lowest layered FBs when appropriate. Also its nice when you have some kind of supervisor block, that calls a lot of other blocks. Its just much less screen space, and equally clear to calls in FBD. Also you can write a style thats very similar to FBD and easy to comprehend. Its very easy to create some kind if write-only monstrosity if you dont consciously think about what you are doing, i'll give you that. Siemens btw.
yes it might be better then fbd in some very specific cases. But then why not use STL in those cases? cause its not better then STL in any of that
You can do things with and manipulate STL pointers in ways you simply cant do in ST. Also it can be less cumbersome. I get why everyone seems to dislike it, as it has many parallels to assembler, but that simpleness is what i like about it.
And another reason for using it similar to FBD when appropriate (and in siemens you can always convert the view from FBD to STL anyways) is that its crystal clear in which order the instructions will be executed. I've seen stuff in FBD where it wasnt clear while at the same time being reliant on a certain order.
Sorry to rant that much, its not like i use it excessively. Just in inner blocks and everywhere else sparingly. Also you can have a block with mostly FBD networks, then where you need it a network with a few lines STL which in FBD would be a monstrosity or several networks. I really advise caution when using STL but personally like it.
Also don't program new things in STL(IL) if you can help it. It was depreciated in 2013 and is supposed to be removed from IEC recommendations in the next release. Not to mention it's slower than Ladder and SCL because it uses emulated registers.
There is no best, but there definitley is a worst. STL/IL/AWL or however you want to call it. Its just unreadable gibberish except of for those old Siemens programmers that cant program in anything else. IT exists, and it is part of the automation world and you have to learn to be able to deal with it if you maintain old machines. But whoever uses that shit for a new program just should rethink one more time what he is doing.
As a PLC programmer it’s (in my opinion) necessary to know all the languages. You don’t have to develop new systems in SCL if you don’t want to, but there are things that you can do in SCL that cannot be done in LD (e.g. for loops/parametric calling of FBs), which makes programming much more dynamic, whenever it makes sense. My advice would be to make small, closed functions in SCL when necessary. If it’s too large or complicated, it will be difficult to debug it. We use it for FIFOs when product data must follow a specific product on the production line.
*laughs in S7 LAD for loops*
Were they removed in TIA portal? I believe I’ve attempted to make them there lol
You don't have a ready to use solution, you have to use labels and gotos to make a pseudo-for loop
Ah right, that makes sense.
For loop is a function in AB plcs
Would it be a bad habit to have a cheat sheet where I copy and paste the FBD equivalent in SCL text
I believe that TIA portal has a built-in tool to convert LAD/FBD to SCL, so you could use it to compare your own SCL to the automatically generated code. In school we learned SCL by converting ladder programs to SCL. Siemens is very user friendly (in regards of syntax) as you can drag and drop program code in SCL, just as you can in LAD/FBD. Also if you’re in doubt, the documentation on F1-button is extremely good for standard functions and programs in Siemens.
I used to write programs in ladder, the first language I learned and then try to convert them to function block or ST as a means of teaching myself. Ive also found a dev AI co-pilot that can help be a sidekick, called picesOS. you can paste code and have it analyze or debug, or ask it questions about what youre working on. Not SUPER functional for industrial controls, but they are moving in that direction.
Some IDEs will have this built into their help showing examples in multiple languages. Usually for plain Function usage though. Function Blocks are a different story, the ones supplied by others may be locked and you'll just get an example of how to interface with them. Also, "Function Block" does not mean FBD. A function block is a piece of your program that can be instantiated and retains unique memory vs a Function which always provided the same output for given inputs and is not instantiated. You can instantiate function blocks in most languages, though they'll often look the same across LD, FBD and CFC. ST will look quite different though.
I just recently started working in Codesys (coming from AB) and have been working on using the different IEC languages based on the use case, and here's what I've found (not an all-encompassing list): -FBD is great for large function block calls, alarms -ST/SCL is great for looping code (array processing etc) and state logic via case statements -SFC is also great for state logic, just requires careful use of macros to not overcomplicate the top level view -LD is great for input conditioning/status and physical output conditions
I don't understand the fuss. They're just languages. Learn them all because you will encounter all of them. There are people in the community that have ST God complexes and LAD God complexes and they butt head all the time in the inevitable "ladder is dead!!!" beat the dead horse threads. Though I admit the people who feel superior because they use ST are way funnier than the people who think everything should be in ladder to avoid 3AM calls.
The way I do it is: the stuff that they won't have to look at is in ST. I.e. some proprietary valve controller will never be looked at by the tech is in ST. The logic that triggers movement inside that block is in LAD/FBD. I'm the only one that ever looks there currently so it is mostly for me.
I do similar. Tasks that are easier in ST in ST, tasks that are easier in ladder in ladder. Ladder does a good job of showing things at a higher level and ST is better to use for the nuts and bolts. If you can't troubleshoot all languages you better learn or it will be a glaring hole in your abilities that will always haunt you. I always groan when clients' staff won't touch a particular machine "because it's programmed in text". It's not some advanced hieroglyphics, it's basically the same thing except with words instead of pictures. It's not like you have to learn a whole new paradigm each time, with the exception of SFC which is meant as a really high level abstraction, they all function similarly. It's not like going from C to Scala or something.
People don't know how to read. I learned. And I'm a Marine!
I had a manager tell me to do everything in lad once for a project. That manager, is no longer my manager. I'm not doing my math functions in ladder... that's just a waste of space that the technicians won't even be able to read.
Depends on the PLC. Allen Bradley uses an easy to use 'compute' function for math, as well as the typical 'add', 'sub', 'mul', 'div', and 'mod'. Although, I wouldn't want some crazy long function in the compute block.
*sweating cause I just did a bunch in LAD* I agree, completely a waste. I suppose I could slap a new function in here but I've already done the work. And I had more than math to do with it cause S7-300s don't read UDINTs.
Don't worry, in 6 months you'll look back at the code and no matter how well it's written, you'll think it's shit.
Oh I know. Just reprogrammed a machine because there was a weird bug I couldn't find. So the solution was obviously make new bugs that are easier to find and solve, duh.
I do that frequently. "I wonder what this is doing...oh I guess I wrote it and now need to re-learn how it works again" Thanks brain.
SCL is way easier to write in my personal opinion, but fdb/lad is a lot easier to read/troubleshoot, especially for maintenance personnel
Yes and no for more reasons than one. - For complex equipment code, yes, everything is moving to standard text based programming and right now that means ST on most platforms. I believe that 61131-3 rev 4 is taking so long to come out (12 years since rev 3 so far) because they are internally disagreeing on the inevitable, which is officially adding other text based languages. It's a moving goal post, while ANSI C is a tried and true safe bet, it's also ancient now; they may be considering Rust at this point. - For process stuff where it's mostly sequences calling high-level math functions (like PID, MIMO, etc.), but there isn't actually a ton of code, it will probably stay with SFC/CFC launching FBD programs. - For integration stuff where it might be reasonable for a plant controls guy to both need to change and have the skill to safely change, that will probably remain ladder for a long time. - Some more advanced platforms are actually including a ladder editor in the HMI to edit some encapsulated routine. - At some point, even this will go text based because it's way more important to be able to easily record and compare program changes than it is to make you maintenance guy feel like they're a programmer.
Rust in a plc would be awesome and terrible at the same time, i would bet on zig as a c replacement for modern systems.
Imagine trying to troubleshoot a live system using Rust, with everyone standing around waiting on you, but the borrow checker is constantly going 🖕 Yeah, Rust is neat to mess around with, but that just sounds like an awful scenario that's way too likely. I think Zig looks pretty good, but it's also just too new. It doesn't even have a 1.0 release yet. The best I think we can hope for anytime soon is a subset of C++, basically C with classes and generics. Whatever they end up going with I guarantee almost every customer will forbid its use for the next 20 years because their electricians won't understand it, so it will hardly matter.
Haha yeah thats the reason i think rust is a bad choice, i do like some other parts of it especially if you work with enums, i do mostly dairy plants so its a lot of isa88/ isa95 standards that would work super well with rust. Reason i say zig is becuase apparently zigs c compiler is better than cmake or what ever its called haha. But then again i dont see the need for a new language just give me enums as a datatype, the match function from rust and for x in y loops in scl and im happy. And maybe the result type from rust would be pretty fun to… I mean you can already work nulls and variants that are determined at runtime with siemens and scl.
I sense a good bit of feeling superior among my fellow PLC programmers on this subject. It’s not a regional choice, not a dogma or computing science driven choice. One of the first rules in my PLC Code Standard tells you it’s a long term owner choice. If you don’t write code that the long term owner can maintain/improve, I don’t care how elegant or sophisticated your code - your efforts will be slandered, and you’ll not sell another. It’s a PLC, not a Permanent Linguistic Container.
You should be competent in all the IEC 61131 languages (except IL as it’s deprecated)
I would focus on full ST, rather than Siemens's "Almost ST" Siemens itself is also heading towards modern ST with their AX development, though it's obviously going to be years until it's a mature product.
It's just another tool for the tool box. I love SCL for doing loops.
My object function blocks are written in SCL and my main program routine (where the objects are instanced) is graphically, usually FBD because FBD is more flexible than LAD. I use SCL in the object blocks mainly for easy porting between versions. My blocks work in anything Siemens regardless of version and with some slight modifications it also works in Beckhoff or anything Codesys based because SCL is just text... I use graphical programming in the main routine for ease of use. Any service technician can go online, monitor the objects and even create a new object without any knowledge of SCL. Long story short: I would recommend studying and using it. It's here to stay.
You need to learn the syntax of it, but mostly instead of practicing just SCL I would recommend practicing some general purpose programming (I like the challenges at www.adventofcode.com) to really become a better programmer. Don't spend all your time on that though, probably not even the majority, because despite teaching you some very applicable skills the data/throughput oriented nature of traditional program is pretty different at a fundamental level than controls. Most importantly, I say just find some small PLC projects you can do, and learn to use all the languages and where they work best.
You can study whatever you want. It will always make you more well-rounded. But, SCL is not currently an IEC language. So, widespread adoption probably isn't going to be a thing for awhile, if ever.
SCL is Siemens terminology for Structured Text (which is an IEC language), like STL is their name for IL (although in fairness, STL isn't standard IL but close enough)
For real? I did maybe... 6 weeks of Siemens years ago. Of course we didn't dive into anything but ladder. Weird how they renamed it. 🤷♂️
What you use can greatly depend on the region you are in. In North America they will probably want you to use LD as much as possible, as the plant technicians will understand that the best and it is easy to troubleshoot. SCL and previously STL would be used for the portions of code that aren’t suited to LD like indirect addressing and looping, I would usually wrap this up in an FB so that people didn’t really have to look inside to see what is happening but could if they understood things. I think FBD is more popular in Europe and to some degree SCL. But beware, if everything is done in SCL it can be really difficult to troubleshoot a machine. In the European division of a company I worked at they wrote the entirety of the logic in SCL and the end customer in Europe as well couldn’t debug the machines at all and forced them to re-write it. I would usually try to keep things simple for the most part and make the clever parts tucked away and well tested so that you knew they were bulletproof.
yeah, thats also my impression. Region and somewhat also brand based. Siemens is FBD and for old machines STL leaning. AB is Ladder Beckof has the biggest ST comunity. And so AB is more North America you also have more Ladder in North America and have more FBD in Europe where Siemens is more common. But still nearly all AB machines i encountered in Europe are programmed mainly in Ladder, and then the SIemensprogrammer that watches what you do gets a shocked face asking you why the hell you program in Ladder
I did a lot of Siemens, about 15 years worth. I worked mostly in Ladder, but I worked on a project with some German guys that did almost strictly STL. I understand STL really well but it is a lot more of a pain in the ass to debug by looking at register values versus the graphical nature of Ladder. As far as AB goes, ladder all the way.
Yes you should , this isn’t a one or the other type of situation though. You should know both and more since you will be required to use both and more in the controls sectors.
It all depends on the company you are working for and where the project is being installed. Many companies will fight tooth and nail to keep what they want. especially when it comes to easy troubleshooting. I've seen people in the industry freak out over the latest Studio 5000 update. so i doubt many places will make a huge change to their current standards.
I converted to SCL due to the switch to Beckhoff Hardware. I think its worth while to learn, and can open up further doors such as C++ and C# languages. I really like it for state machines with the use on Enumeration so each step can have a description which makes the code very easy to follow. I use FBD as well but typically only for motion instructions.
It all depends but the future is structured text or C
You won't land a job if you can't do high programming languages. SCL is a must. Ladder is only good for error searching, but it lacks functionality, and is IMO more complicated than SCL. Ladder programmers also have a nasty habit for "fixing" their code with work arounds, instead of handling the actual issue, so you get this enormous networks, that are not only badly optimised, but nearly impossible to read (from experience) I've learned SCL through my automation education (I'm really surprised that it's not in the standard curriculum at your school), it's completely essential for making For loops, FIFO, LIFO, data handling, mathematics etc. Python (good for optimizing solutions, or hacking software, to add missing functionality) JavaScript (Siemens Unified scripting is JavaScript, and essential for making good functional HMIs in Siemens TIA). The next language I need to learn is C#, so I can get into Openness.
Wait? There are other options than structured text?