Simultaneous analog input and output

[JÞB]

Back with Example code

Attached: and ignore all the snippets (they don't preserve connector panes, relative paths or vi properties.

Here is what I did:

1 Created Display.vi  This vi is set to open FP when called. All the graphing code is here now.

This allows me to do some unusual things to the DAQ.vi in the attached project.

This vi is set with the execution properties as noted in the comment. Debugging is a resource hog Auto Error Handling likewise, And this vi is set to a high execution priority.  Elevating the priority was the driving foce behind getting the graphs in a seperate vi.  If that attached project doesn't work we need to punt and lower the sample rate.

[combo531]

So as it is now, it returns the same "-200292 error" about the buffer. I tried lowering the sample rate with no success above 15000, and If i lower it below 15000 it gives a new error. 

Error -200288 occurred at Stand Alone Optical Drive.vi

Possible reason(s):

Attempted to write a sample beyond the final sample generated. The generation has stopped, therefore the sample specified by the combination of position and offset will never be available.

Specify a position and offset which selects a sample up to, but not beyond, the final sample generated. The final sample generated can be determined by querying the total samples generated after a generation has stopped.

Attempted to Write Sample: 1002
Property: RelativeTo
Corresponding Value: Current Write Position
Property: Offset
Corresponding Value: 0

Task Name: _unnamedTask<56>

I changed the sample rate while leaving it connected to both DAQ functions. Would it be apropriate to lower the sample rate of the input and increase the sample rate of the output, so that the second process is always ahead of the first? Or is that what the above error is referring to, with trying to write a sample that isn't created yet?

[JÞB · Accepted solution]

That actually took some digging but, I think I know whats going on.  Refer to the LabVIEW  Help for the DAQmx Timing.vi and the NI-DAQmx Help on "Buffering".

The Timing vi Samples per ch is defaulted to 1000, we then reset the buffer size to 2 and the vi errors at 1002 (samples to write +buffer+1)

If we use any thing other than "Finite Samples" we need to preload data with a write (Autostart=F) then start the task and keep writing samples before the buffer empties.

Yet here we need to do everything PtbyPt.  And at a 15kHz or slower rate because of the required DAQmx state transitions.  (Or Do We?)

Spoiler

He's running me out of tricks guys feel free to chime back in!

As An asside a AO module that was Hardware Timed Single Point capable would work in this set-up perfectly about three tricks ago!

Lets try this- only because we are close.  

Again The Snip is only for referance for others Use The Attachment to test

See comments in the snip for why and what I changed

Orange comments for changes

Man I deseve a few kudos!

[combo531]

It runs! It reads and writes with no hang up or errors, but there is one last issue. I can change the input signal, say from 2 to 3 volts, and it will eventually read and output the correct values, but it takes about a full second to do so and in the meantime still reads noise variation around the initial 2 volts. So it isn't going to catch my 100-200 hz signals. But I don't understand how, because I re-enabled debugging mode to see and the read Daq function is at a racing speed, but it just isn't reading what I test it at and can see on the oscilloscope. Any Ideas?

If not, I will fiddle with rate values and still mark that last comment as the solution, because oh my goodness, I never would have figured this out. Thank you so much for all your work on this, I appreciate it immensely. 

[JÞB]

Disable debugging again. And get that top level vi reconstructed as a sub vi. The FP should not need to be in memory.

Seriously, I have been doing this for a decade and a half.  I learned a lot working with you.  Really nice posting! Give me a call if you need a job reference.