LabVIEW
Simultaneous analog input and output
Solved!
@combo531 wrote:
Thanks for that, I fixed the rates. I know I cant expect actual "simultaneous" - my arbitrary waveforms will be on the order of 100 to 200 hz, and It is acceptable to have the signal lag behind by a small (less than 5 degree? unsure yet) phase difference. I can lower the metronome in the loop (or remove and place with a tiny wait function).
The main problem is simply that I keep getting errors like error -200452, where I can't write since there is an empty buffer. I've tried to add in "configure output buffer", but I can't figure out how to do so and actually have the program output anything.
Time to pull out some tricks:
Where the ugly subvi created from selection is:
Why did I create that sub.vi?
Inlined!
For something as slow as 20kHz you should be easilly able to achieve that rate unless the UI thread bogs you down updating those charts (You could remove them after tweaking Rank's Value)
Rank then sets the delay between In and Out the tradeoffs are Higher rank = better filtering and more delay
Since it had a problem with Hardware Timed Single Point, I tried changing both to either continuous samples or finite samples but then I run into:
finite samples seams reasonable (Wish that device could go HTSP) for both the AO and AI
Error -200462 occurred at DAQmx Start Task.vi:7220004
Possible reason(s):
Generation cannot be started because the output buffer is empty.
Write data before starting a buffered generation. The following actions can empty the buffer: changing the size of the buffer, unreserving a task, setting the Regeneration Mode property, changing the Sample Mode, or configuring retriggering.
Any thoughts on why these errors occur and how to circumvent them?
As a matter of fact I do. This is obviously the AO task. Replace the Start Task vi with DAQmx Control Task.vi and wire the input to a "Commit" That places the task in a state as close to run as possible and will really lower our overhead inside the loop. It should "Auto-Start" with the Write.vi write one sample and return to the commit state every iteration of the loop. Check here for a great peek at DAQmx State Transitions and Here for the duct-tape-required tour.
We should rethink the AI task and change it back to Contineous Acquision, sample rate = 20000 and Samples to read =1. Use a read 1ch n samp dbl The loop will pace with the AI having 1 sample available. Index the first element (there will only be one) run it through the filter into the AO write.
The trick here is we need to iterate faster than 1/20kSec so that the input buffer does not get a backlog (that will eventually throw another error) So, we need to have that loop doing nothing but DAQmx related stuff. So, Add a Queue! and queue the Raw and Filtered Doubles up for display elsewhere Use the trick found here Serendipity rides again of writing to the graph from a "flush queue" to limit the burden on the UI thread Flush it every 200ms or so.
You are really digging into my bag of tricks now aren't you
Actually not half bad! I'm a bit surprised by that error! The Wait was the worst of your mistakes. The DAQmx read will pace the loop. I fixed your queue datatype.
Give this a shot.
You May need to transpose the 2D array in the display loop. You'll know if the charts look really odd
I think it is almost there, the program would run for a few loop iterations (5 to 10) and would read and output, but it eventually hangs and gives this error:
Error -200292 occurred at Stand Alone Optical Drive.vi
I was afraid of that (and exactly why I set the output buffer to as low a value as possible.
Detailed explaination: What is happening here is two processes:
- First we are reading 1 value writing it to the AO output buffer and reading another value and outputing it to the output bufffer... at 20kHz
- Asynchronously. the AO task is Transitioning to the run state, reading the output buffer, initiating a D-A Conversion and finally transitioning back to the commited state. This process is not keeping up with the first process.
The some might think that increasing the size of the output buffer is the simple solution. They would be dead wrong! If the AO task cannot keep up with the AI sample rate the buffer is going to get fuller and fuller and the AI-AO lag will increase as a function of time.
Others would suggest using a Wait for Task Complete on the AO Task- They would be wrong too, This just fills the AI Input buffer and you will be reading data that was actually aqcuired some time in the past again, the AI-AO lag will increase as a function of time.
We need to do one of two things.
A: Speed up Process 2 (Prefered)
B: Slow Down Process 1
B. is easy as pie, lower the sample rate of the AI Task And we will use this as a "Fall-Back" option. A. should be attempted first.
Next Step. Wait...... I'm coming back with example code
