reading analog output channel (or effector) synchronously with analog input channels into arrays in parallel loops

[zipmanx]

Hi Eric,

If i understand correctly, i don't think that "So the problem is with reshaping the multiple channels into a single array."

From what i can tell, the while loop indexes the value of the output voltage and the stream of analog inputs into their respective array entries. If i then have the code reduce these array entries (say rows 'n' of the arrays), before flattening the 2D arrays to 1D.

As it's working out, the indexing of the while loop is providing the synchronisation of the voltage output and voltage inputs i need to reduce the data. In other words, the first loop provides the first entry for the output voltage, a single value, while the continuous acquisition provides the, say, ~ 1000 or ~10000 data point per voltage channel at the 10 or 20kHz sampling rate that is read at that particular output voltage value.

So maybe that's what's causing the problem of zero insertion?

If you wanted to record multiple voltage channels at a high sampling rate (20kHz), then change an output voltage at the end of each loop iteration, and know at which output voltage those input voltage recordings occurred, all while recording continuously, what would you change or optimise?

thanks again...

[Beutlich]

If you wanted to record multiple voltage channels at a high sampling rate (20kHz), then change an output voltage at the end of each loop iteration, and know at which output voltage those input voltage recordings occurred, all while recording continuously, what would you change or optimise?

I would model it after one of the examples in the NI Example Finder: Hardware Input and Output»DAQmx»Synchronization»Multi-Function»Multi-Function-Synch AI-AO.vi except I would do the AO more like the community example Generate DC Voltage - Software Update. But it sounds like your DAQ is operating as you expect, so don't fix what's not broke . I don't see anything obviously wrong with any part of the code you highlighted in Message 18 or 19, but if you probe the wires and step through the data flow you should be able to see where and why the zeros are added.

If you find a particular transform that is not clear, maybe you could make a copy of the data in and data out, and a separate new VI with just that code segment, and we can narrow the focus of our discussion (your big mass of code is somewhat daunting). You can save the data going in or out a few different ways: creating indicators, executing the code, and then Right-Click»Change to Costant, and then the constant will maintain the value between copies/saves; or when you create an indicator and execute code, you can change to control and set that value as default. Whatever works for reproducing the unexpected behavior in a smaller piece of code would help the forum readers (and me!) understand the issue and provide feedback.

[zipmanx]

Hi Eric,

A probe with a waveform display on the input voltage wire within the while loop does not produce any zeros that you can see...

The only trouble i see with the input/output examples you've given is that i need to index the pieces of input data with their coincident output voltage to properly reduce the data. Indexing on the while loop tunnels or using the queue permits this.

It looks like i'd have to change this example, LabVIEW 2010\examples\DAQmx\Synchronization\Multi-Function.llb\Multi-Function-Synch AI-AO.vi, to produce a square wave of different high and low amplitude periods for our application.

I'll try a code snippet to try to narrow down more where the zeros (or zeroes?) are coming from, but i'm thinking it's a subtlety in the DAQmx input configuration here.

I'm also finding that the voltage output always runs at the beginning to the loop with this reorganisation, rather than at the end. I presume this is the desired behaviour? I'm thinking i could enforce this by putting a sequence over the time with a start task inside it, but then i'll have to put a stop task following the output, if i want the voltage change to occur at the loop end. Does that sound right?

[zipmanx]

I've made the zeros disappear:I was preparing the next version of the VI, with file streaming rather than this stacked sequence stuff, as it is described in the labview for everyone example,

I'll have to double check this with my for loop substitution in the place of a Queue to be sure, but it seems like the problem was a "memory leak" or that the arrays got too large in memory for Labview on WinXP Pro SP3 x86 to deal with perfectly. It also seems independent of a deprecated (?) file operation VI with this icon:

Which is in the path,

National Instruments\LabVIEW 2010\vi.lib\_oldvers\_oldvers.llb\Open_Create_Replace File.vi

I think this is a pre-labview 8.6 VI, but i can't tell because Labview indicates the compilation version is 10.0.

 So, after all, it looks like everything is working, except that i'm getting a queue error:

Error 1 occurred at Dequeue Element in DumbbellHairpinUnzipManualOFCNEW_Force_jump_KPN_moveTrap1_QueueWithFileStreaming.vi
Possible reason(s):
LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.=========================NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

I've attached the code snippet i made.

[zipmanx]

Strangely enough, it appears that indexing into a For loop causes no problem. I added file streaming like so,

And my output comes out ok,

no zeros.

[Beutlich]

This looks great, glad it is working. Note that the data collection and processing is sequential instead of running in parallel. The indexed tunnel will store all of the results from the data acquisition until the data completes, and then send all of that to the for loop for processing each element. This can be an issue if you collect data for a very long period of time, but since it works within the scope you need it to operate then it is an excellent solution.

[zipmanx]

Hi Eric,

I understand tha the data collection and processing is sequential rather than parallel. That's what permits the attempt at synchronising the voltage out with the acquisition of analog voltages.

I have been tweaking the VI, but i can't get rid of a 1 to few ms delay i'm seeing in my data. Is there anyway to do this without triggering?

Right now the voltage out flip occurs after a 1 or more ms delay from the start of the while loop iteration. I need it either at the very end or the very beginning. any recommendations?

I'm also getting two Queue errors, which i'm not sure how to solve:

Error 1 occurred at Dequeue Element in DumbbellHairpinUnzipManualOFCNEW_Force_jump_KPN_moveTrap1_QueueWithFileStreaming.vi

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

---------------------------------------------------------------------------------------------------------------------------------------------

Error 1122 occurred at Dequeue Element in DumbbellHairpinUnzipManualOFCNEW_Force_jump_KPN_moveTrap1_QueueWithFileStreaming_ConstForceLinRegion_nojump.vi

Possible reason(s):

LabVIEW:  Refnum became invalid while node waited for it.

[Beutlich]

If you want time resolution on the order of milliseconds or better, then you want hardware timing, i.e. triggers. If you use a search engine to research about Windows Timing, you often see discussions about how to deal with the 10-15 ms resolution with the system clock. Getting better speeds, like speeds at the rate of the processor, generally requires interacting with the lower level system components, and can be quite complicated to get a little more resolution from the computer clock. There are different solutions to side step this depending on what kind of timing you are looking for, but in your application triggers are going to be a valuable feature if you need 1 ms resolution.

I thought you stopped using a queue and used sequential processing instead (an indexed tunnel between loops). I would not expect to see any queue VIs in your code, and if you have any strays left over, they may be throwing errors because the queue was not setup. Are you still using a queue somewhere else in the code?

[zipmanx]

Hi Eric,

To answer the last question, i did try using sequential processing instead (an indexed tunnel between loops). and this returned the same behaviour, except for the queue error.

Recently i've been running measurements at much high sampling rate (50 to 200 KHz) instead of the original 10KHz to examine the response in our optical tweezers system. I've found that at 50KHz i will sometimes find a lag between the outputted voltage and the inputted data of up to 10ms. I presume that the available CPU time varies and that this may lead to sluggishness on the part of labview, though it's not clear what introduces more cpu use, maybe the Anti-virus. A simple VI i wrote that uses IMAQ for simple aquisition: to watch the camera input uses up to 30 to 40% of the CPU time on our Core2 duo E6400, intel P965, 2GB DDR2-1066MHz, Win XP Pro 32bit, RAID-0 on SATA 3Gb/s 7200pm hard drive pair, running labview 2010 sp1.

Most of the voltage jumps are synchronised within 0.2 or 0.3ms, which is good for our purposes.

Would you know how to trigger the start or stop of a while loop based on the value of an analog output voltage? The catch is that this analog voltage has to be changed with each loop iteration between two values.

This is kind of the idea of the VI, but with continuous acquisition where the analog out is segmented with the analog in for synchronisation.

[NIthan]

Hello Zipmanx,

When you say you want to trigger the start and stop of the loop, do you mean that you would want to essentially 'pause' the while loop, and then have it continue, or completely stop it? A good method for triggering can be done using the DAQmx Trigger.vi, and an overview of some synchronization techniques can be found here: http://zone.ni.com/devzone/cda/tut/p/id/4322. I hope this is helpful.

-Nathan H.