Tabular AO Data

[diarmaede]

I need to send out two analog output voltages every millisecond, one on each of two channels. These values will come from a CSV file which I will read as an array of doubles during initialization. Is there a way to set up an analog output task that will read the whole table, then send out the AO voltage values sequentially? When the task gets to the end of the array, it should start again from the beginning.

I can do this by sending out single AO values in a while loop, but it would be slick if there were a way to automate it.

LabVIEW 2018 standard

Windows 10

Thanks!

[Kevin_Price · Accepted solution]

Sure, easy peasy.   That's exactly what a continuous AO task wants to do - generate all the values you write to the buffer and then start over from the beginning, indefinitely.

I made a few simplifying mods to a shipping example for continuous AO to illustrate.  You'll be prompted for a tab delimited text file of the AO values.  I'm assuming each AO channel is a distinct column in that kind of Excel-compatible text file.

-Kevin P

[diarmaede]

Too darn easy! Thanks, Kevin. That's perfect. Cheers!

[diarmaede]

A related question - Is there a way for me to put up a graph of the actual AO command values being generated? Thanks.

[Kevin_Price]

Do you mean live, in real-time, WHILE they're being generated?  Or just a one time dump of the waveform you *intend* to generate so you can visualize it?

-Kevin P

[diarmaede]

I was hoping for real-time, as they were being generated, but after pondering the situation, I am thinking that's not likely. I'd be happy if you proved me wrong.

[BertMcMahan]

It depends on how "real time" you want it to be. You can't update each one per millisecond (your monitor can't even update 1000 times a second) but you can do it in batches. Updating at 10 Hz won't tax your system much at all and would be a simple visual representation for your user. Just note that the output is buffered, so when you write to DAQmx Write you're actually filling up the buffer, which is being emptied by your DAQ card. Thus, the voltage doesn't appear on the actual pin the same instant you write the value to DAQmx Write.

Kevin may know of a way to use property nodes to see where in the buffer your device is currently reading from but I'm not sure how to do that. IIRC the last time I looked it wasn't possible to determine *exactly* what value was written to the AO port.

I'd probably just disable regeneration and write sections of data to the device in a loop. See the "Continuous AO (no regeneration)" template for an example of this. Each time you write to DAQmx Write, just plop that data on an indicator.

If you have analog input on your device you can do it another way as well. You can actually specify an analog OUTPUT terminal as a source for an analog INPUT read to see what voltage you're currently outputting. You could do software timed reads in an AI loop and update the on-screen value immediately. Note you might get some weird time-related behavior if you're using software timed reads with a plot. It won't be a problem if you're just displaying a single value. If you're plotting, I'd just set up your AI task to read continuously at 10 Hz or so and append each value to a chart.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kGDISA2&l=en-US

[diarmaede]

10Hz update is more than enough for my application. Thanks for your help!

[Kevin_Price]

In fact I *don't* know of any DAQmx property you can query to find out what AO value is being generated at a particular moment.  I've wanted it for quite a while though.   There are some things you can do to partly control and estimate how much buffer latency there'll be and so on, but it'll still be inexact and unlikely to be worth the effort.

That said, both of BertMcMahan's ideas are plenty workable.  Since you're pretty new to this stuff, I'd probably recommend his second approach.  That lets you leave AO in regeneration mode, closing the door on some possible issues that can come up when you disable regeneration and are then required to continuously feed the buffer.  You should still check out the non-regeneration example he mentioned, get a feel for it, see how it fairly easily *can* be done.  But as he pointed out, that approach will display the data as it *enters* the buffer.  There could be several seconds latency before the data works its way through the buffer and becomes an actual AO output signal.  So your data display becomes a little bit of a fortune teller, showing what's *going* to happen sometime in the future.

The AI measurement approach can easily show you exactly what the AO signal *actually* was during a fraction of a second ago.  For example, if you also set AI sampling for 1000 Hz and read 100 samples per iteration, you'll loop at 10 Hz and always be seeing the most recent 0.1 second worth of output signal.   It's much more likely to be near-real-time than the first approach.

-Kevin P

[diarmaede]

Sounds good. I'll experiment with the various options to see what works for this application.  Thanks.