What is the solution for the maintainer that has to troubleshoot the process (system) . Next time you purchase something that requires you to read the instructions, try reading the section in Chinese and see how far you get. It is bad enough some of the crappy instructions written in your first language but try on a language that is not your first language and on top of that try following the instructions that has an alphabet or characters that you have no idea what any of them signify. There is a logical continuity that resembles electrical continuity with ladder logic diagrams that you can follow without reading any text. If you haven't spent many hours on the factory floor than your opinion is that of someone having written a travel guide for a country that they have never even visited.
You are so true with all you say. My first control programs were created back in 1972 with Data General Assembler language. We were the first aluminum smelter plant in the world to be on computer control. The control was based on an office computer like the DEC made by Data General. It doesn't bet more basic than assembler language. You coded it, you loaded it, and prayed it worked. like you I used basic, foretran, and some 'c'. I really liked the ladder logic idea. it is easy to see and understand. I liked the AB because it would show what was happening at the time. I have created some overly complex PLC code, but it was still easy to follow once you learned. I agree with everything you say.
Can you see the logical state of the statements? Can you look at the code and see within seconds why the statement is false. Rockwell had animated variables in their structured text.
Regardless of anything else...the problem is the speed of troubleshooting...the rest is irrelevant. I am not against ST...just using it for sequential logic of machine control that maintenance folks will have to troubleshoot.
Great point...I reserve ST for equations. I have not used ST much lately. With the advent of Add On Instructions for "5000" years ago and more currently, User Defined Function Blocks for CCW, those equations and other calculations that would never need editing have disappeared into my toolbox of "instructions". There are many AOI and UDFB available on Rockwell's website...they are in the programming examples that you can download free.
@@k0ppit In the latest TiaPortal it is possible to show temp vars. The code in ‘test’ mode isn’t like it seems, but a little more. You can ran line/line effecting the plc in a combination of STOP/RUN at the same time. Very powerful !!! Don’t do it in production …. ;-)
I’m sorry but you can’t compare poorly written Structured Text with ladder logic. In ST you can assign an input to an output Digital_Out1 := Digital_In1; without the need for IF THEN ELSE. For the case statement code you could write: _IO_EM_DO_00 := (State = 1); _IO_EM_DO_01 := (State = 2); _IO_EM_DO_02 := (State = 3); _IO_EM_DO_03 := (State = 4); Most structured text IDEs will highlight the Boolean values and display variable values within the code. Each language has their pros and cons. I would definitely recommend Ladder for certain applications, but I prefer the power of Structured Text. Using ladder or Function Block programming as a wrapper framework to hold Structured Text functions where required is a good compromise in the limited cases when someone needs to view the code.
Indeed. ST debugging is sometimes hard to do. But once it gets compiled and running into the plc it is fast. I builded a program with +7400 lines once running at 3.5 ms. Siemens is not comparable with AB, but the ST can give nice solutions. I am not as familiar with AB instead of Siemens or others like Omron, B&R and many others. PLC is a strange world sometimes.
Yeah i am inclined to agree. This reminds me of stuff like visual basic. Sure, for some applications it makes sense, BUT, unless you're doing quite simple stuff, this would quickly get more confusing than pure code. That said, the ideal situation is to have both; and that is in a way what IDEs are trying to do; with color, stylizing, highlighting, peeking, linting, code lensing and so on.
Ladder logic is incredibly powerful when you're troubleshooting an issue on the plant floor. You can connect to a PLC and determine the current state of the process in a graphical representation that is familiar to every electrician. I don't know of any structured language that you can connect to and readily see the current state of every bit/var in a clear format that is readily available to the people that maintain and repair the equipment. Being able to view the code is not a limited case, but rather the daily need of the maintenance personnel.
@@srone so it’s considered quite a good tool to be able to read ladder logic diagrams ect? Is it true that a good portion of electricians don’t possess this knowledge?
There has to be a focus, a focal point. It cannot be broad at both ends nor narrow at both ends. There has to be a focus on one end or the other, the code writer or the maintainer.
The only point of this video was that in consideration of "good parts out the door", the systems have to be easily maintained by those WHO DO NOT WRITE CODE for a living. Our own personal opinions on writing code are relevant only to us. The "maintainers" have a much more difficult task than those who write the code themselves. As long as we can get a sign off from the enterprise, we can walk away and if we do get called back, the code is never that cold to us after a little reacquaintance time. However, the individual that has to be able to sort out dozens of programming styles has a real challenge on their hands and that is reading stories that we have written with minimum effort because it is the easiest and fastest way to get that signoff. They almost have to be greater experts than us.
After using ladder for most of my career, I found IEC61131-3, specifically SFCs and CFCs. Trouble shooting SFCs and (properly commented) CFCs is even quicker than ladder. We had a young hotshot engineer who, after no small effort, convinced me to try IEC61131-3. After a big successful project where public safety was more of an issue than I had previously encountered (6000 psig 180k ppm H2S gas near a small city) I didn't have any trouble swallowing my pride and buying that kid dinner and thanking him. Best job-related advice I ever got.
The example is written in poor ST style, it can be written more simply as an assignment statement. ST strength will be seen in more complex tasks, not simple on off controls. For example, operations on tables, indirect addressing or even just calculating the moving average - LD looks completely unreadable.
@@plcprofessorNo, professor, the guy has the point. What you are talking about is only relevant when the Logic is trivial, primitive. When the Logic includes complex calculations there's no point in following your rules, it would only overcomplicate things.
@@plcprofessor I will write complex logic in ST and seal it in a giant FB so that factory guys can troubleshoot. By the way, timers and counters in LD are not written in ST. LD fans should demand PLC manufacturers to convert timers and counters in LD so that technicians can troubleshoot.
I walked into this video looking for direction on how to make my own plc for a greenhouse as a fun tech project gone too far. But by the end you have shown me not only why my previous job has a lot of issue learning their plc but why they have so many issues finding anyone other than the German based manufacturer to troubleshoot it. I remember seeing code flying down the hand held controller and my boss spending lots of money, time and effort every time a sensor went out of wack or a cylinder blew.. I can't tell you how many hours I spent learning how that thing worked with the production line.. how many hours per year lost to red lights or amber lights that wouldn't go away. How many hard restarts that poor thing went through. Now that I've watched this I am going to learn this the right way so I can rake in a little of that corporate coin they are throwing around.. maybe it will make up for the blood I didn't intend to give to the workplace 😬
Some micro-sized PLCs are under 200 USD& there are different OPen-Source PLCs that in theory run on PIs or RISC boards. Browse the net to see what may fi your projects.
A well written PLC program will raise faults for ALL conditions. As a (PLC) programmer, that is what you should strive for. Iit is not good practice to expect somebody to open the code and check what is going wrong. Whatever the language you pick, your design strategy and implementation is the key. The number of faults a system can raise base on the number of IO points and complexity is revealing. One of many good advice: do not implement silent interlock. Thats a killer. This is one of many reason why another person has to open the code. Another classic one is a sequence logic launching an action without any fault timeout.
Totally disagree! LD is good when machine is simple. However, modern machines are so complicated making LD unsuitable for the job. The reason technicians can't troubleshoot ST is because they are not trained to read ST. I worked with many European and Chinese technicians. They all understand ST and are good at it too. Hence, nowadays there are many tools and IDEs that make troubleshooting code easier. In addition, to improve code quality we can implement unit test, regression test, automated test with ST. For example, after code change, I can let the computer run tests overnight and see how many of them failed. Can LD do that? Also, I can track my changes using source control instead of change the project name to V1.1 V1.2 V1.3... My team members can develop other features without affecting my work and we can merge our code once they are completed. How can I achieve that with LD?
When this discussion takes place regarding the ST/Laddar two important aspects are neglected. Structure and testing. 1) Far too many try to brute-force code without any real proper code architecture. With the right structure and educated staff, troubleshooting ST should not be a major problem. 2) The second thing correlates with the structure - testing. Why do technicians have to enter the code to failsearch something in the machine? it's understandable if hardware breaks down and automated assignment for new hardware has not been set up. But in general, this is obsolete thinking. You have the tools today to do the bench-testing without proper hardware in the office to test the code. Furthermore, a proper FAT/SAT according to GAMP5 or similar will eliminate more or less all software bugs ... Over the years of working as an automation architect for an OEM in the med-tech industry delivering machines around the world, I have in a decade not experienced a single customer complaining of the Structure Text within our machines. I also never had to do any panic support due to a technician couldn't work with the developed software. It's been many years ago since I worked with CCW. But judging from your video I would never choose to work with ST in that editor. It looks very similar to Siemens S7 SCL back in the mid '90s. Modern tools today such as Siemens SCL editor and Codesys (Which enables you to actually go full out with the OOP extension) are much better options.
Most companies go with the lowest bidder and that does not usually include diagnostic code or screen messages. AOIs have narrowed that cost difference significantly.
I feel your pain. It troubles me to see the modern PC programming is turning into that Angular / node.js style and i miss the old C++ or Turbo Pascal style of building applications. But ladder logic is not easier to debug. With the PLC program being more complicated than just handling a garage door ladder logic falls of quickly. Siemens have ways to monitor variables in SCL and in STL can monitor variables (accumulator) but also RLO so you know exactly what`s the result of logic operation and when it changes to 1 or 0. Just using ladder logic doesn`t guarantee that the code will be easy to read and troubleshoot. In many cases the ability to read is how functions/routines are called. Is the function called from one place or multiple places (like one call from OB1 and another from OB34). Or the values in one function can they be modified from outside? Which functions modify them and when are they called? How do you design loops? How do you use pointers?
Most of these arguments about languages are due to differences in PLC platforms, industries and a person's experience. All languages have their place, but the US and Allen-Bradley have emphasized ladder since the beginning. Siemens programmers learn STL first, and don't understand why Americans use ladder. Young programmers with CS degrees often don't understand basic electricity, so ladder doesn't make sense to them. They like what they are used to, which is high-level structured programming. AB has a great ladder editor, and ST costs extra. Logix500 doesn't even have ST. If you are programming Beckhoff, the ladder editor and instruction set are not great, so it won't be your first choice. I teach all of these platforms and have also built large systems with all, and the approach is different for all.
In Europe, the chefs demand that the employees whistle while they work to ensure that they are not eating the food, in the US, the chefs want the employees to sample the food as part of the quality control process. Regimented structure against shared authority. In Germany, unless you are upper class, you go to the school that they assign to you or you go without. I would not hold anything in the EU up as an example except their train systems. The US let politicians destroy them.
In general terms its true. But if You look at other PLC brands then many of them have tools for debugging structured text almost easily as ladder. I can name ABB, B&R as example. And in my opinion complicated part's of program is more readable in ST. I can't imagine writing some communication protocols (for communicating instruments) in ladder.
I'm thinking maintenance person at 3am should not be undertrained in the first place. If so, its a problem of a customer. And second of all, the undertrained guy will no way wrap his head around what happens in some communication protocol program that you wrote in Ladder, anyway. Period
@@7Denial7 Facts. If someone has to debug the machine code to figure out the problem, the source of the problem lies else where. Every single fault should be alarmed. You always also have an IO display for all the actuators etc, fault should not be hard to find on the HMI. If it were up to me, I would not let the customer have access to the PLC, its just a fault waiting to happen.
I agree. Funny think is we had made program using ladder, but the customer told us that it was old fashion. They wanted us to use FBD or ST. In my experience a lot of Logic in FBD gets out of hand fast.
Less downtime then you need a really good test suite. I come from the Wind turbine and generator Industry. Down time is absolute a no go. The test suite call unittest - integration test and lastly system test is so importen. Many dose not do that which is baffling me alot. Test driven development saves time on site and it is alot cheaper to correct fault at the office compare to the customer site.
I was just 10 years old when I had my first interaction with automation. It was with BASIC on 8bit PC in 1984. Actually, it was my mother's second husband to explained how to connect all the el. appliances at home to the computer and control them. When I started the PLC course I was somehow disappointed in the ladder logic as was already programming Arduino on C++ which is much easier. But a couple of weeks later I understood that is much more important to understand the ladder logic especially the relay logic which actually is based on Boolean algebra. In my opinion, if you don't know what are logic gates and binary system there's no point in losing your time trying to be a professional PLC programmer.
When I designed plc programs, I always thought of the maintenance guys who would be troubleshooting the system and designed the program to be easily understood. I also insisted for others to do the same but, sadly, not everyone has the same mindset. (".)
good modern PLC programs have many data HMI messages to indicate most of the reasons why the machine is not working. Laptop PLC troubleshooting is due to not having enough downtime information such as sensor status and where it is located on the machine . 😎 Thanks for the great information.
Most companies go with the lowest bidder and that does not usually include diagnostic code or screen messages. AOIs have narrowed that cost difference significantly.
I don't disagree with the sentiment however 30000 lines of code can be searched. Also I see all my variables online with the values. Extremely complex ladder logic can be just as inscrutible as code. All that said. your point was solid, parts out the door.
I still Subbed, so it's not all bad ;) Oh and I worked a completely unseen before 20+ yr old project with +30k lines of ST just two days ago and added a new change request in a few hours (Most of which was finding where to code, and checking it didn't explode anything). Whilst this is not the most amazing turnaround it still beats out trying to fight through thousands of diagrams. IMHO.
Not every process is assembly. How does good parts out the door relate to a water treatment facility? I think his point is that PLC's were created largely to help get more products out the door, by being more user/technician/manager friendly, not so that programmers could sit around doing nothing but dicking around endlessly "creating" AOI's. Valid point, but needs to be stated more clearly
bottom line...structured text is the most time consuming code to write and troubleshoot, machine control or process control but is good for algorithms that never need to pass through for troubleshooting purposes. AOIs can be just as bad if not thought out for the kids on the shop floor.
Oh boy... If you wouldn't have made that gatekeeping statement, that people like me shouldn't be in the industry, I would be nicer but here we are... My basic opinion is, that if you can't understand ALL IEC languages, you are not suited for your job. In my experience, those guys that say ST is hard to understand, name their variables "xKrBlkip" (global variable of corse!) and don't see anything wrong with it. If you do anything else than binary logic and start using datatypes (like a civilized person), loops, external function calls, LAD just becomes aweful. For simple things, LAD is totaly fine, but if you have a more complex machine, this is defenetly a poor choice. I think the prejudice from a lot of people that don't like ST, is because they don't know how to use it propperly and write well structured readable code. If you see bad ST code, and think "ST is a bad language" instead of "This is badly written code (let me fix this)", than it's a you problem. 7:25 - What is this formatting? Why is "i" declared at the top, and initialized infront of the while loop? Why a while loop instead of a for loop? This could be done more readable in half the loc. 11:15 - What is this formattig again? Just do an assignment! Rediculous example! 16:30 - Gues what? Formatting! Numbers should be replaced by meaningful constants. I don't see anything wrong with this. I know EXACTLY what happenes in each state, with no cross-interaction. If you don't want to set everything FALSE in every step, just set them all FALSE before the case and set only the things TRUE that you want in each state. Or just do "VARIABLE := State = 1;". I'd prefere statemachines anyday. Statemachines should always have a safety else case! WHY IST THE 0 CASE IN THE MIDDLE??? 18:15 - It checks ALL the conditions on every cycle (slow) and is extremly inefficient. This is not the same as CASE! Ontop of that, if you set state in an upper rung, you execute that step (and maybe more states after that) in the same plc-cycle. This is your ticket to an undebuggable statemachine! NEVER do this! 24:00 - Like others pointed out: This is an IDE issue, not ST. I give you that LAD is in this example a little more convinient, but defenetly not something that should bother a professional in any way. 29:08 - I kind of agree here, but if you don't understand ST too, you should be connecting wires, instead of "programming". As someone who knows all IEC languages, I will become rich as hell in the future, if you are right. 29:50 - This is "complex"? This is asignments and IF statements. 30:45 - This is "spagetti code" for you? Two nested IF statments are spagetti code that you can't follow? Sounds like a you problem. I mean, its shitty code and you could write this a lot better, but who cares? just blame the language! 31:20 - If you have to go to step 700... you go to step 700... where is the issue? would have LAD fixed the scrolling? And calling this a "Jump to Label" tells me you don't get this. 31:50 - Yeah, it's not the best ST-Code ever (formatting is realy hard for PLC devs it seems), but I get what happens. Most of the code at the bottom handlse HMI visibility stuff. Having HMI logic on the PLC is one of the worst sins you can do. 32:09 - No one could debug this? I could! You took "one look at this" and decided to rewrite it in LAD??? Rediculous! I'm sorry, but you need to hear this: Don't blame others for writing ST, because you can't read it! Shitty code, is shitty code, a language can't fix bad programming.
You are saying that the maintenance staff has no business troubleshooting industrial control systems if they cannot efficiently analyze structured text. Tell that to the HR department and see how far you get. Arduino bunnies couldn't get in out of the rain if they had to work on the factory floor. It is not about you...never.
@@plcprofessor What I am saying is, that if they can't read ST, they have to learn it. It's part of the IEC Standard and should be expected of someone that wants to do this job. If HR only employs and caters towards bozos, I will talk with them about my resignation. I started off at the factory floor and did that job for years. I have seen a lot of stuff and the issues are caused by bad engineers, not the language.
I appreciate the notion that at the forefront of every process is getting the most product produced and to the customer in the least amount of time as possible. Most times, but not always, that means using some well thought out structure or language in coding that facilitates quickly interpreting the code and what’s happening. However, with that said, it seems you’re making a lot of assumptions in your efforts to “sell” ladder diagram for PLC programming. So, with all respect, allow me to play devil's advocate 😎 *Assumption 1 - All “Joe Snuffy” maintenance personnel only understand electrical circuit diagrams, therefore all code should be written like a circuit diagram (ladder).* I've worked with some very talented electricians that actually were pretty good at text languages. A few of them played with Arduinos and other hobby like text programming outside of their jobs. So when it came time to go online with the PLC that had structured text code in it, it was not much of a problem for them to go through it and troubleshoot it just as easy as if they were troubleshooting a LD program. *Assumption 2 - It will always only be “Joe Snuffy” maintenance personnel troubleshooting PLC code at every company.* I once worked at a facility where the only people that went online with a PLC to troubleshoot things were the controls/automation engineers. Those engineers were expected to understand the code inside and out, regardless of what language it was. That means going online with the process and studying the code and the machine so that you know it well. In my opinion, that’s the way it should be at every facility. If the company is expecting maintenance people to troubleshoot PLC programs, then those people should know, understand and be able to interpret *all* PLC languages (IEC-61131) well. Otherwise, get someone else with a better suited skillset to troubleshoot the PLC programs. In regards to that, it doesn't *always* need to be maintenance and electricians only. In fact, it doesn't need to be them at all. Companies should get out of that paradigm mind set that its maintenance and electricians that troubleshoot PLCs. I know its become a bit of a norm, but companies are making their maintenance personnel do a job that they are not trained or experts in. So then in many cases, we're dumbing down the program or not utilizing the full capabilities of the PLC technology and advantages of certain PLC languages simply because "Joe Snuffy" might take longer to interpret it if its not what he/she knows (LD). *Assumption 3 - Ladder diagram will always be easier to interpret than text code, for every task.* Take a very common task of iterating through an array of integers and finding the element within that has the highest value. It's going to be much easier to both write and interpret that in ST than in LD, especially if your PLC platform doesn't have a ready-made For Loop instruction. In ST, it would be a simple and very common For-Next loop. That's just one example of many. *Assumption 4 - Everyone will interpret ladder diagram faster and easier than they interpret text code.* I once worked with a particular gentleman that could write and interpret text code like it was nobody’s business, but had a heck of a time understanding and interpreting LD, something that supposedly is supposed to be easy for everyone. Moreover, I've often times been around persons with text programming background that just couldn't grasp the "normally open" and "normally closed" concept. *Assumption 5 - All PLCs brands that use text code, will not show the value of a variable in that text code when you’re online with the PLC. You will only be able to see the online value in a ladder editor.* Perhaps that's how it is in RSLogix world, but that is not the case at all in some others, particularly anything that uses Codesys or Codesys under the hood (Beckhoff). With those, you can be online with the PLC and see the real time values of the variables inside the structed text editor just the same as you can in the ladder editor. No difference. Something else I feel needs to be mentioned in regards to graphical languages (LD, FBD, SFC) versus text languages (ST, IL). Graphical languages take longer for the processor to process versus text languages. This means you'll have a longer scan time requirement for LD than if the same routine was written in ST, especially for larger programs. Scan times matter! A simple difference of 10ms scan time versus 2ms scan time could be the difference of 100 widgets per hour at 10ms scan time versus 101 widgets per hour at 2ms scan time. For a typical 24/7 operation, that's a difference of ~8760 widgets per year!!! So, it's not just the downtime that can directly be seen that is costing the company money. It's also the "downtime" that cannot be directly seen that is costing the company money too. The way I like to do it and from my experience works well, is to have a Faults routine and write it in LD or FBD. In most cases, the rungs will be simple and easy to interpret. For the rest of the process/machine, feel free to use whatever language is best suited for the task.
I am not selling anything. I am making a lot of money cleaning up processes written in structured text that their technicians/electricians can't troubleshoot and most of it is spaghetti code. You cannot monitor the logical continuity in any of those platforms that you mentioned...What good are the tag values if they are not present in an active dynamic context?
@@plcprofessor You're trying hard to make an argument for LD, and making a lot of assumptions in the process. That was my point in my post. I've seen it before. If LD is the way we all should be doing it, then why is there even other PLC languages in IEC-61131? Furthermore, why is the predominant PLC language used in the EU, Structured Text??? "that their technicians/electricians can't troubleshoot". That is NOT a PLC language problem! That is the person/s that wrote the code problem. Spaghetti code can be done in any language, not just ST. That is also, perhaps and very likely, the technicians/electricians that can't comprehend text languages. In that case, that's a company problem that's hiring the wrong persons for the job. Again, as I implied in my original post - Stop hiring electricians to be programmers!! If these persons are going to be the ones troubleshooting PLC programs, then they should be expected to be able to comprehend all PLC languages that could be present in a PLC at any given time. That means the company needs to get them up to speed, and if those persons don't get there, then the company needs to get someone that can/will get there. But the PLC language used should not be "dumbed down" for anyone. We use the best language for the task, period! There needs to be a paradigm shift in thinking that "only electricians work on PLC's and that's who we hire for these jobs". Hire programmers to be programmers. Hire electricians to be electricians. But that makes too much logical sense.
@@plcprofessoryou professor completely ignore the good points people point out. Too stubborn to admit that they are right in some point and you are wrong
Based on the cover picture's bright light, I have to ask how many KW hours do you "burn" each month. Doing Systems Analysis for energy. Currently, working on vertical Wind-Turbines within MicroGrid nodes. Been doing A.I. since 1988 (U.S.). What's all the excitement all about? ChatGPT isn't greatly new. Relax and learn about it. Expect many generations ahead inside PLCs.
Good evening, May i ask for a clarification, did your first statements mean the "highest quality (reliability)" in parts, or "Variety of available boards" or the logger/debugging facility, or a combination ? I was not sure . By the way the ST with goto is really not good practice with high level languages, if ST doesn't support high level constructs such as function calls, i can understand how complex code very quickly becomes hard to follow. Thanks, Jean-François
@@plcprofessoryou lost yourself. Arrogant. I read through what you replied to people, and you completely ignore their points, acting like you some kind of superior PLC guru. Let me tell you, you're not. Being older doesn't mean you are any good
This example is really bad. You are saying that because your IDE of choice does not provide good ST debugging experience, ladder is better. I use both, I prefer ST, ladder is fine, but when it gets to big projects and a bit longer networks, debugging ladder is god awful, since I don't have a cinema theatre to display enough networks without scrolling for 3 days to find what i am looking for. They both have pros and cons, your example is just poor, sorry to say.
You are right. With all the new gadgets and technology, we've collectively lost our way since the late 70's. All this tech should make the machine totally able to tell you totally whatever is wrong with it. All assuming that the electrical and process design captured enough information to do so.
I understand and generally agree with your take home message, but I don't think you are doing a great job with the examples and (for me anyway) it detracts from your point. They are somewhat contrived and it looks like you are setting up a straw man for ST. Example 1 code could have been this; _IO_EM_DO_09 := _IO_EM_DI_01; _IO_EM_DO_08 := _IO_EM_DI_00; .... not whatever the hell you had. In my opinion state example 1 shows why ST is good. I would prefer to read that in ST to understand its function. In state example 2 I believe ST would be more equivalent with something like; _IO_EM_DO_00 := (State = 1); _IO_EM_DO_01 := (State = 2); _IO_EM_DO_02 := (State = 3); _IO_EM_DO_03 := (State = 4); much more concise in my opinion. I get and understand your point regarding monitoring. 100% agree with you for CCW, but I don't think you are really comparing apples to apples when it comes to the industry as a whole. Rockwell is known for being horrible for structured text. I could show you some IDE's which make ladder equally as abhorrent that have really nice ST editors. We also didn't touch on loops or other more advanced algorithms. At the end of the day, use the right tool for the job. Good job, keep the videos coming.
also you are being unfair to your structured text. You use very verbose statement with if and else and in the ladder you just assign. so if you just assign OutputX := Input Y, it is more readable and would be the same logic as a normal coil ... (well ok, the other way around, the output comes first because it is the assigned variable) ... of course you need a st editor that can show state and maybe even color code ... so I agree with the visual trouble shooting and state aspect ... you will see that any visual programming language will be popular with some audiences, but once it get's more complicated, often structured text is more powerful and often actually more readable ... if you look at complex node red diagrams, you will easily get lost ... there is a lot of low code programming hype, which I understand and it certainly has it's benefit ... and if you look at it, PLC ladder logic was actually a very early low code programming language for non-programmers (electrical engineers extending their working field) ... the same is true with todays "marketing programmers" or "analyst programmers" that use similar visual programming to solve problems in their domain without being a full code developer
Wrong. Simple as that. Monitor...the device...what your wrong on is how the device is monitored. The device can me monitored, logged, and trended easily in HMI code and (importantly) arranged logically as to function which may or may not be how/where it was written.
Let me guess, you were an industrial electrician or engineer who started working on plc's in a manufacturing factory....and has absolutely no experience doing anything else? How ever I do agree with all of this.
Yes that is true an engineer who started writing fortran and basic for non industrial applications and has thousands of hours on the factory floor working with electricians and technicians and listening to management whine about the downtime and how much it is costing the enterprise that pays our salaries. When you throw a rock into a pack of dogs, the one that yelps is the one that you hit...
@@plcprofessorI can tell, you believe this fallacy where companies are hiring and training plc programmers. That's not how anything works. Your entire generation had the same basic experience you did. They learned step by step as technology progressed working at the same place for 40 years. Today companies are trying to hire direct replacements of you. They are looking for guy who has experience with fortran, and slq500, and some obsolete fanuc robot, and some super specific machine tools they have. Those people don't exist, the only reason you do is because you grew with the technology and the company. Thats why there are no programmers available. And if a company does stumble across a guy that has plc experience, they don't want to pay him more than the dope that changes light bulbs. The old managers are all retiring, and they are being replaced by some moron with a receipt saying they wasted 4 years at an indoctrination center. Those goofballs have absolutely no idea what ladder logic is or why what you said in this video is correct and relevant.
I am self-employed and have a range of processes and equipment worked with that is extensive. I have never worked in one place more that 4 years, how about you? What is your background?@@EitriBrokkr
The goal isn't just products it's also about safety? Sorry how could you miss such a critical aspect of PLCs? Sorry as you said in your preamble maybe I don't belong in the industry if I don't take safety as seriously as production?
These days, regular PLCs and Standard portion of Safety PLC, should never been used for safety. When machine maker or any other integrator leaves the floor, safety logic in Safety PLC and Safety wiring must be checked and verified ahead of time. In case of safety PLC, the Safety part of it must be locked and being Password protected.
Jumped in without hearing the full of it, did you? Safety has nothing to do with programming languages, safety is 95% hardwired. The CR30, which is what I use, has a very simple graphic programming language.
Your whole point around ST being worse than LD is demonstrated on like the simplest hello-world a PLC can do. Your standpoint is like from 30 years ago, things have changed alot! Also you picked a manufacturer which is not capable of live debugging ST, which is not ST's fault. I can see the variable value live and can change it by a single click or force it with 2 clicks on a beckhoff system. Even your big statemachine in the main POU does almost nothing other than setting some booleans. how would you even begin to iterate over some 1000 structurized member array ? - oh wait you guys would copy paste the same logic a thousand times. Have you even mentioned breakpoints ? Or is your plc also incapable of that? With no word you mentioned the extended IEC-61131 object-oriented ST, which to me is another sign that even if you did program BASIC or FORTRAN years ago, you don't actually really get how modern PLC is/could be programmed, or do you know what an Interface-POU is and why it is used? The only point you have is that electricians won't be capable of debugging ST code, which is kinda true. But then again, try to program a modern big machine on like LD, it is gonnna be a nightmare and you cost way more than any electrician trying to fix ST logic. And if ST delivers faster, most companies will take ST-coded machines.
The suggestion to do not learn Structured Text as the primary programming language when approaching PLC (or any other 61131-3 based Control System) is a very bad career advice.
Hi @@plcprofessor, thanks for replying. In the introduction it is emphasized the idea that, in order to get good code, it should be easy to troubleshoot the code itself by monitoring online the PLC variables. After that, there is a comparison of the benefits of a graphical language vs. textual languages, with a few examples to show that the graphical approach provides a better way to troubleshoot the code. Finally, it's written in the notes that this information is given to programmers for the sake of their careers. So, what I understand by watching this video is that if I want to get good code, then I should expect to monitor my variables online and therefore it's a good career advice for me to use graphical languages since they're more suitable for online monitoring. This may be an acceptable approach in very specific projects or when using some PLC platforms with limited features, but it is certainly not a good career advice.
I 100% agree with you, if someone is really good at language like ST and wants to program every machine in ST, they better find a job in the tech company, and they will get paid a lot more.
This is so wrong... so much bias... you can write excellent, highly readable and very well observable programs in structured text. If you need to read actual PLC program to understand what's wrong with your machine, then you solution is simply an unfinished job... HMI should give you enough information to troubleshoot the machine. The comparative examples are ludicrous, you don't write ST programs with LD mindset. On the topic 'picture worth of a thousands words' it is true in a very narrow sense. If I switch off the audio of this video... what would I understand? For understranding we need language (words) that is very a well established fact in cognitive sciences.
Have you worked on these machines yourself or worked with the people who do? The electricians and maintenance workers who repair them are much more familiar with electrical schematics. LD is much more intuitive to them because it mimics that. There is a place for ST, but that place is for things you wouldn't expect maintenance workers to be dealing with anyways such as communications protocols, analog signal filters, etc. Things you want to keep in the blackbox.
When you throw a rock into a pack of dogs, the one that yelps is the one that you hit. I learned that your opening statements must be provocative. I love the results.
Most companies go with the lowest bidder and that does not usually include diagnostic code or screen messages. AOIs have narrowed that cost difference significantly.
What is the solution for the maintainer that has to troubleshoot the process (system) . Next time you purchase something that requires you to read the instructions, try reading the section in Chinese and see how far you get. It is bad enough some of the crappy instructions written in your first language but try on a language that is not your first language and on top of that try following the instructions that has an alphabet or characters that you have no idea what any of them signify. There is a logical continuity that resembles electrical continuity with ladder logic diagrams that you can follow without reading any text. If you haven't spent many hours on the factory floor than your opinion is that of someone having written a travel guide for a country that they have never even visited.
You are so true with all you say. My first control programs were created back in 1972 with Data General Assembler language. We were the first aluminum smelter plant in the world to be on computer control. The control was based on an office computer like the DEC made by Data General. It doesn't bet more basic than assembler language. You coded it, you loaded it, and prayed it worked. like you I used basic, foretran, and some 'c'. I really liked the ladder logic idea. it is easy to see and understand. I liked the AB because it would show what was happening at the time. I have created some overly complex PLC code, but it was still easy to follow once you learned. I agree with everything you say.
It is allen Bradley problem.. in codesys you can see logical state of all variables in online mode in ST. In siemens too. :)
Can you see the logical state of the statements? Can you look at the code and see within seconds why the statement is false. Rockwell had animated variables in their structured text.
Regardless of anything else...the problem is the speed of troubleshooting...the rest is irrelevant. I am not against ST...just using it for sequential logic of machine control that maintenance folks will have to troubleshoot.
In newer version Logix designer you can get your values next to your variables. Siemens won’t show you temp variables values.
Great point...I reserve ST for equations. I have not used ST much lately. With the advent of Add On Instructions for "5000" years ago and more currently, User Defined Function Blocks for CCW, those equations and other calculations that would never need editing have disappeared into my toolbox of "instructions". There are many AOI and UDFB available on Rockwell's website...they are in the programming examples that you can download free.
@@k0ppit In the latest TiaPortal it is possible to show temp vars. The code in ‘test’ mode isn’t like it seems, but a little more. You can ran line/line effecting the plc in a combination of STOP/RUN at the same time. Very powerful !!! Don’t do it in production …. ;-)
I’m sorry but you can’t compare poorly written Structured Text with ladder logic.
In ST you can assign an input to an output Digital_Out1 := Digital_In1; without the need for IF THEN ELSE.
For the case statement code you could write:
_IO_EM_DO_00 := (State = 1);
_IO_EM_DO_01 := (State = 2);
_IO_EM_DO_02 := (State = 3);
_IO_EM_DO_03 := (State = 4);
Most structured text IDEs will highlight the Boolean values and display variable values within the code.
Each language has their pros and cons. I would definitely recommend Ladder for certain applications, but I prefer the power of Structured Text. Using ladder or Function Block programming as a wrapper framework to hold Structured Text functions where required is a good compromise in the limited cases when someone needs to view the code.
Indeed. ST debugging is sometimes hard to do. But once it gets compiled and running into the plc it is fast. I builded a program with +7400 lines once running at 3.5 ms. Siemens is not comparable with AB, but the ST can give nice solutions. I am not as familiar with AB instead of Siemens or others like Omron, B&R and many others. PLC is a strange world sometimes.
Yeah i am inclined to agree. This reminds me of stuff like visual basic.
Sure, for some applications it makes sense, BUT, unless you're doing quite simple stuff, this would quickly get more confusing than pure code.
That said, the ideal situation is to have both; and that is in a way what IDEs are trying to do; with color, stylizing, highlighting, peeking, linting, code lensing and so on.
Ladder logic is incredibly powerful when you're troubleshooting an issue on the plant floor. You can connect to a PLC and determine the current state of the process in a graphical representation that is familiar to every electrician. I don't know of any structured language that you can connect to and readily see the current state of every bit/var in a clear format that is readily available to the people that maintain and repair the equipment. Being able to view the code is not a limited case, but rather the daily need of the maintenance personnel.
Structured text is power
@@srone so it’s considered quite a good tool to be able to read ladder logic diagrams ect? Is it true that a good portion of electricians don’t possess this knowledge?
There has to be a focus, a focal point. It cannot be broad at both ends nor narrow at both ends. There has to be a focus on one end or the other, the code writer or the maintainer.
The only point of this video was that in consideration of "good parts out the door", the systems have to be easily maintained by those WHO DO NOT WRITE CODE for a living. Our own personal opinions on writing code are relevant only to us. The "maintainers" have a much more difficult task than those who write the code themselves. As long as we can get a sign off from the enterprise, we can walk away and if we do get called back, the code is never that cold to us after a little reacquaintance time. However, the individual that has to be able to sort out dozens of programming styles has a real challenge on their hands and that is reading stories that we have written with minimum effort because it is the easiest and fastest way to get that signoff. They almost have to be greater experts than us.
After using ladder for most of my career, I found IEC61131-3, specifically SFCs and CFCs. Trouble shooting SFCs and (properly commented) CFCs is even quicker than ladder. We had a young hotshot engineer who, after no small effort, convinced me to try IEC61131-3. After a big successful project where public safety was more of an issue than I had previously encountered (6000 psig 180k ppm H2S gas near a small city) I didn't have any trouble swallowing my pride and buying that kid dinner and thanking him. Best job-related advice I ever got.
My point was towards easy to troubleshoot for anyone who shows up at 2:30am when the line is down...not to those of us that write code.
The example is written in poor ST style, it can be written more simply as an assignment statement. ST strength will be seen in more complex tasks, not simple on off controls. For example, operations on tables, indirect addressing or even just calculating the moving average - LD looks completely unreadable.
You missed the whole point. Good luck on the factory floor...
@@plcprofessorNo, professor, the guy has the point. What you are talking about is only relevant when the Logic is trivial, primitive. When the Logic includes complex calculations there's no point in following your rules, it would only overcomplicate things.
@@plcprofessor I will write complex logic in ST and seal it in a giant FB so that factory guys can troubleshoot. By the way, timers and counters in LD are not written in ST. LD fans should demand PLC manufacturers to convert timers and counters in LD so that technicians can troubleshoot.
I walked into this video looking for direction on how to make my own plc for a greenhouse as a fun tech project gone too far. But by the end you have shown me not only why my previous job has a lot of issue learning their plc but why they have so many issues finding anyone other than the German based manufacturer to troubleshoot it. I remember seeing code flying down the hand held controller and my boss spending lots of money, time and effort every time a sensor went out of wack or a cylinder blew.. I can't tell you how many hours I spent learning how that thing worked with the production line.. how many hours per year lost to red lights or amber lights that wouldn't go away. How many hard restarts that poor thing went through.
Now that I've watched this I am going to learn this the right way so I can rake in a little of that corporate coin they are throwing around.. maybe it will make up for the blood I didn't intend to give to the workplace 😬
Some micro-sized PLCs are under 200 USD& there are different OPen-Source PLCs that in theory run on PIs or RISC boards. Browse the net to see what may fi your projects.
A well written PLC program will raise faults for ALL conditions. As a (PLC) programmer, that is what you should strive for. Iit is not good practice to expect somebody to open the code and check what is going wrong. Whatever the language you pick, your design strategy and implementation is the key. The number of faults a system can raise base on the number of IO points and complexity is revealing. One of many good advice: do not implement silent interlock. Thats a killer. This is one of many reason why another person has to open the code. Another classic one is a sequence logic launching an action without any fault timeout.
Way to tell it like it is Professor Tim! Years in the trenches have taught you (and the rest of us) well! I'm honored to have worked with you.
For me, structure text or ladder logic, they both need to be readable. That is the key. I’ve worked with unwieldy examples of both.
Totally disagree! LD is good when machine is simple. However, modern machines are so complicated making LD unsuitable for the job.
The reason technicians can't troubleshoot ST is because they are not trained to read ST. I worked with many European and Chinese technicians. They all understand ST and are good at it too. Hence, nowadays there are many tools and IDEs that make troubleshooting code easier.
In addition, to improve code quality we can implement unit test, regression test, automated test with ST. For example, after code change, I can let the computer run tests overnight and see how many of them failed. Can LD do that?
Also, I can track my changes using source control instead of change the project name to V1.1 V1.2 V1.3... My team members can develop other features without affecting my work and we can merge our code once they are completed. How can I achieve that with LD?
When this discussion takes place regarding the ST/Laddar two important aspects are neglected. Structure and testing.
1) Far too many try to brute-force code without any real proper code architecture. With the right structure and educated staff, troubleshooting ST should not be a major problem.
2) The second thing correlates with the structure - testing. Why do technicians have to enter the code to failsearch something in the machine? it's understandable if hardware breaks down and automated assignment for new hardware has not been set up. But in general, this is obsolete thinking. You have the tools today to do the bench-testing without proper hardware in the office to test the code. Furthermore, a proper FAT/SAT according to GAMP5 or similar will eliminate more or less all software bugs ...
Over the years of working as an automation architect for an OEM in the med-tech industry delivering machines around the world, I have in a decade not experienced a single customer complaining of the Structure Text within our machines. I also never had to do any panic support due to a technician couldn't work with the developed software.
It's been many years ago since I worked with CCW. But judging from your video I would never choose to work with ST in that editor. It looks very similar to Siemens S7 SCL back in the mid '90s. Modern tools today such as Siemens SCL editor and Codesys (Which enables you to actually go full out with the OOP extension) are much better options.
Most companies go with the lowest bidder and that does not usually include diagnostic code or screen messages. AOIs have narrowed that cost difference significantly.
Fully agree. Thanks for slapping that into me, I was getting distracted.
Great information…Thanks a million !!!
my pleasure
I feel your pain. It troubles me to see the modern PC programming is turning into that Angular / node.js style and i miss the old C++ or Turbo Pascal style of building applications.
But ladder logic is not easier to debug. With the PLC program being more complicated than just handling a garage door ladder logic falls of quickly. Siemens have ways to monitor variables in SCL and in STL can monitor variables (accumulator) but also RLO so you know exactly what`s the result of logic operation and when it changes to 1 or 0. Just using ladder logic doesn`t guarantee that the code will be easy to read and troubleshoot. In many cases the ability to read is how functions/routines are called. Is the function called from one place or multiple places (like one call from OB1 and another from OB34). Or the values in one function can they be modified from outside? Which functions modify them and when are they called? How do you design loops? How do you use pointers?
Most of these arguments about languages are due to differences in PLC platforms, industries and a person's experience. All languages have their place, but the US and Allen-Bradley have emphasized ladder since the beginning. Siemens programmers learn STL first, and don't understand why Americans use ladder. Young programmers with CS degrees often don't understand basic electricity, so ladder doesn't make sense to them. They like what they are used to, which is high-level structured programming. AB has a great ladder editor, and ST costs extra. Logix500 doesn't even have ST. If you are programming Beckhoff, the ladder editor and instruction set are not great, so it won't be your first choice. I teach all of these platforms and have also built large systems with all, and the approach is different for all.
In Europe, the chefs demand that the employees whistle while they work to ensure that they are not eating the food, in the US, the chefs want the employees to sample the food as part of the quality control process. Regimented structure against shared authority. In Germany, unless you are upper class, you go to the school that they assign to you or you go without. I would not hold anything in the EU up as an example except their train systems. The US let politicians destroy them.
@@plcprofessor You are stuck in time, what did I just read.
MicroGrid node equipment has many PLCs. Fast builds & repairs are key for reliable production.
In general terms its true. But if You look at other PLC brands then many of them have tools for debugging structured text almost easily as ladder. I can name ABB, B&R as example. And in my opinion complicated part's of program is more readable in ST. I can't imagine writing some communication protocols (for communicating instruments) in ladder.
Omron and Mitsubishi PLC's are actually more "user freindly" than AB once you connect.
St is faster for some applications like CNC robotics still ladder programming It’s much user friendly so I say not all programs are created equal
Are you thinking about the under trained maintenance person at 3am struggling with RSLinx or yourself writing code?
I'm thinking maintenance person at 3am should not be undertrained in the first place. If so, its a problem of a customer. And second of all, the undertrained guy will no way wrap his head around what happens in some communication protocol program that you wrote in Ladder, anyway. Period
@@7Denial7 Facts. If someone has to debug the machine code to figure out the problem, the source of the problem lies else where. Every single fault should be alarmed. You always also have an IO display for all the actuators etc, fault should not be hard to find on the HMI. If it were up to me, I would not let the customer have access to the PLC, its just a fault waiting to happen.
I agree. Funny think is we had made program using ladder, but the customer told us that it was old fashion. They wanted us to use FBD or ST. In my experience a lot of Logic in FBD gets out of hand fast.
Companies hire fresh graduates who tell them that the enterprise should do what they like to do, not what is best for parts out the door.
I believe the genius was programming using 'ladder logic' that looked similar to the schematic diagrams used to show relay logic.
Less downtime then you need a really good test suite. I come from the Wind turbine and generator Industry. Down time is absolute a no go.
The test suite call unittest - integration test and lastly system test is so importen. Many dose not do that which is baffling me alot. Test driven development saves time on site and it is alot cheaper to correct fault at the office compare to the customer site.
I was just 10 years old when I had my first interaction with automation. It was with BASIC on 8bit PC in 1984. Actually, it was my mother's second husband to explained how to connect all the el. appliances at home to the computer and control them. When I started the PLC course I was somehow disappointed in the ladder logic as was already programming Arduino on C++ which is much easier. But a couple of weeks later I understood that is much more important to understand the ladder logic especially the relay logic which actually is based on Boolean algebra. In my opinion, if you don't know what are logic gates and binary system there's no point in losing your time trying to be a professional PLC programmer.
When I designed plc programs, I always thought of the maintenance guys who would be troubleshooting the system and designed the program to be easily understood. I also insisted for others to do the same but, sadly, not everyone has the same mindset. (".)
Hello ,I'm an engineering student..could you please share your email address...I would like to connect with you .
My comment was too early, this was a great CLASS. Definitely will listen more to this “old geaser”.
geezer = over 40, old geezer = over 60, super geezer = over 80 and an ultra geezer is over 100...women are never geezers, they are squeezers.
hell yeah
good modern PLC programs have many data HMI messages to indicate most of the reasons why the machine is not working. Laptop PLC troubleshooting is due to not having enough downtime information such as sensor status and where it is located on the machine . 😎 Thanks for the great information.
Most companies go with the lowest bidder and that does not usually include diagnostic code or screen messages. AOIs have narrowed that cost difference significantly.
What is your stance on function block?
I don't disagree with the sentiment however 30000 lines of code can be searched. Also I see all my variables online with the values. Extremely complex ladder logic can be just as inscrutible as code. All that said. your point was solid, parts out the door.
I still Subbed, so it's not all bad ;) Oh and I worked a completely unseen before 20+ yr old project with +30k lines of ST just two days ago and added a new change request in a few hours (Most of which was finding where to code, and checking it didn't explode anything). Whilst this is not the most amazing turnaround it still beats out trying to fight through thousands of diagrams. IMHO.
Not every process is assembly. How does good parts out the door relate to a water treatment facility? I think his point is that PLC's were created largely to help get more products out the door, by being more user/technician/manager friendly, not so that programmers could sit around doing nothing but dicking around endlessly "creating" AOI's. Valid point, but needs to be stated more clearly
bottom line...structured text is the most time consuming code to write and troubleshoot, machine control or process control but is good for algorithms that never need to pass through for troubleshooting purposes. AOIs can be just as bad if not thought out for the kids on the shop floor.
Makes sense, double check equipment first. Got it. 🔥👍
Oh boy... If you wouldn't have made that gatekeeping statement, that people like me shouldn't be in the industry, I would be nicer but here we are...
My basic opinion is, that if you can't understand ALL IEC languages, you are not suited for your job. In my experience, those guys that say ST is hard to understand, name their variables "xKrBlkip" (global variable of corse!) and don't see anything wrong with it. If you do anything else than binary logic and start using datatypes (like a civilized person), loops, external function calls, LAD just becomes aweful. For simple things, LAD is totaly fine, but if you have a more complex machine, this is defenetly a poor choice.
I think the prejudice from a lot of people that don't like ST, is because they don't know how to use it propperly and write well structured readable code. If you see bad ST code, and think "ST is a bad language" instead of "This is badly written code (let me fix this)", than it's a you problem.
7:25 - What is this formatting? Why is "i" declared at the top, and initialized infront of the while loop? Why a while loop instead of a for loop? This could be done more readable in half the loc.
11:15 - What is this formattig again? Just do an assignment! Rediculous example!
16:30 - Gues what? Formatting! Numbers should be replaced by meaningful constants. I don't see anything wrong with this. I know EXACTLY what happenes in each state, with no cross-interaction. If you don't want to set everything FALSE in every step, just set them all FALSE before the case and set only the things TRUE that you want in each state. Or just do "VARIABLE := State = 1;". I'd prefere statemachines anyday. Statemachines should always have a safety else case! WHY IST THE 0 CASE IN THE MIDDLE???
18:15 - It checks ALL the conditions on every cycle (slow) and is extremly inefficient. This is not the same as CASE! Ontop of that, if you set state in an upper rung, you execute that step (and maybe more states after that) in the same plc-cycle. This is your ticket to an undebuggable statemachine! NEVER do this!
24:00 - Like others pointed out: This is an IDE issue, not ST. I give you that LAD is in this example a little more convinient, but defenetly not something that should bother a professional in any way.
29:08 - I kind of agree here, but if you don't understand ST too, you should be connecting wires, instead of "programming". As someone who knows all IEC languages, I will become rich as hell in the future, if you are right.
29:50 - This is "complex"? This is asignments and IF statements.
30:45 - This is "spagetti code" for you? Two nested IF statments are spagetti code that you can't follow? Sounds like a you problem. I mean, its shitty code and you could write this a lot better, but who cares? just blame the language!
31:20 - If you have to go to step 700... you go to step 700... where is the issue? would have LAD fixed the scrolling? And calling this a "Jump to Label" tells me you don't get this.
31:50 - Yeah, it's not the best ST-Code ever (formatting is realy hard for PLC devs it seems), but I get what happens. Most of the code at the bottom handlse HMI visibility stuff. Having HMI logic on the PLC is one of the worst sins you can do.
32:09 - No one could debug this? I could! You took "one look at this" and decided to rewrite it in LAD??? Rediculous!
I'm sorry, but you need to hear this: Don't blame others for writing ST, because you can't read it!
Shitty code, is shitty code, a language can't fix bad programming.
Hmmmm...I do not remember saying that. Maybe offence taken were none meant...good luck on the shop floor.
You are saying that the maintenance staff has no business troubleshooting industrial control systems if they cannot efficiently analyze structured text. Tell that to the HR department and see how far you get. Arduino bunnies couldn't get in out of the rain if they had to work on the factory floor. It is not about you...never.
@@plcprofessor What I am saying is, that if they can't read ST, they have to learn it. It's part of the IEC Standard and should be expected of someone that wants to do this job.
If HR only employs and caters towards bozos, I will talk with them about my resignation. I started off at the factory floor and did that job for years. I have seen a lot of stuff and the issues are caused by bad engineers, not the language.
I appreciate the notion that at the forefront of every process is getting the most product produced and to the customer in the least amount of time as possible. Most times, but not always, that means using some well thought out structure or language in coding that facilitates quickly interpreting the code and what’s happening. However, with that said, it seems you’re making a lot of assumptions in your efforts to “sell” ladder diagram for PLC programming. So, with all respect, allow me to play devil's advocate 😎
*Assumption 1 - All “Joe Snuffy” maintenance personnel only understand electrical circuit diagrams, therefore all code should be written like a circuit diagram (ladder).*
I've worked with some very talented electricians that actually were pretty good at text languages. A few of them played with Arduinos and other hobby like text programming outside of their jobs. So when it came time to go online with the PLC that had structured text code in it, it was not much of a problem for them to go through it and troubleshoot it just as easy as if they were troubleshooting a LD program.
*Assumption 2 - It will always only be “Joe Snuffy” maintenance personnel troubleshooting PLC code at every company.*
I once worked at a facility where the only people that went online with a PLC to troubleshoot things were the controls/automation engineers. Those engineers were expected to understand the code inside and out, regardless of what language it was. That means going online with the process and studying the code and the machine so that you know it well. In my opinion, that’s the way it should be at every facility. If the company is expecting maintenance people to troubleshoot PLC programs, then those people should know, understand and be able to interpret *all* PLC languages (IEC-61131) well. Otherwise, get someone else with a better suited skillset to troubleshoot the PLC programs. In regards to that, it doesn't *always* need to be maintenance and electricians only. In fact, it doesn't need to be them at all. Companies should get out of that paradigm mind set that its maintenance and electricians that troubleshoot PLCs. I know its become a bit of a norm, but companies are making their maintenance personnel do a job that they are not trained or experts in. So then in many cases, we're dumbing down the program or not utilizing the full capabilities of the PLC technology and advantages of certain PLC languages simply because "Joe Snuffy" might take longer to interpret it if its not what he/she knows (LD).
*Assumption 3 - Ladder diagram will always be easier to interpret than text code, for every task.*
Take a very common task of iterating through an array of integers and finding the element within that has the highest value. It's going to be much easier to both write and interpret that in ST than in LD, especially if your PLC platform doesn't have a ready-made For Loop instruction. In ST, it would be a simple and very common For-Next loop. That's just one example of many.
*Assumption 4 - Everyone will interpret ladder diagram faster and easier than they interpret text code.*
I once worked with a particular gentleman that could write and interpret text code like it was nobody’s business, but had a heck of a time understanding and interpreting LD, something that supposedly is supposed to be easy for everyone. Moreover, I've often times been around persons with text programming background that just couldn't grasp the "normally open" and "normally closed" concept.
*Assumption 5 - All PLCs brands that use text code, will not show the value of a variable in that text code when you’re online with the PLC. You will only be able to see the online value in a ladder editor.*
Perhaps that's how it is in RSLogix world, but that is not the case at all in some others, particularly anything that uses Codesys or Codesys under the hood (Beckhoff). With those, you can be online with the PLC and see the real time values of the variables inside the structed text editor just the same as you can in the ladder editor. No difference.
Something else I feel needs to be mentioned in regards to graphical languages (LD, FBD, SFC) versus text languages (ST, IL). Graphical languages take longer for the processor to process versus text languages. This means you'll have a longer scan time requirement for LD than if the same routine was written in ST, especially for larger programs. Scan times matter! A simple difference of 10ms scan time versus 2ms scan time could be the difference of 100 widgets per hour at 10ms scan time versus 101 widgets per hour at 2ms scan time. For a typical 24/7 operation, that's a difference of ~8760 widgets per year!!! So, it's not just the downtime that can directly be seen that is costing the company money. It's also the "downtime" that cannot be directly seen that is costing the company money too.
The way I like to do it and from my experience works well, is to have a Faults routine and write it in LD or FBD. In most cases, the rungs will be simple and easy to interpret. For the rest of the process/machine, feel free to use whatever language is best suited for the task.
I am not selling anything. I am making a lot of money cleaning up processes written in structured text that their technicians/electricians can't troubleshoot and most of it is spaghetti code. You cannot monitor the logical continuity in any of those platforms that you mentioned...What good are the tag values if they are not present in an active dynamic context?
@@plcprofessor You're trying hard to make an argument for LD, and making a lot of assumptions in the process. That was my point in my post. I've seen it before. If LD is the way we all should be doing it, then why is there even other PLC languages in IEC-61131? Furthermore, why is the predominant PLC language used in the EU, Structured Text???
"that their technicians/electricians can't troubleshoot".
That is NOT a PLC language problem! That is the person/s that wrote the code problem. Spaghetti code can be done in any language, not just ST. That is also, perhaps and very likely, the technicians/electricians that can't comprehend text languages. In that case, that's a company problem that's hiring the wrong persons for the job. Again, as I implied in my original post - Stop hiring electricians to be programmers!! If these persons are going to be the ones troubleshooting PLC programs, then they should be expected to be able to comprehend all PLC languages that could be present in a PLC at any given time. That means the company needs to get them up to speed, and if those persons don't get there, then the company needs to get someone that can/will get there. But the PLC language used should not be "dumbed down" for anyone. We use the best language for the task, period! There needs to be a paradigm shift in thinking that "only electricians work on PLC's and that's who we hire for these jobs". Hire programmers to be programmers. Hire electricians to be electricians. But that makes too much logical sense.
@@plcprofessoryou professor completely ignore the good points people point out. Too stubborn to admit that they are right in some point and you are wrong
Based on the cover picture's bright light, I have to ask how many KW hours do you "burn" each month. Doing Systems Analysis for energy. Currently, working on vertical Wind-Turbines within MicroGrid nodes. Been doing A.I. since 1988 (U.S.). What's all the excitement all about? ChatGPT isn't greatly new. Relax and learn about it. Expect many generations ahead inside PLCs.
...and I am willing to speculate that if you lost power, it would probably be the death of you. I was doing neural nets well before that.
Nice shop where are you from?
Indiana
Good evening,
May i ask for a clarification, did your first statements mean the "highest quality (reliability)" in parts, or "Variety of available boards" or the logger/debugging facility, or a combination ? I was not sure .
By the way the ST with goto is really not good practice with high level languages, if ST doesn't support high level constructs such as function calls, i can understand how complex code very quickly becomes hard to follow.
Thanks,
Jean-François
You lost me...
@@plcprofessoryou lost yourself. Arrogant. I read through what you replied to people, and you completely ignore their points, acting like you some kind of superior PLC guru. Let me tell you, you're not. Being older doesn't mean you are any good
Wow, my thoughts exactly you are spot on❤❤
This example is really bad. You are saying that because your IDE of choice does not provide good ST debugging experience, ladder is better. I use both, I prefer ST, ladder is fine, but when it gets to big projects and a bit longer networks, debugging ladder is god awful, since I don't have a cinema theatre to display enough networks without scrolling for 3 days to find what i am looking for. They both have pros and cons, your example is just poor, sorry to say.
You are right. With all the new gadgets and technology, we've collectively lost our way since the late 70's. All this tech should make the machine totally able to tell you totally whatever is wrong with it. All assuming that the electrical and process design captured enough information to do so.
Nice info, thank you for sharing it :)
I understand and generally agree with your take home message, but I don't think you are doing a great job with the examples and (for me anyway) it detracts from your point. They are somewhat contrived and it looks like you are setting up a straw man for ST.
Example 1 code could have been this;
_IO_EM_DO_09 := _IO_EM_DI_01;
_IO_EM_DO_08 := _IO_EM_DI_00;
.... not whatever the hell you had.
In my opinion state example 1 shows why ST is good. I would prefer to read that in ST to understand its function.
In state example 2 I believe ST would be more equivalent with something like;
_IO_EM_DO_00 := (State = 1);
_IO_EM_DO_01 := (State = 2);
_IO_EM_DO_02 := (State = 3);
_IO_EM_DO_03 := (State = 4);
much more concise in my opinion.
I get and understand your point regarding monitoring. 100% agree with you for CCW, but I don't think you are really comparing apples to apples when it comes to the industry as a whole. Rockwell is known for being horrible for structured text. I could show you some IDE's which make ladder equally as abhorrent that have really nice ST editors.
We also didn't touch on loops or other more advanced algorithms.
At the end of the day, use the right tool for the job. Good job, keep the videos coming.
Good luck on the shop floor...
I'm working with people they no understand the basic start stop motor they say programming plc before
also you are being unfair to your structured text. You use very verbose statement with if and else and in the ladder you just assign. so if you just assign OutputX := Input Y, it is more readable and would be the same logic as a normal coil ... (well ok, the other way around, the output comes first because it is the assigned variable) ... of course you need a st editor that can show state and maybe even color code ... so I agree with the visual trouble shooting and state aspect ... you will see that any visual programming language will be popular with some audiences, but once it get's more complicated, often structured text is more powerful and often actually more readable ... if you look at complex node red diagrams, you will easily get lost ... there is a lot of low code programming hype, which I understand and it certainly has it's benefit ... and if you look at it, PLC ladder logic was actually a very early low code programming language for non-programmers (electrical engineers extending their working field) ... the same is true with todays "marketing programmers" or "analyst programmers" that use similar visual programming to solve problems in their domain without being a full code developer
You missed the entire point...this was not about you.
Shane Lodge
Jefferey Plains
Kristopher Islands
Valerie Drives
Wrong. Simple as that. Monitor...the device...what your wrong on is how the device is monitored. The device can me monitored, logged, and trended easily in HMI code and (importantly) arranged logically as to function which may or may not be how/where it was written.
Daren Vista
Let me guess, you were an industrial electrician or engineer who started working on plc's in a manufacturing factory....and has absolutely no experience doing anything else?
How ever I do agree with all of this.
Yes that is true an engineer who started writing fortran and basic for non industrial applications and has thousands of hours on the factory floor working with electricians and technicians and listening to management whine about the downtime and how much it is costing the enterprise that pays our salaries. When you throw a rock into a pack of dogs, the one that yelps is the one that you hit...
@@plcprofessorI can tell, you believe this fallacy where companies are hiring and training plc programmers.
That's not how anything works. Your entire generation had the same basic experience you did. They learned step by step as technology progressed working at the same place for 40 years.
Today companies are trying to hire direct replacements of you. They are looking for guy who has experience with fortran, and slq500, and some obsolete fanuc robot, and some super specific machine tools they have. Those people don't exist, the only reason you do is because you grew with the technology and the company. Thats why there are no programmers available.
And if a company does stumble across a guy that has plc experience, they don't want to pay him more than the dope that changes light bulbs.
The old managers are all retiring, and they are being replaced by some moron with a receipt saying they wasted 4 years at an indoctrination center. Those goofballs have absolutely no idea what ladder logic is or why what you said in this video is correct and relevant.
I am self-employed and have a range of processes and equipment worked with that is extensive. I have never worked in one place more that 4 years, how about you? What is your background?@@EitriBrokkr
The goal isn't just products it's also about safety? Sorry how could you miss such a critical aspect of PLCs? Sorry as you said in your preamble maybe I don't belong in the industry if I don't take safety as seriously as production?
These days, regular PLCs and Standard portion of Safety PLC, should never been used for safety. When machine maker or any other integrator leaves the floor, safety logic in Safety PLC and Safety wiring must be checked and verified ahead of time. In case of safety PLC, the Safety part of it must be locked and being Password protected.
Jumped in without hearing the full of it, did you? Safety has nothing to do with programming languages, safety is 95% hardwired. The CR30, which is what I use, has a very simple graphic programming language.
Aletha Glen
Jeff Hill
Your whole point around ST being worse than LD is demonstrated on like the simplest hello-world a PLC can do. Your standpoint is like from 30 years ago, things have changed alot!
Also you picked a manufacturer which is not capable of live debugging ST, which is not ST's fault. I can see the variable value live and can change it by a single click or force it with 2 clicks on a beckhoff system.
Even your big statemachine in the main POU does almost nothing other than setting some booleans.
how would you even begin to iterate over some 1000 structurized member array ? - oh wait you guys would copy paste the same logic a thousand times.
Have you even mentioned breakpoints ? Or is your plc also incapable of that?
With no word you mentioned the extended IEC-61131 object-oriented ST, which to me is another sign that even if you did program BASIC or FORTRAN years ago, you don't actually really get how modern PLC is/could be programmed, or do you know what an Interface-POU is and why it is used?
The only point you have is that electricians won't be capable of debugging ST code, which is kinda true. But then again, try to program a modern big machine on like LD, it is gonnna be a nightmare and you cost way more than any electrician trying to fix ST logic. And if ST delivers faster, most companies will take ST-coded machines.
Jakubowski Way
I've worked on panels that were all relay logic.... relays latches timers motor contactors.... it was a lot of work.
The suggestion to do not learn Structured Text as the primary programming language when approaching PLC (or any other 61131-3 based Control System) is a very bad career advice.
Hmmmmmmmmmmmmmm...I do not remember saying that
Hi @@plcprofessor, thanks for replying.
In the introduction it is emphasized the idea that, in order to get good code, it should be easy to troubleshoot the code itself by monitoring online the PLC variables.
After that, there is a comparison of the benefits of a graphical language vs. textual languages, with a few examples to show that the graphical approach provides a better way to troubleshoot the code.
Finally, it's written in the notes that this information is given to programmers for the sake of their careers.
So, what I understand by watching this video is that if I want to get good code, then I should expect to monitor my variables online and therefore it's a good career advice for me to use graphical languages since they're more suitable for online monitoring.
This may be an acceptable approach in very specific projects or when using some PLC platforms with limited features, but it is certainly not a good career advice.
The career advice is to engineer for maintainability with the available workforce for maintenance.@@nzsystems
I 100% agree with you, if someone is really good at language like ST and wants to program every machine in ST, they better find a job in the tech company, and they will get paid a lot more.
Koepp Springs
Katrine Squares
Please clean up the audio. The left ear phone has clear sound , the right has a constant white noise that takes out the talking .
mine plays just fine...not sure what your issue was.
Koelpin Shoal
This is so wrong... so much bias... you can write excellent, highly readable and very well observable programs in structured text. If you need to read actual PLC program to understand what's wrong with your machine, then you solution is simply an unfinished job... HMI should give you enough information to troubleshoot the machine. The comparative examples are ludicrous, you don't write ST programs with LD mindset. On the topic 'picture worth of a thousands words' it is true in a very narrow sense. If I switch off the audio of this video... what would I understand? For understranding we need language (words) that is very a well established fact in cognitive sciences.
Have you worked on these machines yourself or worked with the people who do? The electricians and maintenance workers who repair them are much more familiar with electrical schematics. LD is much more intuitive to them because it mimics that. There is a place for ST, but that place is for things you wouldn't expect maintenance workers to be dealing with anyways such as communications protocols, analog signal filters, etc. Things you want to keep in the blackbox.
Both; 25+ years; I know what works best... ;)
When you throw a rock into a pack of dogs, the one that yelps is the one that you hit. I learned that your opening statements must be provocative. I love the results.
@@plcprofessor Excellent argument professor! Just like those in the video. Bravo!
Most companies go with the lowest bidder and that does not usually include diagnostic code or screen messages. AOIs have narrowed that cost difference significantly.
St is best suited for microcontrollers. Not Plcs. Still one of my favorite languages. C# my favorite, garbage collection, C++ no heap.
💯 % Agreed with you sir. 🫡
Troubleshooting is the most complicated part of the work, but also the most important!!!!
💯 % Agreed with you sir. 🫡
Troubleshooting is the most complicated part of the work, but also the most important!!!!
💯 % Agreed with you, sir. 🫡
Troubleshooting is the most complicated part of the work, but also the most important!!!!
💯 % Agreed with you, sir. 🫡
Troubleshooting is the most complicated part of the work, but also the most important!!!!