LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

image acquisition delay due to dequeue process

Dear all,

I have a strange interaction between a software triggered acquisition and a producer/consumer loop which is independent from the acquisition.

What I have is a subvi which acquires images from a camera through a software trigger every second and for a duration of the order of 5 minutes. My problem is that at every iteration of the trigger a systematic delay adds and at the end several milliseconds of delay are accumulated in the images acquisiton.

At the same time, in the main .vi an independent producer/consumer loop processes data acquired from another camera: the producer acquires and enqueues the images in a queue while the consumer dequeues and processes them (at a frequency of about 90Hz).

I found that it is enough to remove the consumer loop to avoid the systematic delay in the triggered acquisition. Does anyone have an idea what the origin of such a behaviour might be? Is there the possibility that the dequeueing process introduces delay in parallel processes?

0 Kudos
Message 1 of 9
(1,292 Views)

You'll have to attach a VI so we can follow along with what you are trying to describe in words.

0 Kudos
Message 2 of 9
(1,279 Views)

Dear all,

I am quite new to Labview and I need some help to sincronize a camera acquisition with the signal generated by a PXI through a software trigger.

I have periodic signal generated by my PXI using DCPower. The .vi I made is designed to iterate signals of the order of 0.1-10 Hz for tens of minutes (see the attachment) and works properly.

Now what I need is to acquire through an usb camera N images for each period. The images have to be equally spaced in time and syncronized with the PXI signal at the beginning of every new period.

Which is the best way to trigger the image acquisition without adding any delay between the signal and the image acquisiton?

 

I made a very naive attempt using a triggered software acquisition as described here, adding the trigger software inside frame 12 and adding a circular buffer acquisition in frame 13 parallel to the "wait for PXI event" loop. In this way, however, a delay is sistematically introduced between the trigger and the image acquisition and after 300 iterations about 10 milliseconds of delay are accumulated...

Thanks in advance

0 Kudos
Message 3 of 9
(1,261 Views)

Sorry for the lack of clarity. I realised that I had made a mistake in assessing the source of the delay. I have rephrased the question more correctly here, also attaching my VI.

0 Kudos
Message 4 of 9
(1,225 Views)

@pddg wrote:

Sorry for the lack of clarity. I realised that I had made a mistake in assessing the source of the delay. I have rephrased the question more correctly here, also attaching my VI.


That thread was merged. Please don't create a new thread for the same question. 

 

EDIT: Actually, that's a completely different question. Maybe a merge wasn't that appropriate (wasn't me).

0 Kudos
Message 5 of 9
(1,195 Views)

I agree that it was not appropriate to merge.

But apart from these matters, does anyone have any suggestions for me regarding the issue I have raised?

0 Kudos
Message 6 of 9
(1,175 Views)

I'd say it was appropriate to merge, the OP said they made a mistake in phrasing the original question and reworded it.  Same problem, just better information.

0 Kudos
Message 7 of 9
(1,151 Views)

Ok

 

Apart from this

 

Now that the question is more clear, do you have any suggestion?

0 Kudos
Message 8 of 9
(1,134 Views)

@pddg wrote:

Now that the question is more clear, do you have any suggestion?


Sorry, not me.

 

This is a technical niche, and it seems pretty low level too. You'd have to catch the attention of the right person...

0 Kudos
Message 9 of 9
(1,128 Views)