sync analog input with digital output trigger

[AEN]

I'm trying to output an analog signal from a file with samples at a specified frequency.  I also need a digital output to trigger a measurement at a specified frequency on a separate system.  The frequency is controled by the timed loop and outputs when the iteration number divided by the period is exactly a whole number.

Both outputs work.  The problem is they aren't synced.  The analog output rises about 0.5 ms faster than the digital signal.  (I'm checking with an oscilloscope)  They both start within the 1 ms each loop runs for, but I really need them to start at the same instant.  What can I do to sync them?  Also, If I'm going in the complete wrong direction, please indicate.

I'm using a PCI-6723 card, which I think someone at some point said didn't have a hardware sample clock.  Which is why I'm trying to use a software timed loop.

[John_P1 · Accepted solution]

Hi AEN,

You need to be using the on-board timing of the 6723 to accomplish what you want.  Since the Digital Output subsystem is software-timed only, a suitable solution should be to use one of the counters to output the pulse.

The attached code should show how to do this.  You can use the counter to output a pulse every N samples of the AO task.  The hardware requires the initial delay to be a minimum of 2 ticks, so the counter will be behind the AO task by 2 samples in this case.  There are various ways to work around this if you need to (e.g. write two samples of 0 first).

Best Regards,

[AEN]

That looks like it will work for the digital trigger.  I've got a problem with the analog signal though.  It looks like I can only output the first 1000 points in my file.  Changing the sample rate just changes how fast those 1000 samples are output.  Is there a way I can get around this?  I'm wanting to output several seconds of input at 1 Khz.  The five seconds of data isn't a waveform so it doesn't repeat.

[AEN]

Wait.  There's a samples per channel on the sample clock.  Nevermind.

[John_P1]

If set to "Continuous Samples", then the driver will repeat the same data until you stop the task.  If set to "Finite Samples" the driver will generate N Samples.  If this is bigger than your file size, the data will be repeated as necessary.

Best Regards,

[John_P1]

If you do want to switch to Finite, you'll probably want to make use of the Task Done? output from the AO Task as another option to break out of the loop.  I'd keep the Counter Task as Continuous (it depends on the AO task anyway).

Best Regards,

[ChristianKi]

Dear John,

I found your solution very helpful - this more or less exactly what I need.

( I am running WIN 7 with NIDAQ PCIx 6363)

I do need to generate a trigger signal out of my Analog Output as a reference (best case every positive zero-crossing)

The example is working so far, but my question is:

What happens, if I need the "Do not allow regeneration" feature, so I dont get "hopping phases" or peaks when I am changing the frequency during continous generation?

Obviously I can set it to change  the frequency of the counter accordingly, but what about the regeneration feature (the phase)?

best regards Christian

PS: I am happy for every other workaround (I already hard wired the AO to an AI; but then I have a significant drop in sample rate due to ghost talk)

[Kevin_Price]

Can you post your code?  It's helpful to "save for previous version..." so more people can open it.  I only work from LV2013 and LV2016 for example.

Some of your comments don't seem to make a lot of sense to me.  I don't understand your remark about AO phase where you seem to associate it with regeneration and with a changing counter freq. 

    Any of the built-in signal generation functions do a good job of maintaining phase through repetitive calls (as you'd need to do in non-regeneration mode).   Counter "phase"  shouldn't matter at all.  Only edges are used to drive AO sampling, what happens between the edges have no effect. 

    What have you tried?  What problems do you get?

Also, your comment about "ghost talk" affecting sample rate doesn't make sense to me either.   Do you mean you must lower the sample rate drastically to *avoid* ghosting of signals on a multiplexed AI task?

-Kevin P

[ChristianKi]

dear Kevin,

let's see If this file export worked.

_____________________________________________________________

Basically what I am trying to do is to marry the

http://www.ni.com/product-documentation/4322/en/#toc5   

by NI(figure4) with the example above.(Synch AO_CO.vi ‏42 KB)

AND

together with the example of NI  Cont Gen Voltage Wfm-Int Clk-Non Regeneration.vi

http://www.ni.com/example/30981/en/

_________________________________________________________________

but I fail big time since the last trys.

I have a AO0 for signal generation and and AI0 for measurement.

I tried just to wire the AO to a free AI1; but then I run into deep problems with ghosting, therefore I am looking for a more elegant solution onboard.

best and thanks for your help

christian

[Kevin_Price]

Since I don't have a really clear idea of what you *need* to do, I can only comment on things I see in the code that "look wrong."

1. You haven't really absorbed some of the key lessons from the link to "Timing and Synchronization in DAQmx."  There are several important aspects to getting sync right -- what signals to share, how to share them, and how to sequence the start of tasks.

2.  By and large, the AO task looks pretty good.  Triggering off Ctr0 looks like a problem however.  I suspect you could leave that out.

3. The CO task sets up Implicit timing (fine) but doesn't wire up the input for Finite vs Continuous sampling.  When unwired, you'll get 1000 pulses in Finite mode.

4.  The CO task seems to want to generate pulses based on the # of AO sample clock signals that have happened.  But you never define the pulse specs.  How many "Ticks" for high time, how many for low?

    Also, the CO task can't receive AO sample clock ticks until AO begins sampling.  But the AO task is set to trigger off Ctr0 output, which can't happen until enough AO sample ticks have happened for Ctr0 to produce a pulse.  This circular timing dependence will prevent both tasks from doing anything useful.

5. In the loop, you call DAQmx Write for your CO task, but you don't define what to write.  You also don't carry through the error output so will never know if there's an error.

    I suspect you shouldn't be writing at all.

6. Your AI task doesn't wire the top inputs to DAQmx Timing so you'll get the default of 1000 Finite samples.  But since the trigger signal can never happen, you wouldn't have seen that yet.

7. Your AI task is set to be retriggerable.  It appears you want to retrigger at certain points within the AO such as positive zero-crossings.  Given that, I wonder if you really want to drive the AI task with the AO sample clock.  It'd be more conventional to set AI to a faster sample rate than the AO it's measuring.

8. Your AI task is never explicitly started.  It should be.

Here's some mods I'd do, based on what I *think* you're trying to do.

- remove the triggering setup from the AO task

- make sure both CO and AI tasks are started before you enter the AO loop (where it gets started too).  The AO task drives the timing so it must start *last*. 

    You can do this with a simple data dependency - wire the error out from starting those tasks to the outer border of the AO loop.

- remove the DAQmx Write call to the CO task that's in the AO loop.

-Kevin P