How to delay and output trigger during retriggerable DAQ

[ceties]

I perform retriggerable data acquisition based on technique described here and as my starting point couple year ago I used attached example shipped with LabVIEW.

What I would like to achieve now is besides already done I need to delay recognized trigger and output it as a trigger signal for other device.

To make a simple schema:
Trigger is recognized->DAQ  [that works perfect alredy more than one year]
                                  ->wait 100ms->output the trigger  [has to be added]

Using WXP, NI PCI 6110

Thank in advance to anybody interested

Message Edited by ceties on 11-10-2008 07:21 AM

[Stefo]

Hi Ceties,

I believe that everythink you will need to do is to add Pause Trigger to counter which continuously generates pulses. You can find an example and more details in KB "Different Counter Retrigger and Initial Delay Behavior in Traditional (Legacy) NI-DAQ and NI-DAQmx". Another example should be posted in article "Retriggerable Finite Pause Trigger Digital Pulse Train Generation".

Let me know if you were successful

Regards,

Martin

[ceties]

Hello Stefo and thanks for your reply. Nevertheless, I do not want to delay the  data acquisition - I actually want my daq work the same as it works now. What I want is to generate an additional trigger (to some digital or analog output) certain amount of ms after the original trigger occured.

[sebastianbratescu]

Hi,

As I understand you want to generate another trigger with some delay in parallel with data aquisition.

I suggest the following approach:

1) Use the same trigger (a new read trigger) in parallel to detect when it comes to the board

2) Add a Flat Sequence Block and introduce a delay in the first step (frame) by using timing VIs.

3) In the second step (frame) of the Flat Sequence generate the output on the trigger

This should work fine and you can always check the examples in LabVIEW in Example Finder.

What you wish to search for is the simultaneously started aquisition for guidance.

Kind regards.

[ceties]

Hello Sebastian and sorry for my late response - I was working on other project.

I was trying to follow your advice but I don't exactly understand what you mean by "new read trigger". Could you show me that using the vi I posted before? And I was also wondering if there is way to do the timing on the hardware basis since I have like 5 triggers coming every second so delaying them by software could cause problems - is there way to program the board to do that?

Thanks for any suggestion!

[Stefo]

Hi Ceties,

Sorry for late answer. If everythink you need is to generate one pulse with initial delay each time you receive a trigger, then example located in

\examples\DAQmx\Counter\Generate Pulse.llb\Gen Dig Pulse-Retriggerable.vi

should work well for you. You need to use one counter to generate signal. You need to configure it to use trigger, and by property node you need to configure to start it retriggerable. According to KB "Creating a Delayed, Retriggerable and Finite Pulse Generator", if you use initial delay when you generate single pulse, it should delay your ouptput after each trigger.

Regards,

Martin

[Stefo]

Hi Ceties,

Were you able yo set up hardware-based, delayed trigger based on previous suggestion?

Regards,

Martin

[ceties]

Hi Stefo and thanks a lot. I will look at it at the weekend since now I work on onother project again. Then I will let you know! Cheers and thanks again

[ceties]

Hi again Stefo. I finally had some time to quickly glance on it. Your suggestion won't probably work since I use already both two counters on the DAQ card to perform retriggerable data acquisition based on technique described here.

What you suggest is basically the same in parallel to the acquisition but delayed and there is only one pulse produced instead. Nevertheless, it still needs two counters which I have blocked for the acquisition. In addition I am not sure if it would be possible to have two tasks running in parallel both linked to the same trigger input - I am afraid the NiDAQmx Vis don't support this kind of parallelism.

So I guess I will have to give up that idea...