I/O automapping
TwinCAT BACnet/IP supports automated mapping of the modular IO systems K-bus and EtherCAT to BACnet. For each I/O channel a corresponding BACnet object of type BinaryInput, BinaryOutput, AnalogInput or AnalogOutput is configured automatically, process data are linked accordingly through Device2Device mapping, and the status of the I/O systems is transferred to the BACnet properties Reliability and StatusFlags, if applicable.
During mapping of I/O systems a distinction is made between I/O busses that consolidate several I/O modules and abstract an I/O strand in each case. By assigning IoBusNr BACnet I/O objects are allocated to an I/O bus, via which the status is mapped, for example. If, for example, a K-bus strand is linked, the process data BusState can be used to detect whether the K-bus is ready for operation, and the property Reliability of all BACnet objects with the respective IoBusNr can be adjusted to the value NO_FAULT_DETECTED, otherwise NO_SENSOR or NO_OUTPUT. With TwinCAT BACnet/IP the I/O busses can also be linked to a K-bus, e.g. a BK9000, or further EtherCAT strands can be linked with a BACnet controller.
I/O bus automapping can be triggered via the "Settings" tab of a BACnet server. In the corresponding dialog box, an I/O bus can be selected and the link can then be initiated via "Map" button:
The following I/O bus types are currently supported:
- EtherCAT
- BK1120, BK1250
- K-BUS: CX1100-BK, CX5000-BK, CX-8000-BK
- BK9000, BK9100, BK9050
In general, during I/O automapping the System Manager analyses all terminals under an I/O bus, creates corresponding BACnet objects and links process data. As an example, the figure shows how a digital output terminal (KL2114) at a CX9001-KBus is mapped to BACnet. The BACnet object "Terminal 2 (KL2114)_Chn1" of type BinaryOutput was created, and the output process data variable "Output" was linked with the BACnet process data variable "RawIoBinaryValue". This link ensures that the status of the digital output signal always matches the PresentValue of the BACnet object, if the object is not OutOfService. The polarity of the "BinaryOutput" is also considered. For further details please refer to section "Process data".
Automapping can be configured via an associated dialog, and the user can specify whether the bus status should be monitored automatically, or whether the process data can be linked automatically. In addition, the object ID allocation algorithm of the created BACnet objects can be specified. The following options are available:
- "Use next available object identifier" - For each new BACnet object the next free object ID for the respective object type is used, starting from 0.
- Module-based ID allocation - Based on a start ID the object ID for each new I/O module is incremented by a "Module increment". This can be used to ensure that the BACnet object ID can always be used to determine which terminal was linked. Example: With a start ID of 1000 and a module increment of 10, a BinaryInput object with ID 1113 is allocated to the third binary input channel of the eleventh terminal.
The other configuration options of I/O automapping are explained below:
- "Create StructuredView object for mapping" - All BACnet objects generated for I/O mapping are created below a newly generated StructuredView object, to increase the transparency within a project
- "Default Resolution" - Analog objects have a BACnet property resolution, which determines the scaling of I/O process data for the PresentValue of the BACnet object and vice versa. The parameter configured here is entered for all generated analog objects. To use the original hardware values, a resolution value of 0 should be set.
- "Link raw PresentValue" - To link the PresentValue of the BACnet objects with the I/O modules, the corresponding RawIoPresentValue properties of the BACnet objects must be activated and linked. This can be activated with this option.
- "Link Status Byte" - Analog input terminals can use a status byte to indicate whether the respective process data value is valid or whether a limit was exceeded, or a wire is broken, for example. If this option is activated, for analog input terminals (KX3XXX, EL3XXX) the data status of the terminal is linked with the BACnet I/O property "RawIoStatus". With EtherCAT the variables "Underrange" and "Overrange" are linked bitbased. If the corresponding status bits are set, the reliability is formed as follows during runtime:
- If bit 0 is set, Reliability is UNDER_RANGE
- Otherwise, Reliability is OVER_RANGE, if bit 1 is set
- Otherwise, Reliability is UNRELIABLE_OTHER, if bit 6 is set
- "Link coupler-/box state" - In a K-bus or Bus Couplers (BK9000) the process data BusState/couplerState and "BoxState" can be used to determine the communication and operating state of all terminals of the bus. Monitoring of the couplerState is realised centrally via the BACnet server. If this option is activated, available BusState/couplerState or "BoxState" are linked with the IoBusState process data of the BACnet server with the respective IoBusNr. The BusState of a K-bus is linked with the couplerState. If couplerState or "BoxState" for an I/O bus in the BACnet server is not equal 0, the reliability of all objects under the server with the corresponding IoBusNr is set to the value NO_SENSOR for input objects or NO_OUTPUT for output objects, provided the objects are not OutOfService.
- "Link EtherCAT state" - For EtherCAT, a mechanism similar to Coupler/Box state for K-bus is available. In contrast to the K-bus, with EtherCAT the state of each terminal can be determined, which could enable disconnected terminals to be detected. With EtherCAT the status identification is therefore not realised centrally via the server, but takes place in each object by linking the process data property "RawIoECATState". Is the value of "RawIoECATState" is not equal 8 (OP), the reliability of the object is set to the value NO_SENSOR for input objects or NO_OUTPUT for output objects, provided the objects are not OutOfService.
- "Link Wc state" - Monitoring of the EtherCAT Wc state is currently not supported.
- "Link Status Override" - For terminals with manual operating mode the respective manual operation status can be mapped in BACnet to the StatusFlags via the override bit. For the terminals KM4602 and KM2652 a link with the process data property "RawIoStateOverride" is generated, if this option is activated.
Automatic mapping of EtherCAT and K-bus devices to BACnet objects is not always possible. In certain cases, and with complex terminals it is in not always clear whether a BACnet object should be created for process data, or which BACnet object should be created. For many basic input/output terminals the mapping is based on the following algorithm:
- For all 1-series modules (KX-1XXX, EL-1XXX) a BACnet BinaryInput object is created for all input variables of type BIT that are found and the input data is linked if the variable name is not equal "WcState" or "InputToggle".
- For all 2-series modules (KX-2XXX, EL-2XXX) a BACnet BinaryOutput object is created for all output variables of type BIT that are found, and the process data is linked.
- For all 3-series modules (KX-3XXX, EL-3XXX) a BACnet AnalogInput object is created for all input variables of type INT16 that are found, and the process data is linked.
- For all 4-series modules (KX-4XXX, EL-4XXX) a BACnet AnalogOutput object is created for all output variables of type INT16 that are found, and the process data is linked.
The following terminals are treated in a special way:
- KL1859 - 8 BinaryInput and 8 BinaryOutput BACnet objects are created.
With automapping the following BACnet properties are configured automatically:
- ObjectIdentifier - is determined by the object ID allocation algorithm
- ObjectName - is formed from the terminal name plus "_ChnX" for the channel number
- IoBusNr - is incremented with each I/O automapping, starting from 0
- IoModuleNr - indicates the number of the linked terminal, starting from 1
- IoChannelNr - indicates the channel, starting from 1
- Resolution - as specified in the configuration dialog