Implementation

Implementation language

There are two obvious implementation languages to choose from the CODESYS / IEC-61131 language set: ST and CFC. Implementations of functionality in level 1 and 2 is most likely to be done best in ST, while often implementations of functionality in level 3 is best done in ST. Computation of physics and simple algorithm might most obviously benefit from implementation in ST.

There is an important design goal for the CODESYS Building Automation library: easy to understand and intuitive to use. In addition, the CODESYS Building Automation library is intended as a development template and not as a mature product. Therefore, understanding a function block and copying or modifying it to your own needs is essential. For this reason, it is most likely a good choice to select CFC as the implementation language from level 4 (possibly 3) to 6.

Implementation rules

There are some rules with which all functionality in the CODESYS Building Automation library should stick completetly:

General implementation rules:

  • The “Common Behaviour Model” should be used wherever appropriate (see https://help.codesys.com/webapp/idx-CommonBehaviourModel-lib;product=CommonBehaviourModel).

  • Function blocks related to time (axis) must provide an INPUT itfDateTimeProvider (Util.IDateTimeProvider) (see examples).

  • In case the function block can fail somehow, there is an OUTPUT xError (error indication) and eErrorID (error ID). Both error indication and error ID will be reset by xEnable := FALSE or by xReset := TRUE (if it exists). In case of error situations, control outputs will be set to suitable values.

  • Function blocks which implement an interface (for example, |ValveThermo| implementing |IValveContinuous|) provide an output itf* (example: itfValveContinuous). This is about to support usability of the function block in CFC.

More specific implementation rules for actuators and aggregates:

  • Actuators and aggregates must provide an INPUT xEnable (BOOL) and work accordingly.

  • Actuators and aggregates most likely provide the OUTPUTs xError and eErrorID.

  • Actuators and aggregates sometimes work with “service indications” (quite often feedback values from the real hardware).

    • “Service indications” INPUTs are implemented as a tuple of two BOOL, for example xSvciWhatEver : BOOL; xSvciWhatEver_Used : BOOL; // xSvciWhatEver_Used indicating if xSvciWhatEver is relevant, used, or connected.

    • “Service indications” have a name prefix “Svci”.

  • Actuators and aggregates sometimes work with “error indications” (error signals from the physical hardware).

    • “Error indications” INPUTs are implemented as one BOOL, for example xErriWhatEver : BOOL;

    • “Error indications” have a name prefix “Erri”.

  • Actuator and aggregates which detect hardware errors (via “error indication” inputs or “command execution monitoring” utilizing “service indications”) optionally allow to hold the hardware error (“malfunction lock”) and shutdown the device (if appropriate) until error is reset