Interface Design ¶ Rule #5: Design smart Interfaces ( Required ) External Interfaces require a reduced set of parameter types (e.g. no POINTER). They should be optimized for the use with CFC. They sho

Error Handling ¶ Rule #6: Implement an user friendly Error Handling ( Required ) Return only error codes which are documented within your library. Never simply return the original error code from sub

Deployment and Licensing ¶ Rule #7: Use the right method for deployment and licensing ( Required ) Deploy libraries only in compiled format (*.compiled-library). Everyone should be able to read “Proje

Templates ¶ Rule #8: Not from scratch - Use Templates ( Optional ) CODESYS provides a rich set of project templates. They are a good starting point for successful library design. See: Common Behaviour

Project Structure ¶ Rule #9: Reuse a well-known Project Structure ( Optional ) Every one find parts of the project much easier, if you use a well known project structure. In order to make orientation

Naming Conventions ¶ Rule #10: Use clean Naming Conventions ( Optional ) The consistent use of a naming convention is the best way for clean code. (Checked by the Static Code Analysis [ 3 ] ) These ru

Documentation Areas ¶ Project Information ¶ Folder ¶ Declaration Header ¶ Member Declaration ¶ Enums, Structures, GVL’s ¶ Some other possibilities to mark up the comments. Actions and Transitions ¶ Th

Formatting Commands (Overview) ¶ A reStructuredText document consists of body (or block-level elements) and it can be structured in sections. Sections are indicated by the title style (underlines and

Tool installation ¶ Note The CODESYS LibDoc Scripting Collection is now part of the CODESYS Library Documentation Support package. With this, the installing a complete Python environment is not necess

Segmented Buffers ¶ It is a constantly recurring task to fill memory areas with certain data. The following is often added as an additional requirement: Some parts always have the same content. Specia