An EventMgr object manages the collection and distribution of event messages from the controller to the host. Events include normal motion completion, motor limits, fault conditions, data recorder buffer full, network node faults, etc. The EventNotify methods enable the application to request host notification for specified events, while ignoring other events. The EventMgr receives the event and then distributes the event via the Notify object to the tasks that are waiting for the event. Events that are faults are latched; the fault condition and the event must be cleared before the event can be generated again.
To collect events, the EventMgr must be serviced via the mpiEventMgrService(...) routine. The EventMgr can be polled by periodically by calling the mpiEventMgrService(...) routine or can be placed in an interrupt service routine. For your convenience, there is an apputil module that provides a serviceCreate(...) function that creates an EventMgr service routine for Windows OSs. The Service thread can be configured for polling or interrupts. Sources for the apputil module are included with the software distribution, so you can port it to other OSs.
The controller has a circular buffer which holds up to 128 event messages. If the EventMgr is not serviced within 128 events, event messages will be overwritten as new events occur. For interrupt driven EventMgr service threads, this is not an issue. For a polling EventMgr service thread, this could be an issue if the service thread does not have enough CPU cycles. In the worst-case scenario, events could be lost.
The best way to avoid lost events is to use an interrupt driven EventMgr service routine. If you're using polling, the next best thing is to make sure the EventMgr services the events at a high enough rate to avoid controller message buffer rollover. Determining the worst case EventMgr service latency and the maximum event message rate can be tricky. A simple method is to estimate the event message frequency and make sure each EventMgr can poll at least once for every 32 events (safety factor of 4). If you know that some events occur more frequently than others, then you may want to increase the polling frequency for EventMgrs that process the most frequent events and decrease the polling frequency for EventMgrs that process less frequently.
Generally, use only one EventMgr in your application. Do not use multiple interrupt driven EventMgr service threads to collect the same event. Suppose you configure an EventMgr to service Motion Done events from MS 0 and you configure another EventMgr with MEIEventMgrServiceConfig.allProcesses = TRUE. If one EventMgr collects the event message and acknowledges the interrupt before the other EventMgr can respond, it will miss the event.
If you want to monitor ALL events with MEIEventMgrServiceConfig.allProcesses = TRUE, then use polling (not interrupts). See the sample app EventLog.c for an example.
Resetting the motion controller will cause any exising EventMgr objects to become unsynchronized with the motion controller, causing it to miss events. It is recommended that after a controller reset, an application should delete and re-create the EventMgr and Service objects. Then the application should reconnect all Notify objects to the EventMgr and re-enable event reporting by calling ObjectEventNotifySet.
| Error Messages |
|Create, Delete, Validate Methods|
|mpiEventMgrCreate||Create EventMgr object|
|mpiEventMgrDelete||Delete EventMgr object|
|mpiEventMgrValidate||Validate EventMgr object|
|Configuration and Information Methods|
|mpiEventMgrConfigGet||Get EventMgr config|
|mpiEventMgrConfigSet||Set EventMgr config|
|mpiEventMgrEvent||Request event notification for all Notify objects on EventMgr's list|
|meiEventMgrServiceConfigGet||Get processes that EventMgr will service|
|meiEventMgrServiceConfigSet||Set processes that EventMgr will service|
|mpiEventMgrFlush||Flush pending EventMgr events|
|mpiEventMgrService||Get list of all pending asynchronous events|
|List Methods- for Control Objects|
|mpiEventMgrControl||Return handle of indexth Control object in list|
|mpiEventMgrControlAppend||Append Control's handle to list|
|mpiEventMgrControlCount||Count the number of Control objects associated with EventMgr (in list)|
|mpiEventMgrControlFirst||Return handle to first Control object in list|
|mpiEventMgrControlIndex||Return the index of a Control object in list|
|mpiEventMgrControlInsert||Insert Control handle into list|
|mpiEventMgrControlLast||Get handle to last Control object in list|
|mpiEventMgrControlListGet||Get list of Control objects associated with EventMgr|
|mpiEventMgrControlListSet||Create a list of Control objects associated with EventMgr|
|mpiEventMgrControlNext||Get handle to next Control object in list|
|mpiEventMgrControlPrevious||Get handle to previous Control object in list|
|mpiEventMgrControlRemove||Remove a Control object's handle from list|
|List Methods- for Notify Objects|
|mpiEventMgrNotify||Return handle to a Notify object associated with EventMgr|
|mpiEventMgrNotifyAppend||Append Notify object to list|
|mpiEventMgrNotifyCount||Return number of Notify objects in list|
|mpiEventMgrNotifyFirst||Get first Notify object in list|
|mpiEventMgrNotifyIndex||Get index value for a Notify object in list|
|mpiEventMgrNotifyInsert||Place a Notify object after another Notify object in list|
|mpiEventMgrNotifyLast||Get handle to the Notify object that is last on the list|
|mpiEventMgrNotifyListGet||Get a list of Notify objects|
|mpiEventMgrNotifyListSet||Create a list of Notify objects|
|mpiEventMgrNotifyNext||Get the Notify object just after notify in list|
|mpiEventMgrNotifyPrevious||Get the Notify object just before notify in list|
|mpiEventMgrNotifyRemove||Remove a Notify object from list|