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.
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 ua-cam.com/video/wJYNTeAE7lk/v-deo.html
Here and watching Gary! Great video, looking forward to more.
Thanks,very useful information!
Awesome!
Α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.
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
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 ua-cam.com/video/wJYNTeAE7lk/v-deo.html
Awesome!