If you are just wanting to use advanced programming to turn on an output or read an analog and do something in a long period of time that's fine. but in a controller running on a machine you need to be guaranteed reliability. Having a vendor in control of the languages being programmed keeps the OS running very fast. running C++, or any web based programming languages are ok if when they do down you have time to troubleshoot them, which always takes 10x longer than the other languages. Plus with Most PLC's now they do safety at the same time, Motion at the same time. Those languages aren't built for that to be super fast. If you have a little brick PLC that you want to do that in then great, but advanced programming languages are built for Programmers(who can't troubleshoot circuits). when you go down time is money in getting back up. Those languages are long downtimes to figure out what is wrong and if you need to change a process you can pretty much write it on the fly download and test in a very short time. I haven't seen the product but if there isn't a status of what the C++ or whatever language it's programmed in, then it will never really fly in a real manufacturing plant.
Good observations and good advice. The system, hardware, software, and programming languages used need to be familiar to engineers and technicians, able to have troubleshooting performed quickly and accurately, and not require recompilation or redownloading of programs while the plant is running. Ladder logic seems old-fashioned and simplistic, but in most cases, PLC manufacturers allow for online program modifications that can greatly improve troubleshooting speed and accuracy.
@@realpars Ladder logic is old fashioned, definitely agree, but the audience I see everyday knows this world very well, and the integrators who should be on top of technology and programming languages are still programming in this language. I grew on on this, but have made a conscious effort to get better in the other languages. I am better but it does take time.
@@bunnyman6321 More so it has to do with the audience that is using the code. PLC's have come a long way in bringing together electricians, EE's and computer coding types. If you can have a common type of language that most everyone can understand then that is what you go with. I work with all types of people doing PLC troubleshooting. Most of which can't or won't try and figure out IF, THEN, ELSE type of programming but everyone can understand Ladder or FBD. Personally there is another language that I think would be perfect now that I think of it and that is something that you just drop blocks onto a work area on your screen and drag lines from the outputs of one block to inputs of another. That would be the ultimate anyone can work on scenario.
As far as I can remember from realpars tutorials, python can be used as programming language to program PLCnext CPU's. Eagerly waiting to see tutorials from Realpars .I really like the raw nature of the video content by the way. Nice!
If PLC is able to do logic coding using C++ or java or others..so what is the need of IEC61131 standardization?. How about technicians who do trouble shooting? Do they need to learn C++ or java or others?
when you need to write complex algorithms then higher level languages are better. It totally depends on the problem you are tackling. Having an option for higher level language is plus. Also Open PLC is not the first one to come up with this implementation just for putting some info here
Some PLCs are able to employ C++ as a programming language, mainly the more modern open-source PLCs. PLCs from the major manufacturers will always need to support IEC61131 languages, in my opinion, while newer open PLCs have an important place in machine control and robotics. Technicians, for the most part, are not C++ programmers, so manufacturers will need to determine the best cost/value approach to maintenance. Engineers are more likely to favor higher-level programming languages, but unless they are charged with supporting these programs 24/7, it us best to use the tools that are most useful to plant-floor technicians.
@@realpars agreed...but it's better if logic code in C++ able to switch to IEC61131 for technicians. Trouble shooting does not always come from I/O but from interlock and "handsake" from other device or system too.
Any system that requires troubleshooting by plugging into the PLC to view and possible modify code, is a poorly designed and poorly tested system. This is where we must change; more testing and more user and technician friendly interface.
I'm afraid the result will be hard to secure. The concept to Data space is nice but I'm not sure that trusted and untrusted pieces of software can coexist without harm.
But Linux is not a real time OS ! I can't use something this slow for motor fault detection and will need additional hardware + software for this purpose.
It blows my mind that's it's 2023 and we are just now getting something like this. Feels like the automation software world has lagged behind the broader tech software world significantly over the last 10 years. I'm still confused as to why we rely on ladder logic so much over established programming languages that the rest of the software industry has built such incredible systems with. Even PLC HMI's are pretty low quality verses the user interfaces you can creat with pretty much any other open language.
Hello @Arturo Pino. You are bang-on with your comments. As for the relevance and use of ladder logic, I think many applications can be easily solved with LD programs. LD is still the sweetheart of electrical and maintenance types as the structure and layout are easily interpreted. Slowly but surely a new generation of automation folks is becoming more familiar with text-based and higher-level languages. Perhaps LD will slowly go the way of the dinosaur? Time will tell.
@@realpars Completely agree, I think a necessity to maintain and troubleshoot has been a major driver in the course of PLC history when compared to tech-focused software platforms. That being said, I think you guys are doing a massive service by exposing the world of industrial automation to these new tools that are out there.
Siemens has been able to do IF..Then.. Else type of programming for over 25 years, they have given the ability to do C language in some of their devices for almost that same timeframe. Now with their newer HMI's they can do JavaScript. But problem still exists if someone puts in that code that doesn't have an online status value, troubleshooting time goes up tremendously. Most of the newer languages just give you tools for Web based things. Heavy number crunching have been in PLC's for ever. Where some of these languages fall apart is speed in the plc. When doing motion, Safety. PLC's are very important to processes and if you have a non standard language in a PLC, it goes down, and you have a plant manager breathing down your neck to get it up and running, you'll see why the IEC language works. If you can't figure out the problem on of a 100 people in the US probably can. If it's all in some third party language then mostly only a person who does coding can figure it out, and that is he understands what a plc does, if not then he needs a technician to pull him along.
If you are just wanting to use advanced programming to turn on an output or read an analog and do something in a long period of time that's fine. but in a controller running on a machine you need to be guaranteed reliability. Having a vendor in control of the languages being programmed keeps the OS running very fast. running C++, or any web based programming languages are ok if when they do down you have time to troubleshoot them, which always takes 10x longer than the other languages. Plus with Most PLC's now they do safety at the same time, Motion at the same time. Those languages aren't built for that to be super fast. If you have a little brick PLC that you want to do that in then great, but advanced programming languages are built for Programmers(who can't troubleshoot circuits). when you go down time is money in getting back up. Those languages are long downtimes to figure out what is wrong and if you need to change a process you can pretty much write it on the fly download and test in a very short time. I haven't seen the product but if there isn't a status of what the C++ or whatever language it's programmed in, then it will never really fly in a real manufacturing plant.
Good observations and good advice. The system, hardware, software, and programming languages used need to be familiar to engineers and technicians, able to have troubleshooting performed quickly and accurately, and not require recompilation or redownloading of programs while the plant is running. Ladder logic seems old-fashioned and simplistic, but in most cases, PLC manufacturers allow for online program modifications that can greatly improve troubleshooting speed and accuracy.
@@realpars Ladder logic is old fashioned, definitely agree, but the audience I see everyday knows this world very well, and the integrators who should be on top of technology and programming languages are still programming in this language. I grew on on this, but have made a conscious effort to get better in the other languages. I am better but it does take time.
@Why Not What do you recommend ladder logic be replaced with with?
@@bunnyman6321 More so it has to do with the audience that is using the code. PLC's have come a long way in bringing together electricians, EE's and computer coding types. If you can have a common type of language that most everyone can understand then that is what you go with. I work with all types of people doing PLC troubleshooting. Most of which can't or won't try and figure out IF, THEN, ELSE type of programming but everyone can understand Ladder or FBD. Personally there is another language that I think would be perfect now that I think of it and that is something that you just drop blocks onto a work area on your screen and drag lines from the outputs of one block to inputs of another. That would be the ultimate anyone can work on scenario.
@@whynot16384 Thank you!
As far as I can remember from realpars tutorials, python can be used as programming language to program PLCnext CPU's. Eagerly waiting to see tutorials from Realpars .I really like the raw nature of the video content by the way. Nice!
Thanks for sharing!
Same here.
We want brief explanation on programming with animation
If PLC is able to do logic coding using C++ or java or others..so what is the need of IEC61131 standardization?. How about technicians who do trouble shooting? Do they need to learn C++ or java or others?
when you need to write complex algorithms then higher level languages are better.
It totally depends on the problem you are tackling. Having an option for higher level language is plus.
Also Open PLC is not the first one to come up with this implementation just for putting some info here
Some PLCs are able to employ C++ as a programming language, mainly the more modern open-source PLCs. PLCs from the major manufacturers will always need to support IEC61131 languages, in my opinion, while newer open PLCs have an important place in machine control and robotics. Technicians, for the most part, are not C++ programmers, so manufacturers will need to determine the best cost/value approach to maintenance. Engineers are more likely to favor higher-level programming languages, but unless they are charged with supporting these programs 24/7, it us best to use the tools that are most useful to plant-floor technicians.
@@Zeesh009 yes I know the advantage and I know what the problem when implemented 24x7 on shop floor in term of maintenance.
@@realpars agreed...but it's better if logic code in C++ able to switch to IEC61131 for technicians. Trouble shooting does not always come from I/O but from interlock and "handsake" from other device or system too.
Any system that requires troubleshooting by plugging into the PLC to view and possible modify code, is a poorly designed and poorly tested system. This is where we must change; more testing and more user and technician friendly interface.
Schöne Grüße nach Bad Pyrmont 🎉
I'm afraid the result will be hard to secure. The concept to Data space is nice but I'm not sure that trusted and untrusted pieces of software can coexist without harm.
Könntet ihr ein Video zu PCS7 Neo machen?
Thanks for your topic suggestion, Matej! I will happily go ahead and add this to our list of topic suggestions.
Happy learning!
Amazing open PLCs..It can be used for unlocking the power of industrial automation.. very helpful
💯
But Linux is not a real time OS ! I can't use something this slow for motor fault detection and will need additional hardware + software for this purpose.
It blows my mind that's it's 2023 and we are just now getting something like this. Feels like the automation software world has lagged behind the broader tech software world significantly over the last 10 years. I'm still confused as to why we rely on ladder logic so much over established programming languages that the rest of the software industry has built such incredible systems with. Even PLC HMI's are pretty low quality verses the user interfaces you can creat with pretty much any other open language.
Hello @Arturo Pino. You are bang-on with your comments. As for the relevance and use of ladder logic, I think many applications can be easily solved with LD programs. LD is still the sweetheart of electrical and maintenance types as the structure and layout are easily interpreted. Slowly but surely a new generation of automation folks is becoming more familiar with text-based and higher-level languages. Perhaps LD will slowly go the way of the dinosaur? Time will tell.
@@realpars Completely agree, I think a necessity to maintain and troubleshoot has been a major driver in the course of PLC history when compared to tech-focused software platforms. That being said, I think you guys are doing a massive service by exposing the world of industrial automation to these new tools that are out there.
Siemens has been able to do IF..Then.. Else type of programming for over 25 years, they have given the ability to do C language in some of their devices for almost that same timeframe. Now with their newer HMI's they can do JavaScript. But problem still exists if someone puts in that code that doesn't have an online status value, troubleshooting time goes up tremendously. Most of the newer languages just give you tools for Web based things. Heavy number crunching have been in PLC's for ever. Where some of these languages fall apart is speed in the plc. When doing motion, Safety. PLC's are very important to processes and if you have a non standard language in a PLC, it goes down, and you have a plant manager breathing down your neck to get it up and running, you'll see why the IEC language works. If you can't figure out the problem on of a 100 people in the US probably can. If it's all in some third party language then mostly only a person who does coding can figure it out, and that is he understands what a plc does, if not then he needs a technician to pull him along.