This documentation is open to be edited by all CODESYS Forge developers. It can be used to share global information, which is of interest for developers of differnt projects.
The contents is not ment dogmatic and should provide the reader with enough tips & tricks to help write code which is clearly readable and quicker understood by the community. The developper adhering to these tips & tricks, in return, will reap the benefits in an obvious manner. So, following tips & tricks is strongly encouraged!
Use the CODESYS programming system in the latest version. It's use is completely free.
You can the program every CODESYS programmable PLC with it, or use the 2h Demo of one of the SL runtimes:
The demos are running 2h and can be restarted as often as you want.
You should use SVN when you want to have a good version control system with CODESYS projects, and if you want to publish them on CODESYS Forge.
CODESYS SVN can be freely used with CODESYS Forge. But we reconnend to use the tool cforge, as it improves the workflow with CODESYS Forge pretty much.
When it comes to library compatibility, the rule is really as easy as that:
"The CODESYS version of the user should be greater or equal to the format of the library."
Things like the compiler version, visu profile, etc. will usually be used from the final project, not from the library.
Offcourse there are some known exceptions;
* ;
* ;
* etc
The following version scheme suggestion is empirical in nature;
v0.0.0.1 Initial version: Your first library / project in beta stage
whenever you code or bugfix just arbitrarily count up as you see fit, there is no right or wrong;
v0.0.0.2 Bugfixes/coding version 2
..
v0.0.0.49 Bugfixes/coding version 49
etc, etc.
whenever you have tested a complete stable internal version;
v0.0.1.0 your first stable version (tested)
..
v0.0.1.3 your first stable version (tested) with some bugfixes
..
v0.0.2.0 your second stable version (tested)
..
v0.0.3.11 your third stable version (tested) with more bugfixes
etc, etc.
whenever you have software which you have tested externally (public beta);
v0.1.0.0 your first public beta version (tested/ publicly released)
..
v0.1.0.2 your first public beta version (tested/ publicly released) with some bug fixes
..
v0.2.0.0 your second public beta version (tested/ publicly released)
etc, etc.
Whenever you have a stable public alpha release;
v1.0.0.0 Your first alpha released version
..
v1.0.0.6 Your first alpha released version with some bugfixes
..
v1.1.0.9 An alpha released version with a beta tested/released component and some bugfixes
..
v2.0.0.0 Your second alpha released version
etc, etc.
As seen, this versioning scheme leaves "room" for (arbitrarily) smaller or larger code updates while also providing a clear overview of the development progress.
Offcourse, other versioning scheme's are possible (provide examples).