Event¶

The Event interface is used for producing an event, based on predefined conditions. An event is defined as active as long as the conditions for the event are valid, e.g. for an over-temperature event, the event is active for the entire duration the temperature is above a predefined threshold.

The user application can subscribe to be notified about an event occurrence for logging, or to trigger an action in the user application. Additionally an event can be configured to trigger an autonomous event response, for example to execute a quickstop move when a proximity sensor event is activated.

Depending on the state of the top-controller (see Top-controller), different constraints are present on the event behavior.

Top-controller state	Description
Config	The Event signal value is reset to false. Queues are disabled.
Run	The Event signal value is updated periodically. Queues are enabled.

Context information¶

The event handler can provide additional context information regarding the occurred event. An example of an additional string for a tracking error event is TrackingError 'xx' is larger than TrackingErrorLimitMoving 'yy'.

Note

Context information is disabled by default to reduce processor load. It can be enabled on per event using the API or XML configuration file.

Event forcing¶

For testing purposes it is also possible to force events into the active state. The different options for forcing events are described in the following table:

Force type	Description
AutoReset	Set the event active, and automatically reset it to inactive.
Set	Set the event active.
Reset	Reset the event inactive.

Queue¶

Event occurrences are monitored in the real-time domain of the motion controller. To report event occurrences to the user application the events are transferred to the non real-time domain using a queue. It is important to understand how the queue orders events and how queue overflows are handled.

Order¶

Event occurrences are internally handled using a queue. A queue is used to transfer event occurrence detected in the real-time domain to the non real-time domain.

An event occurrence is inserted into the queue under the following conditions:

when an event with an event handler subscription becomes active, i.e. the event signal value changes from false to true, or
when an event handler subscription is created for an active event, i.e. the event signal value equals true when the subscription is created.

The non real-time domain removes the event occurrence from the queue and calls the subscribed event handler. The same queue is also used to report event response occurrences (see Event responses - Queue order). This ensures proper order in reporting of event response occurrences.

The following applies:

For multiple events that occur in different real-time samples, response order is guaranteed. The first event that occurred in the real-time domain is also the first event reported using the event handler.
For multiple events that occur in the same real-time sample, response order is arbitrary.
For an event response triggered by an event, the response order is the first event and then the event response.

Furthermore, multiple handlers subscribed to the same event are called in arbitrary order.

Overflow¶

No event occurrences are missed unless the queue overflows. In case of an overflow the EventQueueOverrun event becomes active, which, as a special case, replaces the latest/newest occurrence written into the queue. The order of entries in the queue up to the EventQueueOverrun event occurrence is maintained. Subsequent occurrences are missed until an additional room becomes available in the queue. To prevent the queue from overflowing, the user application must keep the queue duration as short as possible.