IMAQdx FrameDone event with multiple cameras

[GFDGreg]

Hello,  I have used the FrameDone event with a single camera for years.  I am expanding to multiple cameras and the behavior I am observing seems strange.

I am running multiple paralell event loops (one for each camera) and have registered the FrameDone event on each of these loops using the individual camera sessions.

The strange thing is that the FrameDone event does not seem to care that it is registered using different cameras.  In each loop, the event triggers no matter which camera has completed a frame.  It always returns the CtlRef under which it was registered, but returns the ActualBufferNumber of the image that tirggered the event.

I can mitigate this somewhat by keeping camera frame rates constant and adjusting the BufferInterval, but this seems like a less than elegant solution.  It seems to prevent: use of framerates that are not multiples of eachother, ability to change framerates without recalculating all the BufferIntervals, and the ability to add or subtract cameras without changing the code.

Is the framedone event really supposed to trigger after every frame from every camera, or do I have something wired wrong?  Is there a better way to correct the number of events than the BufferInterval?

Thanks,

Greg

[BlueCheese]

Greg,

Would you mind posting a snippet of code? I tried to replicate this here and when using two separate event loops there shouldn't be any issues. I have attached the snippet of code I used to test. I was using LV 2009 SP1 and IMAQdx 3.5.

 

Eric 

Message Edited by BlueCheese on 03-03-2010 06:13 PM

[GFDGreg]

Eric,

Thanks for the rapid reply.  I only have LV8.0.1, so I don't think I can do snippets.  I am posting a vi that exhibits the behavior I described.  The most obvious symptom is that Processed FPS (which is an event count) goes to twice the cameras' frame rates if the frame rates are the same.  In addition, since I've put the second camera on a five second delay, you can see the buffer number flicker between the two buffer counts in the indicator (instead of continuously rising).

I am using LV 8.0.1 and IMAQdx 3.1.0

Thanks,

Greg

[BlueCheese]

Hi Greg,

I tried your example without any modifications and it appears to work correctly for me. I had two cameras, one running at 4.5fps and the other at 10fps. Both seemed to get expected behavior (see screenshot). Again I am running with LV 2009 SP1 and IMAQdx 3.5.

There have been various "issues" in the past with LabVIEW's event handing, but none that I can recall that would exhibit themselves with the way your code is set up. I'd suggest a couple possible courses of actions:

-You should be able to upgrade to the latest version of IMAQdx (3.5) with your current license. http://joule.ni.com/nidu/cds/view/p/id/1524/lang/en

-Maybe try downloading an evaluation copy of a newer version of LabVIEW and see if that helps. They can be installed side-by-side with your older version.

-You could move away from using event structures. Its relatively easy to make a separate acquisition loop that blocks waiting for images and posts the results into a queue that your other loop uses. It could even raise user events of your own. I'd actually recommend doing things this way anyways because it gives you much more control of the acquisition loop than you get when using the frame done events directly. For instance, you can control what you want to do if your acquisition loop gets behind---while the LabVIEW FrameDone event just keeps stuffing the events into a limitless queue with no way to determine its backlog.

 

[GFDGreg]

Eric,

Thank you for looking into this issue.  I upgraded IMAQdx to 3.1.2.  I am not able to upgrade further because the later versions do not support LV 8.0.1.  The problem persists.  However, I think I was able implement your non-event method, and I do not see the problem in that implementation.  Could you check the attached code and make sure I correctly interpreted what you were suggesting?

Thanks,

Greg

[GFDGreg]

I wanted to post an update on this problem.

I was having a bunch of problems with LabView, including this one.  I went so far as deleting all NI software and reinstalling it.  Nothing worked.  Finally, I got fed up, formatted the harddrive, and reinstalled windows and labview.  I replaced some bad memory as well.

This somewhat draconian tactic managed to fix all my problems except the one discussed in this thread.  It made this one much worse.  Now, instead of kicking a framedone event every time either camera completes a frame, it kicks one only when the first registered camera completes a frame.  I can no longer get images from the second camera at all as the IMAQdx Get Image.vi just times out.  This means that that second VI I posted no longer works either and there is no way for me to run two simultaneous cameras at all.

Any insight would be great.  Otherwise, I'll post again if I ever get this fixed. 

[BlueCheese]

Greg,

What kind of cameras are you using? Can you acquire from the second camera in MAX? I suspect when you reconfigured something you might not have setup everything right for both cameras... For instance, if you are using GigE Vision cameras you may need to do a bit of configuration to handle multiple network ports...

As for your original problem, I suspect that you might need a newer version of LabVIEW to fix those multiple event registrations. Or you could continue going down the path of not using events, which I would recommend anyways. Your code you posted is slightly incorrect because you queue the same image to the queue multiple times even though images are reference datatypes. You likely want to either maintain a queue of "free" images that you recycle and pass to and from your consumer loop, or else do your image processing in your producer loop and push results to your consumer loop.

Eric 

[GFDGreg]

Eric,

I think you were right about the new problem.  I am using 2 firewire cameras plugged into a 2port firewire ExpressCard.  The expresscard is reliant on drivers that come with Windows.  After another automatic windows update and a restart, the cameras behave according to the original problem, so I think it was missing a driver update for that card after the clean reinstall.

I don't think my company will be springing for a new version of LabView anytime soon, so I will just have to move away from the event driven architecture.  I am just glad the two cameras are working together again.

Thanks,

Greg 

[GFDGreg]

One more thing:  I tried this on another computer with the same version of LV and it worked the way it was supposed to.  It was a desktop with a regular firewire PCI card.  So I don't think it is the LabView version, but maybe how the framedone events are handled through this Expresscard that I have in the laptop.

Just wanted to post all the data I have in case someone else hits this problem. 

Thanks for all the help.

Greg 

[BlueCheese]

---

GFDGreg wrote:

One more thing:  I tried this on another computer with the same version of LV and it worked the way it was supposed to.  It was a desktop with a regular firewire PCI card.  So I don't think it is the LabView version, but maybe how the framedone events are handled through this Expresscard that I have in the laptop.

Just wanted to post all the data I have in case someone else hits this problem. 

---

 

 

I doubt the difference in firewire cards would have any difference. The LabVIEW event mechanism is so far removed from the low-level firewire stuff that I really don't think there could be any relation. Either you're hitting other, more general acquisition issues or else you likely have some other software difference between the two systems (different service pack versions of LV, different versions of IMAQdx, etc).

Eric