Event response¶
The event responder interface executes autonomous responses that are triggered by events.
See also
- Event
Explanation of the general concept of events and their purpose in the motion software.
There are two types of event responses:
High-level: A high-level response remains active as long as it is being triggered by active events (provided that it has the highest priority). The response will keep enforcing its behavior as long as it has the highest priority. It can be preempted by a higher priority response, but if the event that triggers the low-priority response is still active when the higher-priority response ends, the low-priority response will become active again.
Edge-triggered: An edge-triggered response will only execute when at the time of the rising edge, it has the highest priority. If not, the trigger is lost. An edge-triggered response will execute its behavior and when that is finished it is also not active anymore. Quickstop response is an example of edge-triggered.
Responses are implemented by the event responder interface, to which the user can add events. A response is requested based on the event active state. Examples of responses that can be triggered are performing a quick stop or disable voltage commands.
Events may have mandatory responses, which means that the response is ‘hard-wired’ and not configurable. These mandatory responses are typically intended to protect the motion controller or servo drive from physical damage, for example due to over-current. Furthermore, events maybe be default configured for responses at power-on, these can be removed by the user if desired.
Depending on the state of the top-controller (see Top-controller), different constraints are present on the response behavior.
Top-controller state |
Description |
|---|---|
Config |
|
Run |
Adding an event to a response in these states requires processing time, during this time the event does not yet request the response. Removing an event from a response in these states requires processing time, during this time the event can still request this response and trigger the response callback. |
Propagating event responses¶
An event can be configured to have propagating responses. This mechanism is typically used for coupling the behavior of an axis control group to the behavior of its underlying axes or to another axis control group. From Propagating event responses to axis group it can be seen that QuickStopError, which is configured to respond to Event2, is configured as a propagating response to Axis-Group. Therefore, each time the Event2 is triggered, a QuickStopError response will be initiated on Axis-Group. This makes configuration easier when using multiple axis controls.
Propagating event responses to axis group¶
Similarly, Propagating event responses to physical axis shows an Error response on a logical axis being configured as propagating to the Error response on the corresponding physical axis. Therefore, each time the Event1 is triggered, a Error response will be initiated on Axis-Physical.
Propagating event responses to physical axis¶
Priority¶
Every event response has a unique priority number within the scope of an event responder. This priority is used to determine which response is executed/aborted when multiple responses are requested.
Note
A low priority number implies the response has a higher priority (is more important). E.g. priority number 100 is a higher priority than priority number 110.
The rules that responses of one event responder follow:
At most one response is active at any time on a responder.
When multiple responses could become active due to active events, only the highest priority event response will become active.
Queue¶
Event responses are monitored in the real-time domain of the motion controller. To report event responses to the user application the responses are transferred to the non real-time domain using a queue.
Order¶
Event responses are internally handled using the same queue as the event occurrences (see Events - Queue order). An event response is inserted into the queue under the following conditions:
when a response with subscription becomes active, i.e. the response signal value changes from false to true, or
when a subscription is created for an active response, i.e. the response signal value equals true when the subscription is created.
Response queues and subscriptions have the following constraints:
Queue order is guaranteed for multiple responses that occur in different real-time samples, i.e. the first response that occurs in the real-time controller is also the first one reported to the user application using an event response handler delegate.
Responses that occur in the same real-time sample are reported in undefined order to the user application.
When multiple events and responses occur in the same real-time sample all events are reported first and all responses are reported afterward.
When multiple queues are subscribed for a response these queues are called in an undefined order.
See also
- EventResponse
XML configuration example of the event response interface.