How to hardware trigger a loop?

[tomclark]

Hi,

I'm using a PCI6602 card to generate pulses for some high speed cameras, and a synchronised set of lasers.

The cameras require a continuous pulse train (500Hz). The cameras and lasers require a fairly complex set of trigger pulses (below).

A test is 4ms long and repeated every 2 seconds. it consists of the following triggers:

- laser 1: delay 500u then produce 1 pulse which is 500u high and 1999m low.

- laser 2: delay 2500u then produce 1 pulse which is 500u high and 1997m low.

- laser 3: delay 4500u then produce pulses at 2ms intervals until the end of the 2s (1998 pulses in total)

- camera 1: as per laser 1.

- cameras 2-5: delay 4500u then produce 1 pulse which is 500u high and 1995m low

So at the moment I have a loop in a VI around a set of DAQ Assistants which produce my trigger pulses then stay low for the remainder of 2 seconds. Outside the loop is another DAQ assistant which produces a continuous 500Hz signal to sync the cameras.

Note the time delay doesn't have to be 2s - just about that, and obviously consistent for all triggers.

Question number 1:

If I have 2 different DAQ assistants side-by-side in a VI, can I rely on their hardware to trigger at the same time, or do I need to define all the physical channels within the same DAQ assistant?

Question number 2:

I can get my trigger pulses working no problem. But, I need them all to be in sync with the continuous 500hz camera sync train - so that pulses don't slip into incorrect frames of the video or get lost between exposures. Is the loop in the vi programmed into the hardware at runtime, or is it software based which would cause slip?

Question number 3:

I have available (in the DAQ assistant) a 'continuous pulses (HW timed single point)' option. Can I generate a HW pulse at 2s period, to correspond with the camera 500hz sync, which sets off the trigger pulses? I have 2 concerns:

1. The period of the trigger sample must be less than the 2s period of the HW pulse, so surely an additional set of triggers will be started, not necessarily on the edge of the 2s HW pulse).

2. The problem is the laser pulse 1 - which is effectively gated low for the first two pulses in each 2s unit. The use of an initial delay to achieve this is not ideal. Does the 'continuous pulse HW timed' option restart the whole sample including the delay?

Question number 4?

Am I being a fool? I'm not very experienced with either labview or DAQs - so can anyone see a better way of doing this? The smartest solution would be to gate the laser pulse 1 but I can't work out how to create an and gate in the hardware....

Thanks for reading such a long post!

Kind regards

Tom Clark

[Kevin_Price]

1. Sorry, I can't speak to the behavior/limitations of the DAQ Assistant which I never use.  Because I've been programming NI DAQ apps since long before the Assistant showed up, I've always approached these things from the ground up with regular lower-level calls to the DAQ driver.

   From what I understand of your timing needs, I'm pretty sure it's possible to configure and program the 6602 appropriately using the lower-level calls.  I'm not nearly so confident that it'll be possible through the DAQ Assistant.

2.  Unless you are using an FPGA or something of that ilk, the loop (and the whole program) executes in software and is subject to the vagaries of OS and software timing.

3. I don't think I have a clear enough understanding of the signal timing you're trying to achieve to properly address these questions.  You may have supplied the needed info, but I don't have time available now to try to draw up the timing diagrams, etc.

4. No, you're not being a fool.  This sounds readily do-able with a 6602.  However, you're tackling a fairly complex problem considering your stated inexperience with LabVIEW and DAQ.  Let me suggest an approach:

A.  identify a master clock to be used by all your counters.  Let's suppose it'll be a 500 Hz continuous pulse train you generate with one of your counters.    Create a stand-alone vi for testing that'll let you interactively start and stop this pulse train.

B. Approach the other timing signals ONE AT A TIME!  Make stand-alone vi's that sync each of them up with your master clock.  This lets you build up your understanding one step at a time.  (Note: really, only laser 3 has unique requirements.  Note that it'll likely be a finite pulse train which will require the use of 2 paired counters.  The available pairs on a 6602 are 0/1, 2/3, 4/5, or 6/7.  All the other signals need only 1 counter and differ only in the parameters used for configuring.)

C. By the time you get individual signals sync'ed, you'll be in a much better position to decide how to merge everything into one overall app.

-Kevin P

[Robert.L]

Hi Tom

As this is a complex task with specific timing requirements I believe that you would benefit by using the approach laid out by Kevin especially if you are not experienced with LabVIEW.

Using the lower level functions gives you a greater level of control which you can capitalise on with your application.

If you look in the LabVIEW examples which can be found in the labVIEW help bar.  If you search for Pulse there is an example Gen Dig Pulse Train continuous vi. This will give you an insight into the structure to use the lower level functions. There are also numerous online recourses that can help such as the tutorials which can be found at www.ni.com.

I have place links below to recourses I believe you will find helpful.

<link no longer exists>

http://decibel.ni.com/content/docs/DOC-11729

http://decibel.ni.com/content/docs/DOC-12104

[tomclark]

Thankyou both, that's most helpful. 

Following Kevin's advice I decided to get serious and do it 'properly', and actually found the Gen Dig Pulse Train sample VI. I based my program around that (copied and pasted it several times!) and have finally got things working. It may not be pretty, but it's certainly close enough 🙂

Thankyou both for taking the time to respond.

Kind regards

Tom Clark