How to setup AI to AO

[Skydyvr]

I know this is probably possible, I just don't know how to best go about doing it. I would like to write a program to sample a waveform off of AI0 and output that same waveform on AO0 real time (or as close to real time as I can get) - with the eventual goal of doing some processing on that waveform in between. But for right now all I am trying to do is create a program to do AI to AO.

The examples I have seen for doing simultaneous AI/AO have the output fixed while it samples data on the input. That is not what I want. I want to be able to spit out the signal that is present on the input ADC. Also when I try to modify the program, I get these long (5+ second) delays in between what is present on the input and what it produces on the output. I have tried increasing the sample rate and/or reducing the number of samples but that just causes errors – I’m loosing data because one process is taking too long to complete.

Is there a way to make a streamlined program to simulate an analog buffer?

Details:

NI Device: USB 6251

Software: Labview 8.5

Preferred Sample Rate: 40 kHz

Preferred delay AI to AO: < 0.1 second

I have no code started that I could post. I am wondering if anybody has done this or has an idea about how to do it, i.e. I need to use a queue to buffer data from the AI chain to the AO chain.

Thanks

Jim

[andre.buurman@carya]

I'm sure it can be done. If done two applications with the 6251 USB device. One outputting a continuous 100kHz signal that can be modified on the run without glitches and this one.

I think for starters a producer (AI)/consumer (AO) architecture using a queue will be good. Then all you would have to do is read data from AI and put it in the queue, get data from the queue and write is to AO.

Things to look at:
1. Driverbuffer size;
2. Driver initialisation (have a look at (this);
3. Time outs;
4. Timed loop (consumer and producer loop).


Message Edited by andre.buurman@carya on 06-16-2008 04:43 PM

[Neal M]

Hello Jim,

Andre is correct that our main concern here is going to be the buffer delay.  There are 2 other main delays that we need to be concerned about as well.  These are  software processing and USB bus transfer rates.  Andre's example for the output should work, but I believe it is a little more complicated than you probably need.  He is using a state machine architecture with an event structure, which is easy to expand but can be difficult to follow for a task such as yours.

The producer/consumer would work as well, especially if the processing you are planing on implementing is significant, but this too I think may be beyond your initial goal.  This is, however, a great way to get rid of "loosing data because one process is taking too long to complete."

The reason you are seeing the delay is most likely due to the buffer clearing out.  When you call the DAQmx write, it puts the data at the end of the buffer, so all the data ahead of it needs to be output first.  You can reduce this delay by using non regeneration (see the example program named Cont Gen Voltage Wfm-Int Clk-Non  Regeneration.vi in the Example Finder) and writing smaller chunks (samples to write).  The trick with this is you will get an error if you do not keep some data in the buffer that has not been written.

You also might want to get rid of buffers all together and use hardware single point timing for your output (instead of continuous).  This is when you write 1 point at a time to the card and it is output on the next hardware timed sample clock pulse.  You can use this in conjunction with the Wait for Next Sample Clock.vi (in the DAQmx Real TIme palette).  The problem with this is that because you dont have a buffer, you can only go as fast as you can write points (my computer could go about 500Hz if I did not do anything else at the same time).

The USB is a slower bus than, for example, PCI.  This means that it takes longer to get data to and from the board (there is a lot of overhead).  This could become an issue at the rates you want.

I hope this gives you some ideas.  Let me know if you want me to go into more depth about anything or if you have any questions.



Message Edited by Neal M on 06-17-2008 01:20 PM

[Neal M]

Jim,

One more thought...  You could probably do this easily at the rates you want with one of our R Series cards. They have FPGAs on them, so you could do your analysis/etc in hardware.  That greatly increases the rates you could do.

[Skydyvr]

Thanks for everyone's pointers. I will keep them in mind when I start to write a program to do this. As things typically go around here, I have other programs that have moved to the top of my list and therefore I won't be able to start on this right away.

I of course being the lazy engineer that I am was hoping that someone had already written a program that I could use to do this. There has been many times where I find it would be helpful to bypass and/or add processing to signals on my circuit boards without having to skywire a daughter board on to my PCB. Imagine how much easier design would be if I could sample a signal on my board, process that signal by using all of LV's filters or signal conditioning and then spitting out the signal back to my board real time. I could make all of the changes in Labview before having to go to hardware. I can't belive National Instruments hasn't thought of this potential usage for their DAQ cards. hint, hint...

[Neal M]

Hello again Jim,

That would be a very good Product Suggestion.  Please submit any feedback you may have,  these dont just go into the ether, we do look at them and use them in directing our R&D.

In addition to our FPGA stuff, we also have LabVIEW Realtime which takes windows out of the picture and lets you do things deterministically (and much faster).  I know I am starting to sound a bit sales-pitch-ish, but it sounds like it would work very well for your application.  Let me know if you want more info.