problems with queuing (framegrabber PCIe-1433, Basler Sprint camera)

[sylwia.kolenderska]

Hi.

I am trying to get several images from my camera as soon as the trigger signal from a wave generator is read. I have a line-scan camera from Basler connected by two camera links to PCIe-1433 framegrabber. For a trigger signal I use SYNC output of the generator that also controls the movement of the scanner in my system.

I think the problem is in the way the queues are handled in the program, because instead of getting N (in my case 100) images from the camera each time the trigger is read, I get first 100 images from the queue each time the trigger is read. I tried to empty the queue before the loop, but it didn't solve the problem - just improved the situation a little bit (including not running out of memory).

Does anyone have an idea how to handle this problem? I know that my problem may be basic, but I have already read, I think, everything that is to be read, including looking at LabVIEW sample vis, but every time I get this queuing problem. I also tried sequence acquisition, but it turned out to be very slow in conjuction with trigger signal.

PS. There's a Fourier transformation in the code, because with the camera I detect the spectrum, so after FFT I get the axial profile of my object in one point. Then, with a  scanner I can get to many more such points and have a 2d image.

[ks30]

Sylwia,

What are you trying to accomplish with the trigger? Does that simply start your acquistion, or does it control each individual grab?

Another approach to buffering the images would be to use a Ring Acquisition:

Ring Acquisitions
http://www.ni.com/white-paper/4001/en/

A good example can be found at LabVIEW Help>> Find Examples >> Hardware Input and Output>> Vision Acquistion >> NI-IMAQ >> LL Ring.vi or LL Triggered Ring.vi

Regards, 

Kyle S. 
Applications Engineer 
National Instruments 
http://www.ni.com/support 

[sylwia.kolenderska]

Trigger signal has to determine when to start to acquire frames from my camera, but in my case, it determines when to dequeue an element (it worked for my colleagues who have a similar type of camera, but a dfferent framegrabber plus a DAQ card for triggering so they used NI-IMAQdx). In general, what I want to achieve is: when the trigger comes, take 100 current frames from the camera.

I've already gone through Ring acquisition and using buffers gave me exactly the same results as queues... I have also already checked the examples provided by LabVIEW. The only option that worked was the one with Sequence Acquisition, but it is way too slow.

[sylwia.kolenderska]

I attach the code that works for me, but is superslow. I used Triggered start of acquisition and Grab. It works, but 100 frames are taken in around 700 ms, whereas it should be around 80 or 90 ms (my camera is very fast). I think that it's slow, because each time I stop and start the acquisition.

Is there a way to make it faster? ANY other way? What is there that I cannot see here?

[sylwia.kolenderska]

And here's the program that I thought would do the the same as the previous one above, but fails to do so (it's fast, though). The Trigger Read is in the While loop. When the Trigger Status is 1, the loop ends and Grab acquisition starts (100 frames) and then  FFT is calculated. Those three steps are repeated in a While loop.

The problem is the same as I mentioned in the very first post: with each trigger the camera seems to pick up where it left off with the previous trigger.

[ks30]

Sylwia,

Can you post this over in our Vision forums? You will get more input from other community members there:

http://forums.ni.com/t5/Machine-Vision/bd-p/200 

Regards, 

Kyle S. 
Applications Engineer 
National Instruments 
http://www.ni.com/support 

[sylwia.kolenderska · Accepted solution]

That's true, maybe posting my problem in a more accurate forum would have been better.

However, I managed to solve my problem. It was due to the wrong function I used for inducing triggering effect. I put "IMAQ Trigger Read2.vi", which gave me Trigger status of 1 for the first half of trigger signal's period and 0 for the rest, what resulted in repeating acquisition when Trigger status was 1. Using "IMAQ Wait Signal2.vi" instead solved the issue.