Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Start trigger timing

Hi,

I am currently working with a DAQ 6356-BNC and have been running into problems with syncing my board with a separate CCD camera.  Both the camera and the DAQ are hardware triggered externally at 1 kHz from a laser and I would like the DAQ to begin taking data at the same time as the camera, each collecting some number (~10000) of laser shots.  The camera gives me a ‘fire’ output which gives a TTL gate while the camera is acquiring an image.  I am trying to use that rising edge to trigger my DAQ to start collecting data.  This seemed fairly straight forward to me (I’ve included an example of the DAQ triggering scheme that I am using), but there is clearly a difference in when the camera begins taking a series of data shots and when the DAQ does.  The best estimate I can give to the number of shots different (i.e. ms between when the camera starts and DAQ starts) is 10-20 but it doesn’t seem consistent or systematic.

 

Because I am still working with quite a number of parameters at this point (and problems very well might be arising from the camera not performing as I am expecting) I am just trying to check off possible concerns so my main questions are:

 

  1. Does my task initialization look correct for what I am describing?
  2. Is there a delay when using the ‘start on trigger’ action before the DAQ begins its operation, or will it collect on the very next timing trigger?
  3. Could the fact that I have a train of TTL pulses as opposed to a single pulse confuse the ‘start on trigger’ action?

Thanks in advance for the help!

 

-Zach-

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

1. Task config is a good start, might be missing a thing or two.  See below.

2. No notable delay, certainly not in the msec realm.

3. Pulse train won't "confuse" the trigger circuitry, but requires corresponding config.  See below.

 

Assumptions:

A. Camera takes 1 frame per external "trigger" signal (which in DAQmx is more properly termed an external sample clock).

B. Camera emits 1 "fire" pulse per captured frame.  So the "fire" pulses occur at the same rate as the external trigger, just slightly delayed for better sync with the camera shutter.

 

If assumptions are true, you could just ignore the "trigger" signal, and configure the DAQmx task to use the fire pulse as the external sample clock.  Then you can also eliminate the DAQmx Trigger config.  Another thing I'd suggest is to explicitly start the task before entering the reading loop.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 3
(2,608 Views)

Hello ZF-8014

 

You are configuring a finite samples acquisition inside a while loop which will not have the behavior you expect.

Please review the Voltage-Finite Input.vi example that ships with DAQmx. There you can take a look at the trigger configuration as well.

 

As a reference:

Tips and Techniques in Data Acquisition Triggering - NI-DAQmx

http://www.ni.com/tutorial/4329/en/

 

How Do I Use a Digital Trigger in LabVIEW to Start and Stop Acquiring Data?

http://digital.ni.com/public.nsf/allkb/BA775B0E445BFA79482571FE0032CCEB

 

Diego H

National Instruments

 

0 Kudos
Message 3 of 3
(2,595 Views)