USB 6009 DAQ Weirdness

[Nick Moszer]

I've come across a strange problem with the USB 6009 DAQ. 

I'm using Labview 8.6.1 with NI-DAQmx 8.8.0.  The DAQ is configured as follows:

AI1 and AI2 are differential, continuous samples, -5 to 5V, 200 samples per channel, 2Khz sample rate. 

AI0, AI3, AI4 and AI7 are single ended, continuous samples, -10 to 10V, 200 samples per channel, 2Khz sample rate. 

About 90 to 95% of the time the DAQ reports the correct and expected voltages but the remaining time it reports completely inaccurate values.   When the values are inaccurate they are always the same.  The two differential channels report around 3.7 volts, where normally the input is -4 or so.  The first two single ended channels are always -10.2 volts where they should be  2.5 and 0.4.  AI4 and AI7 report 2.5 v and 0.4 v when they should be around 4.5 volts.  

This make sme think there might be a "race condition" of sorts where occasionaly something in the setup completes before another part, resulting in this error.  The  similarity between what it is reporting and what it should be is too close for those two channels.  I've attached a screen shot of how I'm setting these up.  From the right they run out to a "Analog 1D Wfm NChan NSamp" read and to a signal splitter. 

Any thoughts? 

[Nick Moszer]

Bump.. Anyone?

[Mark_SAI]

Hello,

Instead of using local variables, could you directly wire up the Samples to Read control? Failing that, please post your VI for me to look at.

[Nick Moszer]

Thanks for the reply macaba.  I tried using a constant instead of a local variable, no dice.  The default value of that control was the value I wanted anyway so I would assume changing to that constant would not have helped.

Attached is a slimmed down version of my vi along with two PNG's of the values I get when it's working and the values I get when it's broken.  Thanks for the help! 

[Nick Moszer]

Fixed!

I combined the flat sequence as attached in the screenshot.  

[Nick Moszer]

Not solved!  This came back today out of the blue.  The vi is the same, just slightly modified as posted above with the combined flat sequence.  That makes this problem occur much much less frequently but it does still occur.  This makes me think it's still a race condition somewhere. 

Anyone have any ideas? 

[Mark_SAI]

Hello,

I haven't found any clear cause yet, but perhaps you could try running your task wire through the no - error case of the case structure before leaving the sequence. That is all that occurs to me at the moment regarding race conditions.

[Nick Moszer]

Thanks for the reply.  I don't know how running it through an error/no error would help as the DAQ and VI think nothing is wrong and don't throw an error.

For now I've got a dirty hack in there to reset if one of the values is obviously wrong and the vi is mis behaving.  Any other ideas on what to do? 

[Doug_L._Bear]

I would recommend you get rid of as many variables as possible and connect everything with wires, this should drastically reduce the occurance of any race conditions that are occuring.  You should also aim to determine if the reading coming off of the DAQmx read is incorrect or if the analysis and filtering is yielding the incorrect results.  You can do this by placing indicators straight off the DAQmx read.

If the problem is coming from the read it sounds like it could be a problem with either the card or with the external connnections.