Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
I'm wondering whether it is possible to separate the PLC software and IO/HW configuration in Codesys (two separate Codesys projects)? For example in Beckhoff Twincat you can do this and it is very handy with serial products where the same configurable software can always be used but only the IO (and option parameters) change. In this case the SW can be standard and IO (and parameters) are project specific. This makes for example software updates easy when you don't have to modify the software in every project which is the case if the SW and IO are in the same Codesys project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can put your control logic in a library (i.e. using "AT %I" and "AT %Q" variables as anchor points for mapping, or whipping your own pointer-based strategy to achieve the indirection), and then use a VAR_CONFIG list to map hardware addresses to that software, or use the mapping GUI.
Out of curiosity, what method in TwinCAT are you referring to? I am very eager to find out about something I do not know, for the time being we feel TwinCAT is limited compared to CODESYS, because to my (limited) knowledge it does not support VAR_CONFIG and does not expose hardware addresses at all, forcing the GUI to be used for all mappings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Basically what I mean with the Twincat method is that when the PLC control logic (called PLC control in Twincat2) and the IO/HW configuration (called System manager in Twincat2) are separate projects you can e.g. put only the PLC control logic project in the version control and make the IO/HW configuration project "tailored" for each machine. Standard software from the version control is used to create the executable binaries which can be taken in use just by putting them into the PC's Twincat/boot folder and restarting the PC (these binaries have mapping info for the actual HW addresses which were created as part of the compilation process). This makes method, in my opinion, makes version control and software updates were easy when talking about standard SW (project specific SW is a different story).
Perhaps in Codesys you could have the project in the version control so that it does not have any IO (only "AT %I" and "AT %Q"). Then when engineering a new machine you could take this project from the version control and making the IO/HW configuration machine specific. What I'm wondering is that is it then possible e.g to make a bug fix in the version control and compile the new version for getting executable binaries and then using them for software updates of different machines that has unique IO/HW configuration? Maybe it's difficult to understand what I'm trying to explain here :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
*Perhaps in Codesys you could have the project in the version control so that it does not have any IO (only "AT %I" and "AT %Q"). *
This is exactly what I was suggesting, the "project" in your version control being a library, so that it can be referenced from the actual (machine-specific) project. This library can be pre-compiled and versioned (or not). The machine-specific project contains I/O components (fieldbuses, terminals, etc.) and the mappings. That way, if you have an update to the control logic library, you can link your (unchanged) project to the revised library, and download everything to the PLC. No I/O needs to be remapped if no "AT" addresses have been added or removed.
This is what we do. We also have a modular system where optional are separate function blocks that are simply not instantiated when not used. There are no "AT" addresses left unmapped due to unused options.
We actually have I/O libraries that are tied to a specific electrical design and know what hardware is used and how it talks to the hardware-independent control code. The mapping that needs to be done at the project level is more like linking each I/O card to raw structures in memory without needing to know about the control logic at the other end.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm also interested about this topic. I saw on beckhoff website the automation interface. It look like very interresting and powerfull. I read some Topics and I think it's possible. But I don't know if this exists in Codesys Core?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm wondering whether it is possible to separate the PLC software and IO/HW configuration in Codesys (two separate Codesys projects)? For example in Beckhoff Twincat you can do this and it is very handy with serial products where the same configurable software can always be used but only the IO (and option parameters) change. In this case the SW can be standard and IO (and parameters) are project specific. This makes for example software updates easy when you don't have to modify the software in every project which is the case if the SW and IO are in the same Codesys project.
You can put your control logic in a library (i.e. using "AT %I" and "AT %Q" variables as anchor points for mapping, or whipping your own pointer-based strategy to achieve the indirection), and then use a VAR_CONFIG list to map hardware addresses to that software, or use the mapping GUI.
Out of curiosity, what method in TwinCAT are you referring to? I am very eager to find out about something I do not know, for the time being we feel TwinCAT is limited compared to CODESYS, because to my (limited) knowledge it does not support VAR_CONFIG and does not expose hardware addresses at all, forcing the GUI to be used for all mappings.
fajean, thanks for you answer!
Basically what I mean with the Twincat method is that when the PLC control logic (called PLC control in Twincat2) and the IO/HW configuration (called System manager in Twincat2) are separate projects you can e.g. put only the PLC control logic project in the version control and make the IO/HW configuration project "tailored" for each machine. Standard software from the version control is used to create the executable binaries which can be taken in use just by putting them into the PC's Twincat/boot folder and restarting the PC (these binaries have mapping info for the actual HW addresses which were created as part of the compilation process). This makes method, in my opinion, makes version control and software updates were easy when talking about standard SW (project specific SW is a different story).
Perhaps in Codesys you could have the project in the version control so that it does not have any IO (only "AT %I" and "AT %Q"). Then when engineering a new machine you could take this project from the version control and making the IO/HW configuration machine specific. What I'm wondering is that is it then possible e.g to make a bug fix in the version control and compile the new version for getting executable binaries and then using them for software updates of different machines that has unique IO/HW configuration? Maybe it's difficult to understand what I'm trying to explain here :)
*Perhaps in Codesys you could have the project in the version control so that it does not have any IO (only "AT %I" and "AT %Q"). *
This is exactly what I was suggesting, the "project" in your version control being a library, so that it can be referenced from the actual (machine-specific) project. This library can be pre-compiled and versioned (or not). The machine-specific project contains I/O components (fieldbuses, terminals, etc.) and the mappings. That way, if you have an update to the control logic library, you can link your (unchanged) project to the revised library, and download everything to the PLC. No I/O needs to be remapped if no "AT" addresses have been added or removed.
This is what we do. We also have a modular system where optional are separate function blocks that are simply not instantiated when not used. There are no "AT" addresses left unmapped due to unused options.
We actually have I/O libraries that are tied to a specific electrical design and know what hardware is used and how it talks to the hardware-independent control code. The mapping that needs to be done at the project level is more like linking each I/O card to raw structures in memory without needing to know about the control logic at the other end.
Hi,
I'm also interested about this topic. I saw on beckhoff website the automation interface. It look like very interresting and powerfull. I read some Topics and I think it's possible. But I don't know if this exists in Codesys Core?!