FIFO Good Practice: update old cluster or create new one

[LucG]

Hi everyone,

My question is more about "good practice" than really solving an issue.

I am using FIFO to pass images and other data from a producer to a consumer.

I created a cluster that groups all the data that are to be sent through the FIFO.

My question is: should I create a new cluster at every loop of the producer and put this cluster in the FIFO, or should I define a shift register and then update the data from this shift register berfore sending it in the FIFO?

Below you will find two screenshots that sum up the idea (NB: these are not real VI. There are just here to show the general idea).

If there is a difference (in the way the computer uses the memory for example, or anything else...) between these two programming methods, will you give me some details so that I can understand why to use one rather than the other, please?

Thanks you very much.

Best regards.

Luc

[Sam_Sharp · Accepted solution]

I think there is very little difference in terms of performance (maybe the shift register approach is sliiightly slower - but unlikely to be noticeable in most cases).

The main reason you would want to use the shift-register approach is that if you only update some values before sending the data into the queue, those would be lost if you just created a new cluster each time. For example, if 'OtherData' was constant, you might just feed/update that once in the value on the shift register and just update the 'ImageAcquired' part of the cluster before sending it into the queue. It also means that if you update your cluster to have more items (using a type-def, of course), you can be less worried about having to update the individual items.

I think it's less of a performance issue (both are valid and efficient), and more of a maintainability/flexibility issue.

[udka]

When you say passing images from producer to consumer, Please be sure to use IMAQ Create to create User Buffer reference. What you transfer is Image reference and not the image. And i see in both your approaches there's no mentioning of it and the image gets overwritten.

Hence, i prefer to create the cluster and the new image reference for the new image and enqueue it. Dispose in Consumer loop after processing, to avoid memory overflow.

[LucG]

Thanks to you two for those usefull informations.

I'd like to come back on udka's suggestion to create/dispose a new reference for each image. It seems indeed logical to do so since it is a 'reference' and not a proper image (as in memory space that actually stores the pixels information). However, from the tests I've been running for my software development, it seems that even if the consumer is running late on the producer, all the images are still processed, as if it was indeed the image that was passed in the FIFO and not the reference.

Would Labview duplicate (implicitely) the image AND the reference every time you add an element in the FIFO, to make sure a new element added in the FIFO would not overwritte any older element that would still be in the FIFO?

[udka]

---

However, from the tests I've been running for my software development, it seems that even if the consumer is running late on the producer, all the images are still processed, as if it was indeed the image that was passed in the FIFO and not the reference.

---

-Without seeing full code difficult to comment. There are mainly two types of buffers, IMAQdx Driver buffer (Which IMAQdx driver uses to copy the image from camera) and User Buffer which i mentioned earlier.

-The first memory is configured based on the acquisition you configured. If grab, generally will be configured more than 3 to avoid same overwriting problem. At this point i am guessing this could be saving the image overwrite problem for you.

-How do say all images are processed?

Would Labview duplicate (implicitely) the image AND the reference every time you add an element in the FIFO, to make sure a new element added in the FIFO would not overwritte any older element that would still be in the FIFO?

---

-No, as per my knowledge it doesn't. What you enqueue is only image reference and it will be overwritten if consumer is too slow.

-How are you identifying that image is not overwritten?

[LucG]

After processing the images, I save them in a AVI file. When everything is done, I read the AVI file and the motion in the scene (my hand moving actually) seems consistent. My hand doesn't "jump" from one position to another, which would be the case if images were lost.

Anyway, I agree with you that without seeing the code, you can't actually tell if I'm not mistaken in the code in the first place. ^^

I'll create a new image to have a new reference and a new user buffer, and dispose it after processing. Better that than missing images on the final application. 😉

Thanks again for the advice.