07-27-2016 02:48 AM
Antonia,
depending on the speed of the iteration it is possible that you don't visually see the timeout LED to turn on and off again. Imagine the situation that 1 package per 1000 times out. Then we can assume that the next iteration after the timeout can immediatly enqueue. Depending on the code execution time of the package generation segment, the LED is maybe turned on for less than 1ms..... which is not perceivable by human eyes.
How many packages do you think are "overwritten" (in %)?
Norbert
07-27-2016 03:34 AM
Dear Norbert,
I also put a rising edge detector and a counter function that I can measure how often it timed out more objective and the counter stays at zero, very strange. I am not sure, from the images it seems more like the queue is only writting some values to be faster and that is why the image is reapeated in one frame, could that be?
Thanks for your help again.
Kind regards,
Antonia
07-27-2016 03:52 AM
Antonia,
does your question refer to the first or the second queue?
Do you have an error on the FPGA interface?
I'm not sure if your logic for enqueueing in the first queue is correct. From what i see and understand from you code, you enqueue only if the available bytes in the DMA (elements remaining) are LESS than the number of Pixels per Image. Is that really the desired procedure?
Norbert
07-27-2016 05:43 AM - edited 07-27-2016 05:44 AM
Dear Norbert,
For the first queue. I don't have any errors on the FPGA interface.
I think it should be find I am using the 1-Tap 8-Bit Camera with Frame Trigger example provided by Labview and changed it to my purposes but I kept the principle design. How would you suggest to read the data?
Kind regards,
Antonia
07-27-2016 06:32 AM - edited 07-27-2016 06:35 AM
Antonia,
i am not aware of that example. However, you should use probes to find out if data values match expected setups before enqueueing things. I consider that there could be a mess-up.
Norbert
EDIT: My recommendation is to start to break down the VI. First, check if data you get from the FPGA is 'valid' regarding your requirements. Then add back the queue but use an 'empty' reader. Does that get all data as expected? If so, continue to rebuild the complete VI until you start to run in issues again. You can use disable structures to remove code you don't want to execute without deleting it.
07-27-2016 09:29 AM
Dear Norbert,
Thank you so much that was a great idea with splitting up the acquisition. I solved my problem now. I doubled checked and it was really the read out was wrong as you described it in the previous post. I also integrated a flush the queue and now it works perfectly fine, great! Thank you very much!
Best regards,
Antonia