LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

synchronization - using DAQmx task as clock

Hello,

 

I recently started working on modifying a LabVIEW VI originally used to control a cmos camera. I've added DAQmx code that allows me to blink a pair of light sources at a set frequency while the camera is acquiring images at a with a set delay, such that one lighting source is active whenever the camera exposes. (camera running at 2x the frequency of the LEDs).In addition these images are being saved to disk (2d array -> .txt file.)

 

I've noticed that initiially the images I'm saving are initially in time to the lighting source blinks but after about 20 or so samples, the images start to fall out of sync (i.e two lighting source 1 images in a row, or an exposure between the two lighting sources.)

 

What is the best way to make sure these parts of the code stay in sync with each other? I've tried to use the DAQmx Create Timing Source function, but I'm not sure how to place that within my DAQmx code.

0 Kudos
Message 1 of 3
(1,302 Views)

I've added a demonstrative snippet of code to help illustrate what I'm doing better. The snippet doesn't work as is because including that prior code would be a visual nightmare (several layer stacked sequence structure.) 

0 Kudos
Message 2 of 3
(1,285 Views)

The Good News is that LabVIEW has (and uses) the concept of Time as a Language Feature.  The Bad News is that not all Time is Created Equal.  There is the Time that's related to the Time functions, based on the CPU clock and notoriously "variable" (as the PC is doing all kinds of things that add timing jitter.  There is the time that is built into many DAQ hardware devices, generally based on crystal clocks and generally precise (and relatively accurate).  Finally, there is the clock in cameras -- probably pretty precise, but not necessarily the same time base as the DAQ clock.  So if the Camera is running on one clock and the Lights/DAQ are running on another clock, they are probably not at exactly the same frequency (or harmonics), meaning they'll "drift", and if one is a CPU clock, it is not precise (so there will be jitter).  A big mess!

 

Here's a potential solution -- choose one (1) clock and use it for everything!  You don't describe your hardware (what is your DAQ device?), but if I were contemplating doing this, I'd go with the DAQ's clock and try to derive pulses to trigger the Camera as well as using DAQ Reads to time the VI Loops.  [I've actually done this with a little demo routine that gathers data from an accelerometer].

 

Bob Schor

Message 3 of 3
(1,259 Views)