How to always read from the first signal of a regenerated DAQmx output in a for loop?

[Ellie90]

Hi all,

I have an imaging system controlled by LabVIEW. The camera needs to take two images at each XY position -- one when the blue light on, and the other when the red light on. After taking two pictures, the XY stage moves to the next postion, then the camera image twice again. These modules are put in a for loop. The camera trigger and blue/red control signals are synchronized and generated continuously by DAQmx write in regeneration mode.

The problem is, each time when it loops and the camera receives a trigger, it could be either trigger 1 or trigger 2 (see attached schema), so LabVIEW could not know whether it is blue light or red light and save the data to its corresponding folder. It is not possible to sort the saved images manually since there will be hundreds and thousands of them. Is there a way to tell the camera to read trigger 1 first, then trigger 2?

Thanks!!

[TravisYN]

Hi Ellie90,

Have you considered posting this in the Machine Vision Forum? Someone there might know your answer more readily.

Also, are you controlling your lighting in LabVIEW as well? You may be able to read that information to determine which image is being captured.

[Ellie90]

Hi Travis,

Thanks for your suggestion. I will re-post it in the Machine Vision Forum.

For the lighting, yes, it is controlled with LabVIEW as well. I thought about using the lighting signal as the condition of a case structure. However, the case structure itself would take some time to process, and the signal could have changed before the code runs to image acquisition. Maybe you have some better ideas?

Thanks,

Ellie

[Ellie90]

BTW, the new post is here: 

http://forums.ni.com/t5/Machine-Vision/How-to-always-read-from-the-first-signal-of-a-regenerated-DAQ...

Thanks!

[DuncanW.]

Hi Ellie,

I am confused as to why the first trigger could be either trigger 1 or trigger 2. That implies that there is some element of randomness in your execution, which I assume is software execution timing, but I am unsure why that is a factor here. One of the goals of a good DAQ program design is that its data acquisition is reasonably independent of the software execution timing.

A couple of questions:

How are you triggering the camera? In software? In hardware?

Are the blue/red signals synchronized with the start of your for loop?

Finally, my guess, based on the information provided, is that you are having trouble synchronizing the start of a lighting cycle with the start of data acquisition (for loop). If you know that the for loop ALWAYS starts execution when the next trigger will be for red lighting, then you can reasonably guarantee the order of samples after that point.

I know this isn't really a solution to your problem, but it is hard for me to offer any further advice without having more details about how you are implementing your described design.

Best,

Duncan W.

[Ellie90]

Hi Duncan,

I trigger the camera in hardware.

The blue/red signals are synchronized with my triggering signal, but not with the start of my for loop. All the signals start at exactly the same time before the execution of my for loop, and there is a "Is the Task Done?".vi in the for loop to allow the signals generated continuously. Your guess is correct - my question is how to synchronize the start of the signals with the start of data acquisition to make the program "a good DAQ program design". Let me know if there is anything unclear!

Thanks,

Ellie

[RavensFan]

Acquire the trigger signals as well as the data acquisition signals.

[Ellie90]

Sorry I am not sure what you mean. What is the data acquisition signals you referred to? What is next if I acquire those signals? Thanks!

[DuncanW.]

Acquiring the triggers and using them as a reference for your software execution is definitely one implementation that would work. I'm not sure that you need a system that complicated for this application though.

It seems to me, if you are triggering the camera in hardware with the same signal that is transitioning between lighting, then the samples coming from the camera will have the same ordering as the lighting. That is, if you alternate red, blue, red, blue, then the camera samples will be red, blue, red, blue, even though you are retrieving them (reading) at a later time in program execution. I'm assuming that your hardware triggers are triggering a sample, in which case it doesn't matter when you pull them out of the buffer, they should always display the same ordering as your triggers.

Duncan W.

[Ellie90]

Hi Duncan,

Sorry for the late reply. 

The trigger for the camera and the signals to transition between light are three different signals - signal 1: camera trigger; signal 2: blue light on/off; signal 3: red light on/off.

Unfortunately, every time I retrieves the signals, they are at some random positions. I tested it by putting a "DAQmx read" vi in the for loop and read the signals at each loop. Below are two pictures showing the signals I read in the for loop at two time points, and they are apparently different. Loop 1: when camera reads the first rising edge of the trigger, it is blue light on, so the first image is blue light image; loop 2: the first rising edge of the trigger corresponds to the red light on, so this time the camera will acquire the red light image first.

I am not sure what you mean by "triggering a sample". When I generate the signals with DAQmx write, it is set to generate continuous samples with regeneration allowed. Is that "triggering a sample" you mentioned? 

Please let me know if I didn't put anything clear. Thanks for the help!