From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to save circular buffered data before trigger?

Solved!
Go to solution

Hi,
        I am new in LabVIEW. I want to save some pre-trigger images. So, I use Losses Queue to circular buffer frames before trigger.
        My question is when I press trigger button, it should start saving the buffer frames from the oldest frame to the trigger frame, but it doesn’t like that. It starts saving data from the trigger frame until the frame number reach to the buffer number that I setting.
        For example, my camera has 110fps, I setting the buffer number is 550 frames, when I pressed the pre-trigger button, the time was 10s, it starts saving buffer frame through state machine, when the buffer numbers reach 550, then the procedure change to Saving Sate and start saving the buffered images. It should save the frames from 10s to about 15s, but it saved the frames from 15s to about 32s, which caused by the data processed speed is slower than data acquisition speed.
        I do not know why the queue buffer doesn’t work. If someone give me some advice to solve this problem, I will be very appreciated.
Frank Wang.wait for trigger.pngpre-trigger.pngSaving.png

0 Kudos
Message 1 of 5
(980 Views)

Sorry, I should use Lossy Queue,but I used Enqueue in there. Don't mind it, it will not affect the results.

0 Kudos
Message 2 of 5
(976 Views)
Solution
Accepted by topic author Frank_wang77

If you are "new to LabVIEW", then the problem you are having with LabVIEW Vision is perfectly understandable.  When I started with LabVIEW, I had at least a decade of experience in both Real-Time data acquisition programming and in data analysis programming (my preferred language was Pascal).  I had a mentor who basically taught me LabVIEW in a few months, and had several years of LabVIEW Real-Time experience before a colleague asked me to collaborate with him on his Image Acquisition system, my first introduction to LabVIEW Vision.

 

LabVIEW Vision is much more challenging than the LabVIEW of DAQmx.  One of the key concepts that was not clear to us is the concept of an "Image" and a "Buffer".  When you pass "images" around, and put them in queues, you are not passing what I think of as an "image", namely a 2D Array of Pixels that can be displayed or turned into an AVI or PNG file.  What is basically in the "Image wire" is a pointer (or "reference") to a region in PC memory where the Array of Pixels is located.  Who manages this "Image Memory"?  The Camera, except it calls the "Image Storage Space" a "buffer".

 

Look at your Configure Grab VI.  You have wired "1" into the "Number of Buffers" input, which tells LabVIEW to reserve space for 1 Image somewhere in memory.  This is essentially a "Lossy Queue" managed by LabVIEW Vision that holds the last "N" (or, in your case, single) Image.

 

Read the Help of the IMAQdx Grab2, which you are using to get the Images.  It says it "acquires the most current frame into Image Out".  This means that it returns a pointer to the (single) buffer where the Pixels are stored.  Since you only have one Buffer, every element in your lossy Queue contains exactly the same information, namely where the most current set of pixels (being overwritten 550 times/second) are stored!

 

I haven't been doing LabVIEW Vision much in the last 5 years (back to LabVIEW Real-Time and learning FPGA), so I don't have a recommendation for a good "learning path" for you except to find someone with real experience with LabVIEW Vision to act as a mentor.  Please realize that if you want to "look backwards in time" for 5 seconds of images acquired at 110 FPS,  you'll need to save at least 550 actual Images in memory.  Don't re-invent the Wheel by creating your own "Lossy Queue", particularly if it doesn't contain "Array-of-Pixel" images, but only "pointers to the same Array of Pixels".  

 

Bob Schor

0 Kudos
Message 3 of 5
(951 Views)

Hi Bob,

 

Thank you for your patience in explaining that queue saves addresses and not actual pixels.Knowing where the problem is, I think I can solve it. Thank you again!😁

 

Frank Wang

0 Kudos
Message 4 of 5
(926 Views)

I'm not sure you completely understand.  Your Queue elements all have the same value -- they all point to the single Image Buffer that  (because it's the only Buffer) always holds the latest Image.  So every image that you pull u from your Queue, however long you make the Queue, will always give you the same Buffer, which always holds the latest image.  Nothing you do with the Queue will make any difference -- you are always only going to be looking at the current Image.

 

Bob Schor

0 Kudos
Message 5 of 5
(918 Views)