You call the NDM notification functions to raise or lower a signal state in the NDM (and by extension, on the PLC). In some cases, you also supply some additional data which is stored in the NDM (and by extension, available to your PLC application).
The following table summarizes the available NDM notification functions. For information on function arguments and return values, refer to the Programming Reference starting with the CogNdm class. Many of the following functions take a cameraIndex argument. This argument indicates which of the four acquisition and inspection engines, each of which corresponds to a physical camera, the notification refers to. Some functions also take an acquisitionID argument to serve as a unique identifier so that multiple overlapping image acquisitions from multiple cameras can be managed.
NotifyAcquisitionComplete | Notify the PLC that an acquisition has completed. This function is used to inform the PLC that an acquisition has been completed. Calling this function will automatically re-enable the trigger ready bit on the PLC. You call this function to inform the PLC that an acquisition that it requested is complete and to inform it that a locally triggered acquisition is complete. Before calling NotifyInspectionComplete(), it is required to call this function as well. |
| NotifyAcquisitionDisabled | Optionally notify the PLC that the Vision System is unable to receive acquisition triggers. |
| NotifyAcquisitionError | Notify the remote device that an acquisition error has occurred. |
NotifyAcquisitionMovePart | Optionally notify the remote device that the exposure is complete or the strobe has fired and it is now safe to move the part from the field of view. You can use this notification function to tell the PLC that the acquisition (but not the inspection) is complete. |
NotifyAcquisitionReady | Notify the PLC that the Vision System is ready to receive acquisition triggers. You must call this function to enable the PLC to send a trigger using the TriggerAcquisition event. After the first call to this function, the NDM will automatically call NotifyAcquistionReady whenever your application calls NotifyAcquistionComplete. |
| NotifyAcquisitionStarted | Optionally notify the remote device that an acquisition has started. |
| NotifyAsyncSoftEventComplete | Notify the remote device that an asynchronous soft event has completed. |
| NotifyError | Notify the remote device (PLC) that the Vision System has encountered an error. |
NotifyInspectionComplete(CogNdmInspectionResult result) | Notify the PLC that an inspection has finished. This overload is not available through the Notify PLC Block; it can only be called from script. The CogNdmInspection result argument to this function provides information, including which engine and which images were used to generate the result. Note: The InspectionIndex member of the CogNdmInspection object corresponds to the cameraIndex argument used in other functions. It is the engine number. |
NotifyInspectionComplete(Int32 inspectionIndex, CogNdmUsedAcquisitionIDCollection usedAcquisitionIDs, Boolean inspectionPassed, Int32 resultCode, Byte[] resultData, Int32 resultDataOffset) | Notify the PLC that an inspection has finished. This overload is available through the Notify PLC Block or it can be called from script. All of the supplied arguments are written to the signal table for use by your PLC application. Note: The inspectionIndex argument corresponds to the cameraIndex argument used in other functions. It is the engine number and must be in the range 0-3. |
| NotifyJobState | Notify the remote device which job is loaded. |
| NotifyRunning | Notify the PLC that the Vision System is running or "online". |
| NotifyStopped | Notify the PLC that the Vision System stopped running or gone "offline". |
| NotifySystemStatus | Notifies the PLC of the Vision System status. |
When your PLC application changes the value of an NDM signal, the NDM will issue one of the events listed in the following table:
ClearError | The NDM raises the ClearError event to inform the vision system that the remote device has been notified of an error reported by the vision system and the error has been be cleared. Handle this event to know when the remote device has acknowledged an error and normal operation can continue. |
JobChangeRequested | The NDM raises the JobChangeRequested event to inform the vision system that the remote device has requested a job change. Handle this event and use the JobID and JobSlot properties of the event args to determine which job to load and where. |
NewUserData | The NDM raises the NewUserData event to tell the vision system that new user data has arrived from the remote device.. Handle this event and call ReadUserData(Int32, Int32) to read the new user data. Note that changes to the user data present on the remote device cannot be read until the remote device signals the vision system that new user data is available by sending a "Set User Data" signal. The remote device can send separate "Set User Data" signals for each user data channel. Use the ChannelIndex property of the event args to determine which "Set User Data" signal was received. Upon returning from the event handler, the remote device is automatically notified by sending the “Set User Data Ack” signal. |
OfflineRequested | The NDM raises the OfflineRequested event to tell the vision system that it should go offline. Handle this event and use the ReturnToPreviousState property of the event args to determine whether to transition the vision system offline or return it to its previous state. |
ProtocolStatusChanged | The NDM raises the ProtocolStatusChanged event to inform the vision system that the status of the underlying protocol has changed. Handle this event and use the RemoteAddress and ProtocolStatus properties of the event args to determine how the protocol status has changed. |
TriggerAcquisition | The NDM raises the TriggerAcquisition event to inform the vision system that the remote device has requested an image Acquisition. Handle this event and use the CameraIndex property of the event args to determine which camera should perform the image acquisition. Set the ResponseCode property of the event args to notify the remote device if an acquisition error has occurred. |
| TriggerAcquisitionDisabledError | The NDM raises the TriggerAcquisitionDisabledError event to tell the vision system that an acquisition trigger was set but the acquisition trigger was not enabled. |
TriggerAcquisitionNotReadyError | The NDM raises the TriggerAcquisitionNotReadyError event when the remote device asserts a "Trigger Camera" signal high without waiting for the vision system to signal that it's ready to receive triggers by setting the "Trigger Ready" signal high. Handle this event and use the CameraIndex to identify which camera channel was triggered before it was ready. Your user code should call NotifyAcquisitionComplete(Int32, Int32) to signal that the vision system that it has completed the current acquisition and is ready to receive another "Trigger Camera" signal from the remote device. |
TriggerAcquisitionStop | The NDM raises the TriggerAcquisitionStop event to tell the vision system that the Acquisition trigger has been reset. Handle this event and use the CameraIndex property of the event args to determine which camera trigger was reset. |
TriggerSoftEvent | The NDM raises the TriggerSoftEvent event to inform the vision system that the remote device has requested that a soft event execute. Handle this event and use the SoftEventID property of the event args to determine which soft event should execute. Set the ResponseCode property of the event args to notify the remote device of the status of the soft event when the event handler returns. |
TriggerSoftEventOff | The NDM raises the TriggerSoftEventOff event to tell the vision system that the soft event trigger bit has been reset. Handle this event and use the SoftEventID property of the event args to determine which soft event has been reset. |
There are some important restrictions to keep in mind while writing host notification event handler functions:
- You should avoid writing an event handler that takes a long time to execute.
- Your event handler must not throw any unhandled exceptions.
- Your event handler must invoke to the GUI thread in order manipulate GUI objects.