Events
The base framework of TwinCAT 3 Building Automation and the objects it contains offer extensive functions for processing events.
In TF8040, an event always refers to an object. Events occur when an object assumes an abnormal or faulty state. Event-capable objects in TwinCAT 3 Building Automation have the bEvent output for further processing of the event within the TwinCAT program.
Example:FB_BA_AI
The state of an object is described with the EventState.
Possible event states are:
|
State |
Description |
|---|---|
|
eNormal |
The state of the object is normal. |
|
eFault |
The state of the object is faulty. |
|
eOffnormal |
The state of the object is abnormal. |
|
eLowLimit |
The upper limit value of an analog object has been exceeded. |
|
eHighLimit |
The value has fallen below the lower limit of an analog object. |
Display of events
Events are displayed in the event list of the Site Explorer and the TcHmiBa. The events are also transmitted to BACnet clients via the BACnet server if required.
The display of an event depends on the following properties:
- Event type
- Alarm mode
- Acknowledge and reset state
This results in the following possibilities for displaying an event (illustration using the example of an alarm event):
|
Designation |
Figure |
Description |
|---|---|---|
|
Hidden |
|
No event is pending. |
|
Indicated* |
|
The event is not (no longer) pending, but is indicated for information purposes until it is acknowledged. |
|
Past and acknowledged** |
|
The event is not (no longer) pending. However, it has already been acknowledged but not yet reset. |
|
Past** |
|
The event is not (no longer) pending. However, it was neither acknowledged nor reset. |
|
Pending and acknowledged |
|
An event is pending and has been acknowledged. |
|
Pending |
|
The event is pending. |
* Only possible with alarm mode standard!
** Only possible with extended alarm mode!
The following representations result for each event type:
|
State |
Alarm |
Fault |
Maintenance |
Notification |
Miscellaneous |
|---|---|---|---|---|---|
|
Hidden |
- |
- |
- |
- |
- |
|
Indicated |
|
|
|
|
|
|
Past, Acknowledged |
|
|
|
|
|
|
Past |
|
|
|
|
|
|
Pending, Acknowledged |
|
|
|
|
|
|
Pending |
|
|
|
|
|
Event controllers
Critical events often require a control response, such as shutting down a ventilation system after a fire damper fails.
The desired control functionality is parameterized with the lock functionalities of the event-enabled objects.
For this purpose, the events within the levels in the project structure are summarized and evaluated using the function block FB_BA_PlantLock.
Parameterizing events
An event can have different requirements with regard to its display, its control processing and its acknowledgement and resetting. Most of these properties are not parameterized on the object itself, but with the event class FB_BA_EC assigned to the object.
 | An event is called active as soon as it is no longer in the Normal state (Hidden). |
Acknowledging and resetting
The user can interact with active events. He has the following options (depending on the configured alarm mode):
With the function block FB_BA_EventObserver it is possible to carry out a collective acknowledgement or reset of all events within the project structure. Which objects are acknowledged or reset depends on the position of the FB_BA_EventObserver in the project structure. In general, all objects that are located in the same folder or a subfolder in the project structure are acknowledged or reset.
-
Acknowledging
Signals (e.g. to maintenance staff) a perceived event.
In terms of understanding, it should be possible to deduce that a corresponding action is now required.
The acknowledgement is therefore for information purposes. -
Reset
In extended alarm mode, an event (or an object) must not only be acknowledged, but also reset in order to restore an already passed event to the normal state.
Resetting therefore prevents the occurrence of undefined states (e.g. uncontrolled restarting of systems) and thus provides additional safety.
Lock priorities
Define the priority for disabling events that, for example, have the desired effect on the FB_BA_PlantLock.
-
Local medium
Enables a local shutdown of medium* priority. -
Local high
Enables a local shutdown of higher** priority. -
Medium
Enables a higher-level shutdown* of medium priority. -
High
Enables a higher-level shutdown** of higher priority.
* Used for system-safe program sections.
** Used for personnel-safe program sections.