This is a good presentation about how useful and intuitive an object structured application can be. The problem is, CODESYS and other PLC frameworks don’t allow you to schedule beyond the program level. This is an issue if you need some of your objects to execute faster than the main program. You either have to schedule everything in the program at the fastest rate required which is a waste of CPU utilisation or, separate those objects out. In the latter case you just end up with a task structured program again. The ABB Advant 450 controller is the only system that I know of that allows you to schedule parts of a program at different intervals using the CONTRM PC element. However this is a legacy system that doesn’t have IEC 61131 support.
You are correct. Although, there are several good alternatives. First, have you considered event-driven programming? Using this technique, the functionality of each object is only invoked when required. This is described in the Advanced chapter of The Book of CODESYS. Another technique is to implement a central service. With this, each object registers itself and specifies the cycle time it requires. The central service then calls each object with the specified cycle time. This is also described in the Advanced chapter. I would be happy to help you implement either approach.
CODESYS allows integration of C code, so if you can wrap your Java in C, you can integrate it in. However, I only recommend that for legacy code that you absolutely don't want to touch. There is a reason why we don't program industrial automation in IT languages -- most automation applications can't tolerate the terrible reliability of most IT software. Best to stick with IEC61131-3 for automation. Rebooting your phone/pc/smartTV/router/etc is an irritation. Rebooting your plant or machine could be a disaster.
@@ControlSphereC is used in so many safety critical embedded systems now it’s really hard to justify that argument you just made. If anything, I see IEC 61131 languages as completely unnecessary given the abundance of safety critical embedded systems using C, ADA, Spark, Rust etc. the IEC 61131 languages are an unfortunate legacy of trying to allow electricians and chemical engineers the ability to use programmable equipment for industrial automation. C and ADA etc. are extremely reliable and are used as the underlying firmware for many PLCs, satellites, medical equipment etc. so saying that they are unreliable is totally misleading.
@@user-fk9mo2ld6w I stand by my statement. It is significantly more difficult to create reliable systems in IT languages than it is in a system and language specifically designed to maximize reliability. That having been said, I do differentiate between IT and embedded systems. Reliable embedded systems can and do exist, but they were created by highly trained and highly skilled expert engineers. (In the wrong hands, you end up with Toyotas with uncontrolled acceleration, Max jets falling from the sky, and Mars missions careening past their destination, etc.) It typically isn't cost-justified to apply expert embedded resources to most industrial automation systems, especially when there is an excellent alternative.
@user-fk9mo2ld6w For sure, there are high-volume automation systems which can cost justify the expertise necessary to create a reliable embedded system. But, these are the exceptions, not the mainstream. And, with those they should use Eclipse, Visual Studio or some other embedded system development environment -- not using the C-code integration to write Java code in CODESYS.
@@ControlSphere are you implying that people who work in the industrial automation field are not highly skilled or highly trained? You can be highly skilled or highly trained in anything and make mistakes or do things improperly and cause issues. It's the relatively simple functional requirements for most industrial systems that make them much easier to develop, and the development be done in any programming language in theory. Compare that with the functional requirements for a satellite or aerospace navigational computer and you see the obvious leap in complexity. Nevertheless, both can be extremely reliable if developed properly. The reason a lot of IT systems are not as reliable is more to do with the underlying operating systems that prioritise user experience over task determinism. They allow things like dynamic memory allocation, complicated and unpredictable task scheduling, non type safe programming languages etc. Personally, I think that the IEC 61131 languages should (and eventually will) be superseded by C, Rust, Spark and Ada. That being said, the framework in which PLCs are developed with static memory allocation, deterministic task scheduling etc. is obviously a good thing and the IDEs, CODESYS included are user friendly enough to make developing PLC applications relatively easy.
That's great to hear. For PLC designs? Be sure to understand the distinction between OOP and OOIP. Many plant managers fear that bringing pure OOP techniques into the PLC world will require their plant or equipment to be rebooted as often as their computer/phone/TV/etc. OOIP is a first step that provides many of the productivity improvements of OOP without the complexity/reliability issues. Plus, its something their plant technicians can understand and troubleshoot. Plant managers tend to be much more open to OOIP.
@@ControlSphere Thanks for the response. I’m speaking of PLC and DCS (PCS 7). I’ve implemented the same same type of designs in Codesys 2.9.x, 3.5 and Siemens PCS 7. Currently rebuilding function block library in Siemens TIA since they now have CFC.
@@abstractobject5337 Very good! Sounds like you were on the leading edge. I'm curious how you solved the distributed object configuration in CODESYS (and that and the distributed object I/O mapping in PCS 7)
Please elaborate with examples on why you feel CFC is difficult to use and troubleshoot. This is the first I've heard this perspective. Do you have experience with LabView or SimuLink, and do you find that equally difficult?
@@ControlSphere I am coming from Beckhoff which is based on CodeSys. Trying to cross ref a tag to a CFC sheet just takes you to the sheet. If you have a large CFC sheet you then have another step to find the tag. You can't add a breakpoint to a CFC sheet like you can in ST, FBD or LD. I never use IL but you can add breakpoints there if you want to. In programs I have worked by other guys done in CFC it looks like spaghetti messes. Mostly used by the older guys who came from creating circuits back in the day. Maybe if done "well" they might be easier to read but I have never seen them done well and are terrible to troubleshoot when done poorly. If someone decides to use the entire sheet you are constantly scrolling side to side and up and down to find what you are looking for. At least with ST you can copy to NotePad++ and make changes quickly if needed. You can't really do that with graphical languages. I have not used LabView or SimuLink but understand what they do. We don't have those tools at my job. Maybe if you are really used to those tools that is why you prefer CFC. Honestly this is the first tutorial I have found that uses CFC. Most programmers I have worked with stay away from this language and like ST, FBD and Ladder.
@@AudioJunkie79 Unfortunately, there isn’t a programming language on the earth that proscribes bad code. A large flat design is difficult to understand and debug in any language. Apparently, Beckhoff has some limitations as its possible to set breakpoints on any box and single-step through the CFC design in CODESYS. I do agree that creating a design in a graphical language takes slightly longer, but I have never prescribed to the language-based programmers’ philosophy of “minimum keystrokes at any cost” (and “look how clever I am, I consolidated 5 lines of code into one [that no one will ever understand]”. I’m willing to spend a little more time to make something that is much easier for others to understand and enhance in the future. Also, I don’t disagree with those who say text-based languages are a holdover from the days before computers had graphic capabilities, and that graphical languages better utilize the significant portion of the human brain dedicated to understanding picture. This is why LabView and Simulink are so popular. Take a look at this link for examples of CFC-based designs ruclips.net/video/wJYNTeAE7lk/видео.html
This is a good presentation about how useful and intuitive an object structured application can be. The problem is, CODESYS and other PLC frameworks don’t allow you to schedule beyond the program level. This is an issue if you need some of your objects to execute faster than the main program. You either have to schedule everything in the program at the fastest rate required which is a waste of CPU utilisation or, separate those objects out. In the latter case you just end up with a task structured program again.
The ABB Advant 450 controller is the only system that I know of that allows you to schedule parts of a program at different intervals using the CONTRM PC element. However this is a legacy system that doesn’t have IEC 61131 support.
You are correct. Although, there are several good alternatives. First, have you considered event-driven programming? Using this technique, the functionality of each object is only invoked when required. This is described in the Advanced chapter of The Book of CODESYS. Another technique is to implement a central service. With this, each object registers itself and specifies the cycle time it requires. The central service then calls each object with the specified cycle time. This is also described in the Advanced chapter. I would be happy to help you implement either approach.
Here and watching Gary! Great video, looking forward to more.
woauh , very interessing Sir
Very nice job , and Good explaination
Could you share backup with Please
The OOIO Demo Project can be found at ooip-foundation.proboards.com...
Αs a java/c++ programmer this subset of oop I use ! I have a question : do you know if there is an API for java/c++ ?
CODESYS allows integration of C code, so if you can wrap your Java in C, you can integrate it in. However, I only recommend that for legacy code that you absolutely don't want to touch. There is a reason why we don't program industrial automation in IT languages -- most automation applications can't tolerate the terrible reliability of most IT software. Best to stick with IEC61131-3 for automation.
Rebooting your phone/pc/smartTV/router/etc is an irritation. Rebooting your plant or machine could be a disaster.
@@ControlSphereC is used in so many safety critical embedded systems now it’s really hard to justify that argument you just made. If anything, I see IEC 61131 languages as completely unnecessary given the abundance of safety critical embedded systems using C, ADA, Spark, Rust etc. the IEC 61131 languages are an unfortunate legacy of trying to allow electricians and chemical engineers the ability to use programmable equipment for industrial automation. C and ADA etc. are extremely reliable and are used as the underlying firmware for many PLCs, satellites, medical equipment etc. so saying that they are unreliable is totally misleading.
@@user-fk9mo2ld6w I stand by my statement. It is significantly more difficult to create reliable systems in IT languages than it is in a system and language specifically designed to maximize reliability. That having been said, I do differentiate between IT and embedded systems. Reliable embedded systems can and do exist, but they were created by highly trained and highly skilled expert engineers. (In the wrong hands, you end up with Toyotas with uncontrolled acceleration, Max jets falling from the sky, and Mars missions careening past their destination, etc.) It typically isn't cost-justified to apply expert embedded resources to most industrial automation systems, especially when there is an excellent alternative.
@user-fk9mo2ld6w For sure, there are high-volume automation systems which can cost justify the expertise necessary to create a reliable embedded system. But, these are the exceptions, not the mainstream. And, with those they should use Eclipse, Visual Studio or some other embedded system development environment -- not using the C-code integration to write Java code in CODESYS.
@@ControlSphere are you implying that people who work in the industrial automation field are not highly skilled or highly trained? You can be highly skilled or highly trained in anything and make mistakes or do things improperly and cause issues. It's the relatively simple functional requirements for most industrial systems that make them much easier to develop, and the development be done in any programming language in theory. Compare that with the functional requirements for a satellite or aerospace navigational computer and you see the obvious leap in complexity. Nevertheless, both can be extremely reliable if developed properly.
The reason a lot of IT systems are not as reliable is more to do with the underlying operating systems that prioritise user experience over task determinism. They allow things like dynamic memory allocation, complicated and unpredictable task scheduling, non type safe programming languages etc.
Personally, I think that the IEC 61131 languages should (and eventually will) be superseded by C, Rust, Spark and Ada. That being said, the framework in which PLCs are developed with static memory allocation, deterministic task scheduling etc. is obviously a good thing and the IDEs, CODESYS included are user friendly enough to make developing PLC applications relatively easy.
Been using these design patterns at Texas Instruments since 2009 and earlier.
That's great to hear. For PLC designs? Be sure to understand the distinction between OOP and OOIP. Many plant managers fear that bringing pure OOP techniques into the PLC world will require their plant or equipment to be rebooted as often as their computer/phone/TV/etc. OOIP is a first step that provides many of the productivity improvements of OOP without the complexity/reliability issues. Plus, its something their plant technicians can understand and troubleshoot. Plant managers tend to be much more open to OOIP.
@@ControlSphere Thanks for the response. I’m speaking of PLC and DCS (PCS 7). I’ve implemented the same same type of designs in Codesys 2.9.x, 3.5 and Siemens PCS 7. Currently rebuilding function block library in Siemens TIA since they now have CFC.
@@abstractobject5337 Very good! Sounds like you were on the leading edge. I'm curious how you solved the distributed object configuration in CODESYS (and that and the distributed object I/O mapping in PCS 7)
Where can I download this project? Thank you!
Chapter 19 in www.TheBookOfCodesys.com or ooip-foundation.proboards.com/thread/7/ooip-video-demo-project
can I pay for the book in installments?
Yes. Amazon offers payment plans
Thanks,very useful information!
Awesome!
Why would you uses CFC? That is the worst language to use and to troubleshoot. At least use FBD.
Please elaborate with examples on why you feel CFC is difficult to use and troubleshoot. This is the first I've heard this perspective. Do you have experience with LabView or SimuLink, and do you find that equally difficult?
@@ControlSphere I am coming from Beckhoff which is based on CodeSys. Trying to cross ref a tag to a CFC sheet just takes you to the sheet. If you have a large CFC sheet you then have another step to find the tag. You can't add a breakpoint to a CFC sheet like you can in ST, FBD or LD. I never use IL but you can add breakpoints there if you want to. In programs I have worked by other guys done in CFC it looks like spaghetti messes. Mostly used by the older guys who came from creating circuits back in the day. Maybe if done "well" they might be easier to read but I have never seen them done well and are terrible to troubleshoot when done poorly. If someone decides to use the entire sheet you are constantly scrolling side to side and up and down to find what you are looking for. At least with ST you can copy to NotePad++ and make changes quickly if needed. You can't really do that with graphical languages. I have not used LabView or SimuLink but understand what they do. We don't have those tools at my job. Maybe if you are really used to those tools that is why you prefer CFC. Honestly this is the first tutorial I have found that uses CFC. Most programmers I have worked with stay away from this language and like ST, FBD and Ladder.
@@AudioJunkie79 Unfortunately, there isn’t a programming language on the earth that proscribes bad code. A large flat design is difficult to understand and debug in any language. Apparently, Beckhoff has some limitations as its possible to set breakpoints on any box and single-step through the CFC design in CODESYS.
I do agree that creating a design in a graphical language takes slightly longer, but I have never prescribed to the language-based programmers’ philosophy of “minimum keystrokes at any cost” (and “look how clever I am, I consolidated 5 lines of code into one [that no one will ever understand]”. I’m willing to spend a little more time to make something that is much easier for others to understand and enhance in the future. Also, I don’t disagree with those who say text-based languages are a holdover from the days before computers had graphic capabilities, and that graphical languages better utilize the significant portion of the human brain dedicated to understanding picture. This is why LabView and Simulink are so popular.
Take a look at this link for examples of CFC-based designs ruclips.net/video/wJYNTeAE7lk/видео.html
Awesome!