Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Trigger Delay with external sample clock

I am using a PXI-6115.  I am using Ctr0 and a CO Pulse Freq task to provide a clock to an external device.  I also want to use this as the reference clock for an Analog Output task which I have configured to start on an external trigger.  I set the AO task up using the Sample Clock timing with the source set to Ctr0InternalOutput (is this correct?).  I want to delay the start of my analog output from when the AO Start Trigger occurs.  I tried using the Start.Delay property of the DAQmx Trigger node, however, I get an error stating "Start trigger delay is not available when an external sample clock source is specified. Change the sample clock to onboard clock, or do not configure the start trigger delay."

 

Is there another way to achieve this? 

0 Kudos
Message 1 of 7
(3,806 Views)

This is a little indirect, but I think it oughta work.  However, it depends on using Ctr1 which won't be available if your Ctr0 output task needs to be a finite pulse train.  If Ctr0 is (or can be) a continuous pulse train, here's the idea:

 

We're going to use Ctr1 to intercept and delay the AO start trigger.  Ctr1 is configured as a triggered single pulse, triggered off the signal that you used to define as your AO start trigger.  It'll probably be easiest to configure the pulse in terms of time rather than freq.  The normally-optional 'initial delay' setting is crucial here.  Then you would configure your AO task to use Ctr1InternalOutput as its start trigger.

 

If you can't free up Ctr1 but your AI system is available, I may have another idea...

 

-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 7
(3,794 Views)

Kevin, thanks for the reply.  The problem I have is that the external device I am connected to is looking for the AO_StartTrigger coming out on PFI6.  It expects that trigger to be asserted N numer of clock ticks before the 1st data output.  I think, if I understand what you described, what will happen is that the AO_StartTrigger will occur after the delay (is this correct?).  What I need is for the trigger to be asserted and then the delay.  I am sorry if I didn't convey this in my previous post.  Am I correct in thinking that if the sample clock was internal that by using the Start.Delay property the AO_StartTrigger would be asserted and then the delay would occur?

 

Again thank you for the reply

0 Kudos
Message 3 of 7
(3,787 Views)

I haven't used the Start.Delay property on a triggered AO task, so I can't vouch for how it might behave with an internal clock, but your thoughts sound sensible to me.

 

If I understand the other stuff correctly, I still *think* we can get you where you need to be.  I'm supposing that some external signal is wired to PFI6 where you are currently using it to trigger the AO task.  Another external device is *also* wired to PFI6 to use that same signal to trigger or sync or whatever.  You want the external device to receive that signal immediately, but you want your AO task to delay a bit before using the external clock to generate samples.

 

Have I got it?  If so, then I think you just need to realize that an AO task can be triggered from other sources besides PFI6.  PFI6 is simply the default.  You can configure the AO task to use something else, such as the output of Ctr1.  That way the external device still sees the signal at PFI6 when it should, but your AO task won't receive its triggering signal until after the delay built into the Ctr1 output task.

 

I haven't used the E-series boards in a while and I recall that the signal routing has different restrictions than the newer M-series boards.  If you're unable to route directly through software config, there will almost certainly be a way to route with jumper wires in the terminal block.  Another little "trick" I used to do regularly on E-series boards under traditional NI-DAQ was to send a timing signal up to the RTSI bus from one task, and then pull it down from the RTSI bus with another task.  This gave me MUCH more flexibility in routing, though I kinda suspect DAQmx might figure out how to do that stuff automatically.

 

-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 4 of 7
(3,782 Views)

Kevin, thanks again for the response.  I do not have any external device connected to PFI6 which is providing the Start Trigger.  What I have is an external device which is looking for the Start Trigger coming out of my DAQ device on PFI6.  Therefore, what I am looking for is the AO Start trigger to be asserted when my AO task is started but delay the actual output.  I think that this works as long as I do not use an "external" sample clock for my AO task.  However, I would like to use my Ctr out task as the source of the sample clock.  The S series documentation states that "several other internal signals can be routed to the sample clock".  I have tried routing the Ctr0InternalOutput to the AO sample using the DAQmx Connect Terminals.vi but I can't seem to get this working either.    

0 Kudos
Message 5 of 7
(3,736 Views)

 

Are you nominally at 0 volts output before the trigger?  If so, couldn't you just put a few extra AO samples of 0 Volts in the beginning to act like a delay between the AO Start Trigger signal and the generation of the waveform you *really* intend?

 

-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).
Message 6 of 7
(3,716 Views)

That is what I have done, I just thought that after reading thru the documentation that I could route the internal Ctr0 output signal to the sample clock of the AO task and use the built in Trigger Delay but I guess not.  Thanks for your help

0 Kudos
Message 7 of 7
(3,687 Views)