LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reconfiguring DAQ VI to support multiple real-time updating analog output channels

Hi Zach,

 

As the message indicates, error -200018 means:

"DAC conversion attempted before data to be converted was available. Decrease the output frequency to increase the period between DAC conversions, or reduce the size of your output buffer in order to write data more often. If you are using an external clock, check your signal for the presence of noise or glitches."

 

The reason that the simulated device works is because there is no physical DAC circuit compared to your DAQ device. What is probably happening is that the sample clock rate is causing data to be written out faster than your DAC can convert from the buffer. Your two options are to either decrease your sample clock rate, or decrease the buffer size so that the DAC converts faster. It's more of an art than a science to reach the correct balance between the buffer size and sample clock. Keep in mind that you don't want the buffer to be too small, or you could run into other errors because your loop will run more often. Play around with that and see if you can get the error to disappear.

 

Mark M.
Applications Engineering
National Instruments
0 Kudos
Message 11 of 16
(657 Views)

Hi Zach,

 

I wanted to also answer your question regarding only being able to change the properties of one waveform. This makes sense that you are only able to change one of the waveforms, as it is exactly what the code is doing. The code simply takes a duplicate copy of the waveform and adds it as the next element in the array.

 

If you'd like to be able to modify each individual waveform before outputting to each channel, I'd suggest two steps:

  1. Either modify your code that you posted to work with an array of waveforms, like the first example that you posted. Or, modify the code from the first example to slow down the write task like in the second example. Remember, the main difference between the two examples that you posted is that the second example keeps track of how much data has been written to the device, and slows down the write task so that the amount of data in the buffer stays small.
  2. Also, consider using a producer/consumer design to generate the waveforms in parallel to the code that is writing the waveforms. This will reduce the time that your processor will take to generate the waveforms for multiple channels.

Do keep in mind that the speed at which you can update will still be limited by the hardware itself to some degree.

 

Regards,

Regards,

Michael Whitten
Senior RF Applications Engineer
Message 12 of 16
(632 Views)

Hi Mitten,

I went ahead and tried to modify the first example I posted about to adjust the write function, but my code ended up producing very strange results. The waveform graph produced in the VI window appeared to correctly correspond with my waveform characteristics that I had specified, but the waveforms produced were the product of the waveforms added together. I had a sine wave and cosine wave combine to produce weird "horned" shapes on my oscilloscope, and I'm not exactly sure why. I think it has to do with how I keep track of the data being written to each waveform on each channel, and how I compare that prior to the write function. I've attached the newest version of the code below.

Thanks for your detailed advice,

Zach

0 Kudos
Message 13 of 16
(616 Views)

Hi Zach,

 

Can you explain what you are doing with the part of the code reading the phase of the waveforms? I don't quite follow what you are trying to accomplish. I think that this may be the issue.

 

Are you trying to make sure that the wave is generated to be continuous? My understanding is that the VI does that by default. 

 

Regards,

Regards,

Michael Whitten
Senior RF Applications Engineer
0 Kudos
Message 14 of 16
(601 Views)

This may be related to Mitten's question about Phase, but I noticed a input "Tunnel" on the While Loop with a diamond shape inside it.  Hovering over it I see "Initializer Terminal", something I'd not heard about, and can't find in LabVIEW Help.  What is this, and what does it do?  [I also noticed an unused Shift Register for a Boolean Array just above this terminal -- something really strange is going on inside this code ...].

 

Bob Schor

Message 15 of 16
(586 Views)

Aha, I get it (the Phase stuff referenced in the last two posts) -- the Original Poster does not understand how to use the Basic Function Generator, and doesn't understand how to use a Boolean Shift Register to handle initialization.

 

First, the Basic Function Generator.  There is a terminal on top called "Reset" that is designed to let you generate a single continuous waveform a piece at a time.  What you want to do is call it the first time with Reset = True so that it takes the properties of the waveform from its inputs, and for all subsequent calls, you want Reset = False so that it "continues from where it left off".  This is most easily done by having a Shift Register with True wired in from the outside that goes to this Reset Terminal, and with False wired from the inside to the output part of the Shift Register to make all subsequent values False.  You can use exactly the same trick to make the "Start Task" function fire only on the first loop.

 

But what if you want to do two functions?  Well, this Function Generator is a Pre-allocated Reentrant Clone, which means it will "remember" its settings from multiple calls.  So what you do is put two of these functions in, one for each of the two Waveforms you want to generate (and thus do not put them in a For Loop).  Now each Function Generator will "remember" its own setting, and you'll get two independent continuous Waveforms with very little effort!

 

Bob Schor

Message 16 of 16
(581 Views)