Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How to synchronize retriggerable task with a second TTL signal?

Solved!
Go to solution

I have a retriggerable task (AI Voltage, Finite samples) that acquires 50 samples at the maximum sample speed (2 MHz for the USB-6361) whenever it receives a TTL pulse on PFI0. These TTL pulses come in a certain sequence that repeats, like this: ABCDABCDABCD. I would like to synchronize this task so that it begins on a specific TTL pulse, pulse A, which I can specify with a second TTL pulse on PFI1 that lines up with pulse A. Otherwise, the first pulse I get would be random, and I won't know if I have ABCDAB... or BCDABC... etc.

 

The main issue is that I would like the task to wait for a rising edge on PFI1, but only for the first trigger. After that, PFI1 should be ignored, and the acquisition should occur on rising edges from PFI0.

 

Is there a way I can do this, without lowering my sample rate from 2 MHz? I was considering making a second "dummy" task that waits for the signal on PRI1 and then stars up the first task via software, but I don't think that's very reliable, since these pulses (A,B,C,D) have spacings of  100-500 microseconds. My other idea was to put the PFI1 signal on an analog input port, but then my sample rate has to drop to 1 MHz, because I'm sampling two channels. Maybe someone knows of a proper way to achieve this.

 

Thanks for the help!

0 Kudos
Message 1 of 6
(114 Views)
Highlighted

I think we can make this work by generating the sample clock with a counter.  You can configure it to generate a retriggerable finite pulse train that the AI task uses as its sample clock.   I'd probably just make the AI task be continuous and split the data into groups of 50 samples after the fact.

 

Here's the important part.  The counter task can *also* be configured for a one-time "Arm Start" trigger.  Regular triggers get ignored until the Arm Start trigger (PFI1).  That arms the counter for action, after which it can keep retriggering on the regular Start trigger signal (PFI0).

 

If you have some control over these pulses, it'd be better to line up the PFI1 pulse with pulse D, and configure the "Arm Start" trigger for the *trailing* edge of that pulse.  Then it'll get armed and the next *leading* edge it sees will be pulse A.

 

The Arm Start trigger needs to be configured via DAQmx Trigger property node.  Search here and you'll find lots of further info.

 

 

-Kevin P

Message 2 of 6
(84 Views)
Highlighted
Solution
Accepted by topic author slourette

I had a few minutes while monitoring some equipment and thought I'd whip up a starting example.   Along the way, I realized another method might be a little simpler to deal with.

 

Instead of getting involved in the whole Arm Start trigger business, you could use a retriggerable finite pulsetrain as your sample clock, but then configure a 1-time trigger for AI from that PFI1 synced pulse.  It should all work out pretty much the same way in the end -- the AI task gets triggered just once by that special pulse, after which it will perform sampling as the counter task keeps getting retriggered.

 

Attached is a basic but (hopefully) working example in LV 2016.

 

 

-Kevin P

Message 3 of 6
(70 Views)
Highlighted

Thank you for your advice! I was able to get it to work using your example. This method fixed the issue with synchronization, but unfortunately it also introduced a new problem. I had been previously using the trigger "start delay" property in order to delay the acquisition trigger (the retriggerable one) with 10ns precision to compensate for signal propagation delays. When I try to do that now, I get "Specified property is not supported by the device or is not applicable to the task." I'm guessing there's a way to do it, but I don't know how to do it using the new method. Here's the VI with the error.

 

Thanks again for your assistance!

0 Kudos
Message 4 of 6
(55 Views)
Highlighted

You can do that a different way with the counter pulse train.   When setting up the pulse specs, there's an input called 'initial delay' at the bottom of the call to DAQmx Create Virtual Channel.  This is used as the time before the very first pulse.  All subsequent transitions are based on the freq & duty cycle params wired into the top. 

 

In the case of a re-triggered pulse train, the default behavior is that initial delay is used only for the 1st pulse after the 1st trigger.   Fortunately for you, you're using an X-series board which supports an option to use the initial delay parameter for the 1st pulse after *every* trigger.    Set the DAQmx Channel property "Counter Output->General Properties->More->EnableInitialDelayOnRetrigger" to True.  I think that oughta do the trick.

 

 

-Kevin P

Message 5 of 6
(51 Views)
Highlighted

It's perfect! Thanks for the help

0 Kudos
Message 6 of 6
(47 Views)