A complete CODESYS BACnet software stack consists of the following parts:

  • runtime component CmpBACnet (which includes the BACnet stack, hereinafter referred to as BACstack)

  • IEC-library CmpBACnet - basically a IEC-61131-interface for the BACstack

  • IEC-library BACnet - application layer library containing easy to use BACnet object / property abstractions, BACnet client request abstractions and more

  • IEC-library BACnetDefaultImpl - application layer library containing “default implementations” for some aspects that are stated as “vendor-specific” or not defined in the BACnet standard.

  • BACnet device descriptions - foundation for CODESYS BACnet configurator integrated in the BACnet-plugin

  • BACnet-plugin - providing the BACnet configurator, consistency checks for library versions, BACnet object identification and network numbers as well as EDE export/import

  • BACnet_examples.project and related example projects covering lots of practical aspects in applications

All those parts - except runtime component CmpBACnet - are contained in the CODESYS BACnet package. For more detailed information regarding the IEC-libraries please refer to the library documentation.

CODESYS BACnet(1) did provide BACnet protocol revision 14/15. As with CODESYS BACnet version 2.0.0.0 (hereinafter referred to as CODESYS BACnet2) there was a major jump to BACnet protocol revision 25. With this jump in BACnet protocol revision there are changes in the BACnet-Standard which alone would require application code changes - please see documentation section “migration” for details. Additionally changing the BACnet protocol revision of an already certified BACnet device is not for free regarding the BACnet certificate - there is a need to do BTL conformance testing and certification again, so in fact it turns out to be kind of a brand new BACnet device.

To allow customers to run either CODESYS BACnet(1) or CODESYS BACnet2 applications the two software stacks had been separated. So CODESYS BACnet2 parts do have a different name and / or version than their CODESYS BACnet(1) predecessor and all parts of the both software stacks are shipped with the CODESYS BACnet package (from version 2.0.0.0). Only exception of this rule is the BACnet-plugin - there is just one BACnet-plugin which can be used to work with CODESYS BACnet(1) as well as with CODESYS BACnet2.

CODESYS BACnet(1) vs. CODESYS BACnet2 artefact names and versions

  • runtime components CmpBACnet vs. CmpBACnet2

  • IEC-libraries CmpBACnet.compiled-library-v3 vs. CmpBACnet2.compiled-library-v3

  • IEC-libraries BACnet.compiled-library-v3 (version 1.7.x.x) vs. BACnet2.compiled-library-v3 (version 2.x.x.x)

  • IEC-libraries BACnetDefaultImpl.compiled-library-v3 (version 1.7.x.x) vs. BACnet2DefaultImpl.compiled-library-v3 (version 2.x.x.x)

  • IEC-source-libraries BACnetDefaultImpl.library (version 1.7.x.x) vs. BACnet2DefaultImpl.library (version 2.x.x.x)

  • BACnet device descriptions for example BACnetAnalogValue.devdesc.xml (version 1.7.x.x) vs. BACnet2AnalogValue.devdesc.xml (version 2.x.x.x)

  • example projects BACnet_examples.project vs. BACnet2_examples.project

The BACnet-plugin can be used for both CODESYS BACnet(1) and CODESYS BACnet2 development activities.

functionality of the parts

The CmpBACnet2.compiled-library-v3 provides the following aspects:

  • IEC-61131 language interface of the BACnet stack:

    • BACnet stack data types mapped to IEC-61131-DUTs (ENUM, TYPEDEF, STRUCT, UNION)

    • BACnet stack functions mapped to IEC-61131-FUNCTIONs

  • a mechanism to map BACnet stack (function pointer) callbacks to the CODESYS event mechanism

So in fact it is a very low-level API to BACnet functionality and foundation for the BACnet2.library

The BACnet2.compiled-library-v3 is the high level application programming interface of CODESYS BACnet2 and provides the following aspects:

  • function block representations of BACnet objects like BACnetAnalogValue

  • function block representations of BACnet client operations like BACnetClientReadProperty

  • support for BACnetServerPlugin(s) IBACnetServerPlugin which enables flexible implementation options for user specific behaviour

  • application side event dispatching - see IBACnetEventConsumer

  • foundation for BACnet object property configuration regarding existance, writablity and persistence

  • foundation for BACnet persistence

Since the BACnet2.compiled-library-v3 is high level application programming interface it should used instead of directly accessing the runtime component via the CmpBACnet2.compiled-library-v3. There are some sensible exceptions from this rule, please refer to the CODESYS BACnet2 online documentation chapter “When to Use the BACnet Library or the CmpBACnet Library” https://content.helpme-codesys.com/en/CODESYS%20BACnet/_bacnet_when_to_use_bacnetlib_cmpbacnetlib.html.

The BACnet2DefaultImpl..compiled-library-v3 contains so called default implementations to further reduce the effort for PLC vendors and application programmers. Each of those default implementations covers one ore more aspects that are stated as vendor specific or are not defined completely in the BACnet-Standard. Those implementations are based on assumptions / definitions of use cases / constraints set by CODESYS. The BACnet2DefaultImpl..compiled-library-v3 makes specific assumptions documented at each item in the library. In case those assumptions could not be fulfilled by a specific PLC, BACnet2DefaultImpl.library could be used as an example for a more specific implementation - it is provided with source code for this reason. For more details please refer to the library documentation.

The BACnet device descriptions form the foundation for CODESYS BACnet2 configurator.

The BACnet-plugin does some consistency checks (library versions, InstanceNumber/InstanceName, check routing network number) and the EDE-export/import.

BACnet MS/TP

CODESYS BACnet2 supports the BACnet/IP protocol only. It is possible to extend CODESYS BACnet2 to additionally support the BACnet MS/TP protocol. The MS/TP protocol defines really harsh timing constraints. So an UART specific MS/TP device driver is inevitable - more generic UART devices (for example USB-connected UARTs) can’t be used. Such a hardware specific MS/TP device driver is not (and can’t be in the future) part of CODESYS BACnet2.