Well, that was a surprise. I timed how long it took for the USB 6009 to generate 1000 samples, one at a time (as you are doing), and also timed how long it took to generate 1000 digital samples (as I had suggested). My prediction would be that it would be slower than 1KHz due to the inefficiency of one-at-a-time (and the USB Bus), but that Digital would win. Well, I was correct, but not by much. I got 494 Analog samples and 616 Digital.
While this doesn't completely explain your slowness, it partly does. You are "inverting the timers" -- you are clocking with the 6009, and only asking for a Frame when you get a sample. You should clock with the Camera -- take a frame and then ask "Should I take more frames?" by sampling the 6009.
Even better would be to set up parallel loops. You don't need all of the samples, just the latest one. You can use something called a Notifier for this. But try inverting the timers first, and see if that "mostly fixes" your problem.
Thanks a lot for your help Bob. The parallel loops solution ended up being the most elegent way to solve the problem. I was also able to attain the 60 frames per second using a nested while loop structure (rather than a case structure nested inside a while loop). It is important to note that for my application I needed to use Grab.vi and NOT Snap.vi. I was playing around with my code at some point and switched out Grab.vi with Snap.vi, which reduced the maximum number of frames I was able to acquire per second.
"-LabView program starts running and waits for GigE camera to output frames"
hi friend. How can I do that? Is there any VI which is waitting for new image in the camera when it is triggered by hardware trigger??
Thanks a lot!