detect trigger event

[Tomi]

Hi All,

I would like to detect the trigger event, and measure the time between them in 1ms accuracy to calculate the frequency. For first trial I use PCI-6251 DAQ card and a modified  sample vi from NI "Gen Dig Pulse Train-Finite-Retriggerable.vi" but until now I have no success.

The results do not indicate the real trigger frequency. This method is improper. Can anybody suggest how to do it?

(The main goal is to generate a triggered pulse train, but the initial delays and the output frequency will depend on the previous calculated trigger frequency. This  pulse train will be the clock signals for the digital signal output series.  The trigger frequency can vary in range of 2-8Hz).

(Win XP SP2,  LV7.1 )

Regards

  Tomi

[Tomi]

Hi,

It looks that the task done property and the Wait until done.vi poll the DAQ in 100ms loop. This causes me the problem. Is it possible to set this cycle time to shorter? Or somehow to detect the hw trigger as event?

Regards

Tomi

[K_Dinnes]

Hi Tomi,

since You want to change the frequency and the initial delay during the execution of the VI, you have to clear the task and to create it again. This cause a software delay between all cycles.

In this example I use a counter to measure the trigger frequency. Since PFI 9 is the Gate of Counter0 (which is to use for the frequency measurement), I choose PFI 9 for the Trigger Channel. The frequency of the pulse train depends on the frequency of the trigger.

I hope this helps

Thanks

Klaus

[Tomi]

Hi Klaus,

Thanks for your response. I tried to use your vi but this is not that what I am looking for. My problem description was not detailed enough. What I want to achieve is shown in the attachment.

For this I created a finite samples digital output port and wrote the samples to the DAQ card by DAQmx Write. Due to the card cannot trigger the digital output generation I use one counter output as clock source (1MHz finite pulse train, triggerable with initial delay) for the digital output. The initial delay ("tc" on my drawing) depends on the trigger frequency and a user coefficient ("k"). And this is that point what I cannot manage. I cannot implement a frequency measurement simultaneously with the other DAQ tasks.

Additionally I have to stop and restart the triggered pulse train task to get the initial delay again, after the the previous trigger occured. Unfortunately the task is done vi has a very long "execution time" (100ms). This prohibits to implement any software solution to detect the trigger in proper time and restart the task.

May the used hardware DAQ PCI-6251 has no enough resources? Or the limited knowledge on DAQ at my side is the real problem and this is why I cannot figure out the way to the solution? That is the reason asking the forum for any help.

Best regards

Tomi

[Kevin_Price]

I'm not near a LV pc to look at or test code now, but I'll take a shot.

The main problem seems to be that you're using up both your counters to generate the retriggerable pulse train and there aren't any left for freq measurement.

You could set up a dummy AO task solely for the sake of using its sampling clock for timing purposes.  If it's possible to make it retriggerable (I'm not sure about your board and/or most recent DAQmx version), you're almost done.  Just set it to be finite sampling, and configure your DO task to use the AO clock as a timebase.   This will reserve your counter to do the job of measuring incoming frequency.

A more complicated possibility would be to make the AO task continuous with "pause triggering."  Then you setup one counter for retriggerable single pulses with the right delay and duration, and use its output as the "pause trigger" for the AO task.  This will cause AO sample clock pulses to occur only while the single pulse is high (can be configured for active low instead, if desired).  That still leaves the other counter free for measuring the incoming freq.

Hope this helps point you toward some possibilities you can check into...

-Kevin P.

[Tomi]

Hi Kevin,

Your suggessions are really worth. They opened my eyes. Based on your second proposal I could build up the requested tool with "dummy paused AO task" for clock source of the DO.  And I have learnt a lot...  Great.

Many thanks, best regards

Tomi

Message Edited by Tomi on 10-27-2006 06:59 AM

Message Edited by Tomi on 10-27-2006 07:00 AM

[Kevin_Price]

Good, glad it helped.  By the way, another key reason I suggested you use a dummy AO task rather than a dummy AI task is that it's possible to change an AO sample clock frequency on-the-fly without stopping the task.  AI tasks don't allow this, at least not the last time I looked into it.

-Kevin P.