Enqueue/Dequeue is repeating the last queued element

[Phoenix729]

Hello

I am trying to aquire data from a camera at 256fps in one for loop, enqueueing the data after each frame is acquired. A seperate while loop is supposed to dequeue each image and stream it to a binary file, acheiving the maximum imaging speed possible by seperating the data acquisition from the saving routine.

However, this is not happening. The files are being queued and dequeued correctly UNTIL the acquisition for loop reaches completion (for example after 500 cycles) at which point the dequeue VI stops passing successive images to the binary write VI and just sends the last dequeued image over and over again until 500 images have been written to the binary file.     

Can anyone suggest why this might be happening?

Cheers 

[Norbert_B]

Can you post the VI?

I asume, that you destroy the queue before you have dequeued all elements. Due to bad error handling (?), you don't catch that and therefore keep on going to work with all datasets.

The thing i am wondering about is, because if i am correct, you should get empty pictures instead of the old one......

Norbert 

[Phoenix729]

No, the progress of the Vi is controlled by the error wire and so can not reach the release queue before completing the dequeueing routine. Attached is the VI

[RavensFan]

I haven't used IMAQ, so I'm not an expert, but I remember reading something about IMAQ in other forum messages.

I thought the purple Image wire is actually just a reference to a location in memory, and is not an actual chunk of data.  So I think you are queueing up 500 references to the same chunk of memory.    You are dequeuing 500 references.  Now you are probably actually missing some images during the time both loops are running because the consumer loop is running slower.  But once the producer loop is finished, the same final image remains in that memory location, and the consumer loop keeps dequeuing that for the remainder of the 500 times.

[Phoenix729]

Ok, I think you are right about the IMAQ referencing a location rather then actual data. I have put an image to array VI infront of the enqueue Vi in the producer loop and this seems to allow me to write 500 different images (as arrays of intergers).

This throws up 2 new problems though, the images do not appear as they should and the saved binary data file is twice as large as it should be. I've checked that there is nothing wrong with the acquisition program by removing the enqueue VIs. The presence of the queue is causng either the triggering or the grab acquire VI to stop working correctly.

If this queueing approach doesn't work, what other alternatives are there for acquiring large amounts fo data as quickly as possible before writing it to the computers hard disk?  

[John.P]

Hi Phoenix,

The queue approach is still the best architecture for your application.  Instead of converting the image to an array, have you tried flattening each image to a string and passing this into the que?

You can then un-flatten from the string in the non-deterministic loop.

Hope this helps,

John P

[Phoenix729]

Seems to increase the speed of the binary writing and the file size is as it should be but unfortunately, does not change the image stability problem. The image appears to flicker when the queueing substructure is activated. On closer inspection when opeing the saved binary file, every other image is the same. This leads me to beleive that the queueing element is affecting the triggering that controls the light soruce.

Is a queue function known to affect a loop? In the program it is set to repeat 256 times, is there any way the loop can repeat more times then this? Is there any possible way the trigger in the loop could be activated more then 256 times?

[Phoenix729]

nope, thats not the problem either. Just checked the trigger function and it is working normally. it seems as if one particular element is being dequeued and inserted inbetween every proper image. Every other image is being dequeued and saved correctly but the images inbetween are out of place. Each image is also unique, the inbetweeen images are also all different  despite being dequeued incorrectly. Almost as if the dequeue element was swapping between FIFO and FILO after each iteration of the loop