Single Sample Analog Output without using the analog input clock for a hardware timed loop?

[argolds]

I am trying to output single samples from a PXI-6733 at the time of the board's sample clock.  However it looks like the samples are output at the instant they are written using DaqMx Write Analog Wfrm NChan 1Samp.  It is not waiting for the time of the analog board's sample clock.

It looks like I would need to use a hardware timed loop, but for some reason, the loops can ONLY use the sample clock from an analog input channel.  My problem is that the analog input channels on my PXIe-6536 all need to run at a completely different sample rate (much faster) from the Analog output channels.

Is there any way to get single sample output to wait until the analog board sample clock or to get a timed loop to use a different clock (say from my 6682 or 6674 cards)?

Thanks

[Kevin_Price]

Have you tried "HW-timed single point" for the sample timing mode?    The 6733 is a pretty old board, but I think it might support that.

Otherwise, it sounds like you've configured your AO task in immediate, on-demand mode which is what you get if you never make a call to configure DAQmx Timing.vi

-Kevin P

[argolds]

Thank you Kevin:

I am using HW Timed Single Point but if I set that value on the AO task, I get an error (the documentation states that only an AI task can HW Time a loop).  To get it to work, I have to set up a task using an AI task but, like I said, I need that task to have a much higher sample rate.

I will check to see if I am calling DAQMX timing.  I think I set the properties using a property node but may not be making the call.  I'll check but it will take a while to set up an experiment to see if that works.

[argolds]

As a follow up, I am now calling DAQMx Timing (Sample Clock) with "Finite" mode and  the samples are still being output as soon as they are written.  If I try "Hardware Timed Single Point" mode, DAQMx Timing.vi throws an error (as explained earlier, this is using the AO task).

So it looks to me as if only a hardware timed loop using the AI sample clock will work.  I really hope someone has another idea.

[Kevin_Price]

[Edit: Oops, started the reply then returned much later to finish.  After posting, I saw a subsequent reply from the OP.   More at the bottom.]

I think we're talking about slightly different things.   You seem to be talking about using a TImed Loop structure.   I was talking about "hardware timed single point" as a sampling mode that can be wired into the call to DAQmx Timing when configuring a task.  

What's the big picture here?  What kind of AI rate and AO rate do you need to support?   Why the need for hw-precise timing of the AO samples?   

A very simple scheme to get you *close* would go like this:

Let's suppose you have an AI rate of 10 kHz and an AO rate of 200 Hz.  Use a *normal* While loop whose timing is controlled by requesting 50 AI samples per iteration.  That'll make the loop iterate at a nominal 200 Hz.   Immediately after reading the AI samples, write your single AO sample.  Do this with an AO task in immediate, on-demand mode (no call to DAQmx Timing before the loop).

That'll give you an *average* AO update rate of 200 Hz.  It'll vary above and below, but it'll average 200 Hz in the long run.  Once you have something like this functioning, you'll hopefully be in a better position to evaluate the need for more nearly perfect AO timing.

-Kevin P

[Edit: can you post your code?  I was able to configure hw-timed single point AO on a simulated 6733 board without an error.   I'm also not clear on the value of syncing the AO to the sample clock on the 6733 board unless you're also carefully hardware-sync'ing the 6733 to your AI board.

    Also, are you running under Windows or under Real-Time?  Further, is it correct to assume that the AO is a control signal that must keep being calculated on the fly as you run this application?] 

[argolds]

Kevin:  Thanks for trying to help:

I can wire "hardware timed single point into the DaqMx Timing.vi but it does not seem to make a difference.

Here is the big picture, and it is something fairly new:  I am creating dynamic multi-band oscillators using state-variables.  From these, you can create dynamic signals that can be varied in real time (I am a smart-grid researcher at NIST)  Using the basic Xdot = AX + Bu and Y = CX + Du, I can create dynamic signals such as damped oscillations that are often seen in the smart grid.  u(t), the forcing function, is fed back into the oscillator from some kind of Smart Grid monitoring device such as a PMU or a microgrid controller.  The eventual goal is to use hardware (FPGA) to be able to control the signal output on the microsecond level but for now I am doing it all in LV software as a proof of concept.

So what happens is: in a loop, an output sample (actually 6 channels (3 voltage and 3 current)) is written to AO, u(t) is sampled at a much higher rate because of the higher harmonic content of the smart grid.  At present, using the AI sample clock, the best I can get right now is about 2400 samples per second due to the loop time required to generate the next 6-channel AO sample set.  I'd like to get 4800 SPS AO and 48,000 SPS AI and might be able to get that if I can find out what is taking the loop so long.

One final thing.  AI and AO are not done in the same loop.  I am developing a set of modular, IVI complient functions (e.g. Fgen, and Digitizer) that are completely independent of each other.  This lets other researchers (this will all be open-source) to develop their own test beds using these modules.  But you do have a good idea if I need to do it in the same loop.  My original question remains however: can I get the single timed samples out without having to use the AI sample clock at all?  It seems pretty basic and I would like to understand why NI does not seem to support it.  I wish I could see what was happening at a lower level in the hardware...

Thanks again.

[argolds]

The code is absolutely huge and extremely complicated!  Again, these are stand-alone IVI complient modules.  If could IM me, I'd give you a link to github so you could fork it, but there is a fairly steep learning curve to get it up and running (and it requires matlab as well).  It is GPS synchronized as well, (I have a stand-alone SYNC module based on an IVI inspired API) so you need two timing cards...

Some reference info on the pluggable modules are documented here:  https://pages.nist.gov/PARTF/html/moduleAppendix.html

It is a pretty deep dive!

[EDIT]:  I can build a simplified example of what works and uncouple it from the GPS synchronization, it would take me few hours...  But again it seems like write one sample ought to just output at the AO sample rate, not immediately..

[argolds]

Running under Windows on a PXI crate.  Can you send me YOUR code?

[EDIT} yet another note, these pluggable modules are hardware abstracted.  Eventually, other hardware made by keysight, OPUS, RTDI, etc could not be used to make this all work! 

[Kevin_Price]

Sure enough, that's a deep dive indeed!   It's quickly clear to me that my only chance to help is to keep focused on the very narrow topic of DAQmx, NI devices, Windows, timing, and sync.

1. You mention a limit of about 2400 samples per second.  Are you getting a 2400 Hz *loop* rate where you update a single AO sample (6 channels) each iteration?

2. Observation: I took the shipping example for HW Timed Single Point AO and modified it a little.  When running on my simulated 6733, it ran without erroring out but I was limited to 2 msec loop timing.

    However when I ran on real hardware (an X-series PCIe-6341), I was easily able to run at 5 kHz and more.  I used the newish function High Res Relative Sec to track actual loop iteration times and got the following:  (also see code attached at bottom)

3. To make sure it was really functioning, I ran a shipping example for AI and captured the quantized sawtooth waveform I was creating with the modulus function.  It checked out.

To be honest, I was very pleasantly surprised at how good the timing looked!  I didn't expect timing to be nearly so consistent under Windows!

Attached is a copy of the AO code, largely derived from a shipping example of similar name.  How does it do on your 6733?

-Kevin P

[argolds]

Kevin:

You are a real champion for taking all this the time to help out with a forum post!

A few  years back I decided to keep my 6 labview machines all at LV 2014 until some newer feature came along that I absolutely needed (if it ain't broke, don't fix it).  So I could not open the modified example.

But I did look at the shipping example (thanks for pointing it out).  It looks like what I was missing was the DAQmx Wait For Next Sample Clock.vi.  I'm guessing the DAQmx Write (... 1Samp) does unbuffered writes directly to the DAC which is running at some high speed output rate which holds the output until the next sample is written to it. (...NSample) buffers the samples which are written to the DAQ from some internal loop running at the sample rate.

The example shows what is in effect a hardware-timed loop using DAQmx Wait For Next Sample Clock.vi to drive loop timing rather than use a HW-Timed Loop (which, I still don't understand NI limited to ONLY use the AI Sample Clock.

I'll try this out in my code and get back to you with lots of KUDUs for you taking the time.  I'm truly impressed you go so far out of your way for the community.