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!
You can the program every CODESYS programmable PLC with it, or use the 2h Demo of one of the SL runtimes:
CODESYS Control Win V3
CODESYS Control for Raspberry Pi SL
CODESYS Control for Linux SL
The demos are running 2h and can be restarted as often as you want.
Version Control System
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; ; ;
Versioning of own items
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
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
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)
Whenever you have a stable public alpha release;
v22.214.171.124 Your first alpha released version
v126.96.36.199 Your first alpha released version with some bugfixes
v188.8.131.52 An alpha released version with a beta tested/released component and some bugfixes
v184.108.40.206 Your second alpha released version
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).
when using RTS_IEC_HANDLE and RTS_IEC_RESULT types, please add SysTypes2 Interfaces (220.127.116.11);
if possible, use standard error codes (CmpErrors or CmpErrors2 Interfaces);
if possible, avoid using dynamic memory (the usage of NEW operator);
always use Structured Text (ST) language whenever possible as ST is by far the most versatile language, in which all operations, manipulations and functions are possible;
document the source code, add meaningful comments to it;
for modern coding style advice: read the CODESYS v3 library development tips as provided in CODESYS help,
The tips and practices laid out in the CODESYS help are pretty complete but not as thorough as Steve McConnell "Code Complete", though they provide a very good starting point.
For further reading see e.g. Steve McConnell "Code Complete";
The following is a list of some greate resources about some more advanced programming techniques.