Process data
This section describes the process data variables of the individual TwinCAT BACnet/IP elements. In general, process data of a BACnet/IP device are linked with the PLC and a fieldbus via asynchronous mapping. This is necessary since BACnet has acyclic characteristics, and certain services may trigger many changes in other BACnet properties and therefore the sending of many BACnet Ethernet frames. Asynchronous mapping is used to prevent links with BACnet process data resulting in cycle time violations in the PLC or watchdog timeouts of the fieldbuses. It means that BACnet, PLC and fieldbus tasks run independent of each other.
Linking to a task takes place under the BACnet device via the Settings tab and "Task Configuration". This is where a task can be selected. The selection dialog shows all tasks with a port greater than 350. The bottom left of the screenshot shows a PLC task ("BACnet_Demo") that is linked asynchronously with the BACnet task, which by default is created with priority 58 when a BACnet object is added.
BACnet Device
| Under a BACnet device the process data variables are the Device Status, which includes the link status of the linked Ethernet adapter, and the state of the internal state machine. The device status is explained in the following table. In addition the AmsNetID of the BACnet device can be linked with a PLC that accesses BACnet functions via ADS. |
Bit | Description |
|---|---|
0 | Ethernet link status: Represents the current link status of the linked Ethernet adapter:
|
1 | Gateway status: represents the current status of the IP gateway:
|
8 - 15 | Device State Machine: Reflects the state of the internal BACnet device state machine:
|
BACnet Server
| The ServerStatus contains among other things the current state of the internal server state machine. The server status from a BACnet view can be determined with the help of the property SystemStatus, which can be linked cyclically. The state of an I/O link can be monitored centrally via the IoBusState process data variables. When linking a K-bus or a BK9000, for example, CouplerState or BoxState maps the state of several I/O modules. Fieldbuses that are linked with BACnet via I/O automapping can map Reliability automatically with the aid of these process data. Each fieldbus strand is allocated an IoBusNr, which is also a vendor-specific BACnet property. If the value of the process data variable couplerState or BoxState is not equal 0, all relevant (I/O) BACnet objects of the server with the corresponding IoBusNr are notified, and the Reliability is set to NO_SERVER or NO_OUTPUT. By default 8 IO buses are available. |
BACnet Server Status
Bit | Description |
|---|---|
2 | WriteOnChange disabled: WriteOnChange is disabled via the server control bit. |
8 - 15 | BACnet Server Statemachine: Reflects the state of the internal BACnet server state machine:
|
BACnet Server Control
Bit | Description |
|---|---|
0 | Backup PLC feedback Enable: When backing up data generated by the PLC through a BACnet backup, this bit ensures that the PLC initially has write access to the backup-relevant files (configuration files). If this bit is set, the BACnet stack waits for bit 1 of the server control word being set before acknowledging the backup request. If this bit is not set, the BACnet stack omits this handshake procedure. Further information on backup and restore can be found in the corresponding chapter of this documentation. |
1 | Backup PLC feedback Complete: Once the backup-relevant PLC data were backed up, this bit instructs the BACnet stack to continue with the backup. |
2 | Disable WriteOnChange: Disables writing of cyclic process data. Can be used by the PLC to reset the writing process data without manipulating BACnet |
3 | Elapse IO startup timeout: At system startup, process data in the BACnet stack are only processed once the IO startup time has elapsed. This is configured as advanced parameter and is set to 2000 ms by default. It enables the PLC to prepare writing process data for BACnet before potential error messages are sent to the BACnet network. For faster startup, the PLC can reduce this time by setting this bit to 1. TcBACnet.lib uses this functionality automatically. |
BACnet Client
| In addition to monitoring the client status, the SystemStatus of the device object of the client should always be activated as process data. Since errors in the client communication are only shown in the client status if errors in the communication occur, regular communication should be ensured. To this end it is advisable to read or poll the property SystemStatus cyclically (with a suitably low cycle time). The process data SystemStatus is a enumeration with the name BACnetDeviceStatus and is defined in the BACnet standard. BACnet makes provision for the following values:
|
BACnet Client Status
Bit | Description |
|---|---|
0 | Client TimeOut: A timeout has occurred in a BACnet service request. |
1 | Client Service Failure: A service with the configured client could not be carried out successfully. This error bit is set if:
|
2 | Client WriteOnChange State: Activation control for WriteOnChange, which is specified under client control.
|
3 | Client COV Subscription Control State: Displays the state of the COV subscription control. If the Client COV Subscription Control bit is set, this bit is set to 1 when the COV subscription data structures were reset. If the Client COV Subscription Control bit is not set, the state is 0. This bit does not indicate whether all COV subscriptions were completed successfully, it only indicates that all COV subscription will be executed again in future. |
4 | Client Force Output Update State: Force Output Update is active. |
8 - 15 | Client Remote State: Reflects the state of the internal client state machine:
|
BACnet Client Control
Bit | Description |
|---|---|
0 | Client TimeOut Reset: Reset the Client-TimeOut bit in the client status. |
1 | Client Service Failure Reset: Reset the service failure bit in the client status. |
2 | Client WriteOnChange Control: Activation control for WriteOnChange. WriteOnChange is disabled if the corresponding bit is set in client status.
|
3 | Client COV Subscription Control: Resets the status of the COV subscriptions and triggers the new registration of COV subscriptions. The internal data structures are reset once (which triggers the COV subscriptions) if a change of value 0 -> 1 is detected. |
4 | Client Force Output Update State: When the value changes from 0 to 1, at the next possible point in time all writing process data on a BACnet client are updated. This feature can be used to ensure that values for the whole cross communication are applied on a remote station, without overwriting by a different device in the meantime. |
Notification Sink
| The TwinCAT BACnet/IP notification sink enables the receipt of COV and event notifications. The number of received notifications can be determined via the process data CovNotifications and EventNotifications. Notifications can be deleted and read via the ADS interface of the notification sink. |
BACnet objects - properties as process data
Properties with non-complex data types (Signed Integer, Unsigned Integer, BitField, Boolean, Real, Enumerated) can be configured as cyclic process data. In the property process data a distinction has to be made between objects under a server (local objects) and objects under a client (remote objects).
- The properties of local objects are configured under a BACnet server. The dialog "Cyclic Data" can be used to configure which properties are linked as process data. Connectable properties appear under an object as process data variables and can be linked with variables of a PLC or with other I/O devices (e.g. EtherCAT terminals or K-bus terminals). Properties can be activated as a reading or writing process data:
- Output data ("PLC/IO -> BACnet") are data that are copied from a PLC into a BACnet object. They are shown as red variables.
- Input data ("BACnet -> PLC/IO"), shown in yellow, are copied from BACnet to the PLC. These include the StatusFlags of an object, which can be processed in the PLC.
For remote objects, the properties of a remote device can also be made available as cyclic process data. The data of the properties can either be transferred acyclically via COV (Change of Value) or cyclically at a fixed interval. In remote objects data that are consumed by a PLC are shown in yellow, produced data in red.
The schematic diagram illustrates the application of process data in client and server objects. The example shows a BinaryOutput object created on a server. The property PresentValue is linked as a process data variable. The PresentValue implemented as RawInBinaryBoolValue can be used in a PLC on the server in order to influence a functionality in a PLC program, for example, or it can be linked with an EtherCAT/K-bus terminal to activate lighting, for example. In this case, RawInBinaryBoolValue is a yellow PLC input variable on the server side. On a second device the object is configured as a remote object. In this example the value of PresentValue of the server object is to be changed with the aid of a PLC on the client. To this end the PresentValue is mapped as a red output variable on the client and can be linked with the PLC.
The following table shows the relationship between BACnet data types and PLC data types:
BACnet data type | PLC data type |
|---|---|
Boolean | BOOL |
Unsigned Integer | UDINT |
Signed Integer | DINT |
Real | REAL |
Double | not used |
Bit string ( StatusFlags, EventEnable, LimitEnable etc. ) | WORD (For bit strings it should be noted that the lowest-order byte is used to display the number of unused bits of the highest-order byte. An example is 0xE005 of an EventEnable property: 5 indicates that 3 bits are used in the highest-order byte [to_offnormal, to_fault, to_normal]. 0xE0 indicates that all 3 bits are TRUE. If a bit string property is written cyclically from the PLC to BACnet, these bits have to be coded accordingly. Valid values can be found in the Online tab of the BACnet objects.) |
Enumerated (EventState, Reliability, Polarity, BinaryPV etc.) | WORD |
Process data of local objects
For local objects, (writing) process data are generally written once on system startup and subsequently when a change occurs. This means that potentially the value written by the PLC and the value of the described property can differ. Among other things because e.g. via BACnet or ADS another 'actor' has changed the value. For writing process data it is therefore advisable to implement feedback in the PLC. This behavior was modified compared with the implementation in Revision 6, where all properties were written in each cycle. An exception are the Raw* properties, which are written in each cycle.
Commandable properties
BACnet offers the option to control certain (commandable) properties via a priority mechanism. In this case, the value of the property PresentValue of the objects BO, BO, AO, AV, MV and MO is controlled via the entries of the property PriorityArray. The different entries correspond to different importance and can be written by different 'actors' in the BACnet network. With TwinCAT BACnet/IP, the PLC can write entries in the PriorityArray. To this end, a priority level can be selected in the tab "Cyclic Data" for writing the property PresentValue (the values are then copied internally to the property PriorityArray).
To activate a lower priority level, a priority level with the value NULL can be written (enabled).
- From the PLC this is possible for BinaryOuput/Value objects. If a value not equal 0/1 is written to the PresentValue of a linked priority level of a BinaryValue or BinaryOutput object, the value ZERO is copied to the PriorityArray.
- For AnalogOutput/Value objects the value ZERO is assumed in the PriorityArray, if the special coding of REAL values NaN (not a number) is used as process data. For server objects NULL is also written if the REAL value of the process data variable is outside the Min/MaxPresValue range.
- In MultistateOuput/Value objects the value NULL is assumed in the PriorityArray, if 0 is written as process data. For server objects NULL is also assumed if the process data takes on a value greater than NumberOfStates.
For each BACnet object, several priority levels can be written simultaneously by the PLC.
RawIoProperties
Process data properties from this category are used for linking of BACnet objects with I/O modules and PLC variables. These properties do not directly represent properties that are visible in BACnet, but they act on standardized properties of the corresponding objects or are formed from them. The general rule for RawIo properties is that the BACnet property OutOfService takes effect. An object is then referred to as OutOfService, since the BACnet property OutOfService has the value TRUE.
Property | Description |
|---|---|
RawIoSignedValue | Signed 16-bit value (INT) used for analog* objects. If an AnalogInput object is not OutOfService, the value of this process data variable forms the value of PresentValue. The value of RawIoSignedValue is converted to a REAL data type, the result is multiplied with the property Resolution and then added to the property ScaleOffset. For AnalogOutput objects the value of RawIoSignedValue is formed from PresentValue based on the inverse procedure. If the value of the PresentValue exceeds the value range of the data type INT (-32768 to 32767), RawIoSignedValue has the value 0. If an object is OutOfService, depending on the configuration of the properties FaultFallbackValue or OutOfServiceFallbackValue, the last value remains or the configured value is used. |
RawIoUnsingedValue | Unsigned 16-bit value (UINT) that is used for analog* objects. If an AnalogInput object is not OutOfService, the value of this process data variable forms the value of PresentValue. The value of RawIoSignedValue is converted to a REAL data type, the result is multiplied with the property Resolution and then added to the property ScaleOffset. For AnalogOutput objects the value of RawIoSignedValue is formed from PresentValue based on the inverse procedure. If the value of the PresentValue exceeds the value range of the data type UINT (0 to 65535), RawIoSignedValue has the value 0. If an object is OutOfService, depending on the configuration of the properties FaultFallbackValue or OutOfServiceFallbackValue, the last value remains or the configured value is used. |
RawIoBinaryEnumValue | Enumeration type (in the PLC processed as WORD) that is used for binary* objects. Applies if OutOfService is not TRUE. For BinaryOutput objects the value of the property RawIoBinaryEnumValue is formed as follows:
If OutOfService is TRUE, for BinaryOutput objects the property RawIoBinaryEnumValue assumes the value of the property OutOfServiceFallbackValue if this is activated, otherwise the last valid value is maintained. For BinaryInput objects the PresentValue is formed from the property RawIoBinaryEnumValue.
If OutOfService is TRUE, PresentValue always assumes the value of FaultFallbackValue if this is active, otherwise PresentValue assumes the last value when OutOfService was FALSE. |
RawIoBinaryBoolValue | Binary value (BOOL) that is used for binary* objects. The property PresentValue of the binary* objects in BACnet is an enumeration type. The property RawIoBinaryBoolValue was introduced to optimize the handling of binary objects. It can be used instead of RawIoBinaryEnumValue. For BinaryOutput objects the value of the property RawIoBinaryBoolValue is formed as follows:
If OutOfService is TRUE, for BinaryOutput objects the property RawIoBinaryEnumValue assumes the value of the property OutOfServiceFallbackValue if this is activated, otherwise the last valid value is maintained. For BinaryInput objects the PresentValue is formed from the property RawIoBinaryBoolValue.
If OutOfService is TRUE, PresentValue always assumes the value of FaultFallbackValue if this is active, otherwise PresentValue assumes the last value when OutOfService was FALSE. |
RawIoStatus | Analog input modules can have a process data that indicates the state of the physical connection (e.g. wire break detection, range violation). If the property RawIoStatus (data type USINT) is active, it influences the property Reliability. The property Reliability is formed from RawIoStatus if the object is not OutOfService, no IoBus error is pending (see RawIoECATState, IoBusState) and no status override is active, (see RawIoStateOverride*) as follows:
|
RawIoECATState | EtherCAT modules have an operation status that maps the current operating state. BACnet objects that are linked with EtherCAT modules can form their Reliability via this operation status. RawIoECATState enables unplugged modules (module plug) and partial bus failures to be detected and mapped to BACnet. The property Reliability is formed as follows from RawIoECATState if the object is not OutOfService:
|
RawIoWcState | WcState monitoring is currently not supported. |
RawIoStateOverride | Some I/O modules have a mechanical manual mode for overriding the fieldbus process data locally. Manual override can be mapped in BACnet via the property StatusFlags with the bit OVERRIDE. If the process data variable RawIoStateOverride is TRUE, in the allocated BACnet object the bit OVERRIDE is set in the property StatusFlags, otherwise not, when the BACnet object is not OutOfService. |
RawIoStateOverrideInverted | Some I/O modules have a mechanical manual mode for overriding the fieldbus process data locally. Manual override can be mapped in BACnet via the property StatusFlags with the bit OVERRIDE. If the process data variable RawIoStateOverride is FALSE, in the allocated BACnet object the bit OVERRIDE is set in the property StatusFlags, otherwise not, when the BACnet object is not OutOfService. Examples for using RawIoStatusOverrideInverted can be found in modules KM2642 and KM4602. |
RawIoAccumulatorUnsignedValue | RawIoAccumulatorUnsignedValue enables acquisition of count values via a 16-bit process data variable. This can be linked to a KL5101, for example, or counting pulses can be specified by the PLC. The BACnet stack performs a rotation detection at 32767. In other words, two pulses are counted (after 0 and after 1) during the transition from 32767 to 1. To protect against data loss when the PLC is stopped, no operations are carried out when the current value is 0. Only with a new value of 1 would accumulation continue accordingly. |
RawIoPulseConverterUnsignedValue | RawIoPulseConverterUnsignedValue has the same mode of operation as RawIoAccumulatorUnsignedValue. Integration mode is not supported for the PulseConverter object. |
Special data versions of PresentValue
Property | Description |
|---|---|
PresentValueBool | Schedule object: If the PresentValue of a schedule object of the BACnet data type is Boolean, the process data property PresentValueBool reflects the current value of the property PresentValue. Binary* objects: In BACnet the property PresentValue of binary* objects is of data type BinaryPV and therefore an enumeration. The corresponding PresentValue process data is therefore of data type WORD, since enumerations are processed in the PLC as 16-bit values. As an optimized version the process data PresentValueBool of data type BOOL can be used. PresentValueBool is TRUE if PresentValue is ACTIVE and FALSE if PresentValue is INACTIVE. |
PresentValueEnumerated | If the PresentValue of a schedule object is a BACnet enumeration, the process data property PresentValueEnumerated reflects the current value of the property PresentValue. |
PresentValueReal | If the PresentValue of a schedule object is of BACnet data type Real, the process data property PresentValueBool reflects the current value of the property PresentValue. |
PresentValueSigned | If the PresentValue of a schedule object is of BACnet data type SignedInteger, the process data property PresentValueBool reflects the current value of the property PresentValue. |
PresentValueUnsigned | If the PresentValue of a schedule object is of BACnet data type UnsignedInteger, the process data property PresentValueBool reflects the current value of the property PresentValue. |
Remote process data
For remote objects, data have to be transferred to the remote BACnet server (with the aid of the BACnet WriteProperty service). TwinCAT BACnet/IP offers two data transfer options. Data can be written "On Change", i.e. when changes occur. During processing of the process data within TwinCAT BACnet/IP, write access to the corresponding BACnet property is triggered if a change in the process data is detected. This procedure is equivalent to the processing of local objects. As a second option the data can be written cyclically. If "Write On Change" is active the data are written once when a change occurs. If another BACnet device subsequently overrides the value, the value of the client PLC may differ from the property value. It may be advisable to feed the BACnet properties back as input variable. With "Write On Change" data are transferred at most with the set cycle time. The dialog "Cyclic Out Data" can be used to configure writing process data for remote objects:
For commandable properties a priority can be selected for the write access. This priority is then transferred in the WriteProperty request.
A special case for writing remote process data is an automatic locking when the PLC stops. If Bit3 (ElapseIoActiveTime) in the BACnet server control word changes from 1 to 0, the DisableWriteOnChange function is automatically activated for each BACnet client. Writing of remote process data can only recommence once this bit has been set to 1 again. This protective logic is required to prevent flooding of the BACnet network with "0" if the PLC stops.
Reading process data of remote BACnet objects are configured via the tab "Cyclic In Data". This dialog can be used to select as a basic configuration whether data are transferred when changes occur (COV) or cyclically. In addition, the interval for new subscriptions to change messages (Resubscription interval) can be specified. For properties with floating-point values, the COV increment can be used to specify the "resolution" at which data are to be transferred. CycleTime defines the period for reading cyclic data.
BACnet supports two services for transferring change messages. The service COV-P enables transfer of changes of all properties. In addition, a COV increment per Subscription can be specified for properties with floating point values. The service COV only allows the transfer of specially specified properties for selected objects (e.g. PresentValue, StatusFlags). COV is supported by a wide range of manufacturers; COV-P only by a few. To achieve maximum compatibility, the COV service should be used whenever possible.
COV-P is used if:
- a property is not supported by COV (e.g. EventState)
- a COV increment other than 0.0 was entered
The TwinCAT BACnet/IP stack in Revision 12 supports extensive further modes for process data transfer of remote BACnet objects. These transfer modes cannot be configured in the "Cyclic In Data" tab, since they always affect several BACnet properties at the same time. Some of the modes shown in the following table can only be activated via PLC automapping or with the Process Data wizard.
Requirements
Transmission type | Description |
|---|---|
Unconfirmed COV | This mode is activated in the "Cyclic In Data" dialog. Property values are sent as unconfirmed change messages (UnconfirmedCOV). In other words, the sender does not ensure that the data is actually delivered. In order to be able to use this mode, the remote station must support the service COV or COV-P for the activated property. This mode can be used in reliable networks. |
Confirmed COV | In this mode change messages are delivered confirmed (ConfirmedCOV). After submitting a change message, the sender waits for the configured APDU timeout (device object). If the change message is not confirmed, the message is sent again until the number of APDURetries is reached (device object). In order to be able to use this mode, the remote station must support the service COV or COV-P for the activated property. This mode should be use in networks with temporary overload, or in cases where confirmation is required that change messages were delivered. Note that the maximum number of simultaneous changes that can be transferred to the remote station is 255. |
Unsolicited COV | In modes Unconfirmed COV and Confirmed COV, changes are subscribed to via the SubscribeCOV service. The remote station stores the subscription in a table, which often has a limited size. In cases where many devices in a network register for changes of a particular property (e.g. weather data), it may be sensible to use the service Unsolicited COV. In this case, no registration is required. The source device automatically sends changes as broadcast (message to all devices in the network). If this mode is used for client process data, the corresponding property is read once via ReadProperty when TwinCAT starts (initial value). Subsequently, the corresponding broadcast telegrams are evaluated. Details about the configuration of Unsolicited COV as client and server can be found at the end of this chapter. |
ReadProperty (Polling) | This mode is activated in the "Cyclic In Data" dialog. Property values are transferred cyclically via ReadProperty. |
ReadPropertyMultiple per Object (RPM-O) | In BACnet, the service ReadPropertyMultiple can be used to transfer several property values in one message. RPM-O mode can be used in cases where many property data have to be transferred as process data from a remote BACnet device. In this case, cyclic read access operations to several properties are consolidated in one message per object. |
ReadPropertyMultiple per Client (RPM-C) | In BACnet, the service ReadPropertyMultiple can be used to transfer several property values in one message. RPM-C mode can be used in cases where many property data have to be transferred as process data from a remote BACnet device. In contrast to RPM-O, in RPM-C all property values of all objects are consolidated to one message. The BACnet stack automatically optimizes the request size to avoid segmentation at BACnet level (messages are limited to approx. < 1400 bytes per message). |
Unsolicited COV - client configuration
With the Unsolicited COV feature, change messages are sent without the need to register in the BACnet network (COV subscription). This function is used by room control units or weather stations, for example. The Unsolicited COV mode can be used to 'consume' these change messages as client process data. This mode can be selected via the Property wizard by selecting all required objects of the BACnet client, selecting properties and then activating the new mode in the field "Change Process Data In Configuration (Read)". In this mode an initial value is read once on startup via ReadProperty. Subsequently the change messages are processed.
Unsolicited COV - server configuration
TwinCAT BACnet/IP also supports the Unsolicited COV server functionality. This means that change messages can be sent as broadcast in the BACnet network without registration. Unsolicited COV is configured via a Notification Sink (or several Notification Sinks). The context menu in the "Settings" tab can be used to activate Unsolicited COV via the checkbox "Use unsolicited COV Broadcasts". This causes all configured COV subscriptions to be stored and processed internally with broadcast recipient. The COV subscription list can also be used for settings such as the COV increment.
The Property wizard, which is available in the context menu, can be used to select the properties for which change notifications are to be sent.
