How do you unregister a callback function for imgSessionWaitSignalAsync2

[Harold Bien]

Let's say I registered a callback function via ImgSessionWaitSignalAsync2, and now would like to stop the callback. I understand I can return zero from the callback function itself, but I would like an external function to terminate the callback process. Can I simply pass a NULL pointer for the callback function, or will this crash the driver when the condition becomes true? Thanks.

[Harold Bien]

On a related question, can you have more than one assigned callback for the same signal/condition? That is, if I had:

imgSessionWaitSignalAsync2(sessionID, IMG_SIGNAL_STATUS, IMG_BUF_COMPLETE, IMG_SIGNAL_STATE_HIGH, myCallback1);
imgSessionWaitSignalAsync2(sessionID, IMG_SIGNAL_STATUS, IMG_BUF_COMPLETE, IMG_SIGNAL_STATE_HIGH, myCallback2);

When the buffer complete signal gets asserted, would both 'myCallback1' and 'myCallback2' get called? Or only 'myCallback2'?
If both, then how does one go about clearing the registered callback (my first question) - would a imgClose(sessionID) work?

Thanks.

[s_a_s]

Harold,

The only way I know of clearing out the callback functions created with the imgSessionWaitSignalAsync2 function is to close the session using the imgClose() function.  It MAY be possible to pass in a NULL argument to the function pointer with a subsequent call, but I would recommend using the imgClose function to close the session.  That way we know that the memory is properly freed as closing the image unregisters the events,

As for  having multiple callback functions for the same signal condition.  This configuration is not recommended.  It will probably be best to call any functions you want to trigger from within the callback function you register with your first call te imgSessionWaitSignalAsync2().

[Harold Bien]

Thanks for the reply. If I understand you correctly, the imgSessionWaitSignalAsync2() function does maintain a list of registered callback functions, so while hooking multiple event handlers is not recommended, it is possible? And that if I pass in a NULL callback pointer, being the top of the list, there is the possibility that this might shut-down the callback chain?

Since you advised calling imgClose(sessionID), I was wondering if you could point me to more documentation on the use of sessions and interfaces, specifically:

1) When should you open/close a session? For each acquisition?
2) [as posted in another thread] Can you have more than one session open at a time?
3) If you can have more than one session open, I understand if you cannot acquire from both sessions at once, but can you send serial commands in one session, and acquire using another session?
4) If can you open more than one session, but as another poster noted you get the same sessionID returned, can you still access the session after an imgClose(sessionID)? Put another way, if I called imgSeesionOpen() twice, and then called imgClose(sessionID) once, is the session still valid/open?
5) [as posted in another thread] After you call imgConfigureSession(), it appears that the ROI and ACQ_WINDOW attributes are locked. Other than calling imgClose, is there another way to unlock the ROI/ACQ_WINDOW? I've tried, for instance, an undocumented function "imgMemUnlock" and it appears to work. Is the locking effect of imgConfigureSession() merely due to the presence of a imgMemLock() call?
6) After a call to imgSessionAcquire() and acquisition is done, i.e. IMG_AQ_DONE is asserted, to re-acquire another set of images using the same session requires yet another call to imgConfigureSession()? Why?
7) Can you re-use buffer lists between two open sessions?

Thanks.

[Harold Bien]

I'm not certain, but further testing so far indicates that even calling imgClose() on the session does not remove the callback. I'm trying to hunt down the problem, but it's difficult because it's another thread. My callback is referencing illegal memory locations because it's getting invoked after everything has been freed on a 2nd acquisition when it was not supposed to get executed. My next step will be to assign a NULL callback and see if that stops the callback or crashes IMAQ.

[s_a_s]

Harold,

I'm doing a little research to make sure I can give you the correct answers to your questions.  I'll post as I get answers.  One way of unregistering a callback is for the callback to return 0 when it is done. When a callback returns a non 0 number, it reregisters the callback and if it returns a 0, it unregisters it. The only disadvantage with this is that you cannot unregister a callback without calling it.  That might be a start.  I'll keep digging to see what more I can find out.

Arves

[Harold Bien]

Ah, a great point. I now understand why I was seeing this problem only in certain situations. Under normal operating conditions, my callback realizes it's done and returns '0'. However, when something goes wrong and I have to interrupt the acquisition with imgSessionAbort(), the callback knows it's not yet done and the last returned value is '1'. As a workaround, I guess I can add another parameter to the userData structure to tell the callback to return a 0, and then attempt another single frame snap to fire off the event. It's not the prettiest solution, nor the most efficient, but it might work.

In any case, my current solution is to ensure that my acquisition runs to completion without needing a call to imgAbort(). So far this has cleared up the problem, but I would be very glad to learn about the details of registrations/unregistering a callback.