LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Frame Done Event questions

So I apologize if this has been answered elsewhere, but searching for "frame done" and "event" together returns just about nothing I'm interested in.

I'm trying to implement a nifty separate video loop for my 1394 camera with IMAQdx's new "Frame Done" event. I can get it to work, but I'm wondering the best way to implement a "Grab" and "Snap" functionality. I setup a dummy register for event for "Frame done" with a blank IMAQdx session to initially create the dynamic event refum. This returns an error, but I end up putting a valid IMAQdx session in it later. While initializing the camera, I configure the acquisition, start the acquisition, then notify the other loop that it can start. Since it really only has a "Frame Done" event (and one to stop the loop), it sits there waiting for an event. Good. Then when the user presses "grab" I register the IMAQdx session for the "Frame done event" and video starts getting captured.

Now enters maybe the faulty thinking. I'd like for the user to depress the grab button or press the snap button and have the video loop which is getting "Frame Done" events left and right to stop registering them. So I thought the best way was to unregister the event. This works great for pausing the video loop, but I can't get it going again by registering the IMAQdx session for "Frame Done" again when the user engages the grab button.

Ok, so just writing this out has given me an idea. Perhaps unregistering the event throws away that dynamic event refum so that the same refum (which the video loop is waiting on) will never recieve another "Frame Done" event even if I register for it again? (This doesn't seem quite right since when probed, the refum doesn't show up blank after it's been unregistered). At any rate, I just tried registering for a blank IMAQdx session (even though it throws an error from the register for events node) instead of unregistering and it gives the desired effect of pausing the video loop but also being able to start it again by putting in the corrent IMAQdx session.

For those of you trying out "Frame Done" I've included my little test vi. All you should need is a 1394 camera and IMAQ acquisition 3.2.1 or later.
Message 1 of 6
(4,589 Views)
Hello Ianmat,

It looks like you have a race condition (first make you sure you absolutely need two event structures)
The upper while loop waits on the start-notifier triggered by the start-button.
Is this notifier sent before you want to grab?
Then you register for the daqmx event with a name from the shift register (is the correct camera name shown?)
Maybe you should use execution highlighting.
Secondly I think you should use only one while loop and one event case can handle your events.

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 2 of 6
(4,583 Views)
There shouldn't be a race condition as long as the two event structures are handling separate events. The reason for the notifier is so that the lower loop has a chance to generate a valid IMAQdx session name, then passing it to the video loop. So it doesn't really matter whether the grab happens before the notification or not. In this case, the user has the option to start the grab (the Go! button) whenever. Even in the stop case, it's more of a cascade (video loop stops and fires off a separate boolean which stops the main loop so no race conditions should be there. It's mostly a matter of whether you can unregister an event and still have it fire the event structure when you re-register the event. What I've seen leads me to think that the answer is "no" and not because of a race condition since the loop can be running, waiting for the frame done event and registering a valid IMAQdx session sets the loop going.

The reason why I want a separate loop is that the main loop is actually the consumer loop of a producer-consumer loop design and handling video there bogs down the response of the system. I'm not sure whether putting it in a separate loop gives it it's own thread (such that it might be run on a separate core on a multi core system), but it definitely separates the execution well, leaving the remaining cpu time that's leftover after video acquisition to the producer/consumer loop (which in my particular case has some cpu intensive calculations that are done).
Message 3 of 6
(4,577 Views)
Ianmat,
 
I ran your VI, and I was able to restart acquisition by clicking the "go" button, so I'm not sure why it isn't working for you.  In general, though I think you could accomplish the same thing with a single loop architecture without any register for event nodes.  Simply ending a session, then restarting it with the "go" button inside a single event structure would be just as effective as what you are trying to do.  I highly recommend using only one event structure per VI.  If you want to use parallel loops, you might start with the "Producer/Consumer Design Pattern (Events)" template in LabVIEW.
 
Chris M.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 6
(4,548 Views)
The vi posted actually does work. If you look at the first post, I started with pausing the video by unregistering the IMAQdx session which never allowed re-registering. Switching to registering a blank IMAQdx session works as desired. I figured after making most of the post I might as well post my "question + solution" anyways in case anyone else was wondering a similar question.

As for the multiple event structure, the vi is actually a test case for a new design strategy that implements the producer-consumer method with a third loop designed solely for real-time data generation (be that video, voltage measurements, stage locations, etc.) which happen with high enough bandwidth to normally bog down the consumer loop. Case in point, if you're handling video inside the consumer loop and the user presses the "super-duper filter" button which goes on a 10 second rampage of blob analysis and multiple FFT operations, the video is going to hang. I've done some projects where I actually called a separate VI to handle the video, but this is a more elegant solution and allows direct usage of Image control property nodes inside the main VI for things like ROI (still waiting on that image control refnum fix...try passing one to a subvi). The bottom loop in the test vi simulates the effect of a producer-consumer loop going through initialization and starting the video loop.

A coworker and I are thinking of putting together a nicely formed template for NI week of our "Producer-Consumer-Generator" design. This question regarded mostly working out the details of IMAQdx's new "Frame Done" event and how it can be implemented.
0 Kudos
Message 5 of 6
(4,539 Views)

I know this is an old thread, but I wanted to add why Ianmat's solution works.  It is using dynamic event registration and un-registration. (https://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/dynamic_modifying_reg/) 

 

This at least helped me understand why the solution worked, and that it was not in fact some strange hack or bug with LabVIEW.

 

Cheers!

-Nathan

0 Kudos
Message 6 of 6
(3,512 Views)