Error 200019 problem with USB-6251

[jchsu]

Hi guys,

I'm fairly new to LabVIEW so bare with me a little bit.  I searched through some of the questions already but I don't think the solutions apply to my problem.

I am simply reading inputs from the USB-6251 (with a function generator connected to it).  When I only read from one pin, I can enter very high sampling frequencies with no problem.  However, once I create an array and sample from more than one pin, the maximum sampling frequency I can achieve is 384,615 Hz.  The maximum sample rate of the hardware is 1.25 MHz.

Attached is the very simple code for what I'm trying to do. 

[Hillman]

Hi jchsu,

Good afternoon and I hope your well today.

There are a few suggestions I have to improve the code you have developed. Firstly, have you tried using the NI Example Finder? There are some pre-built DAQmx Analog Input examples.. these should work for you. Go to Help>>Find Examples>>Hardware Input/Output>>DAQmx>>Analog Input..

Are you trying to perform continous or finite DAQ task? It is generally not recommended to have a loop around a complete DAQ task, such as start + read + stop looping. It takes time to open and close rapidly. 

I have made some changes, and the code below is post in LabVIEW 8.6. If you are using a different version then please let me know. 

I hope it finds you well, 

[jchsu]

Thanks for your help James.

The reason the code is like this is because my supervisor handed it down to me in a state very similar to that.  But I'm thinking it might have been an error on her part in taking out the inner while loop and I never realized.

I am trying to continuously sample the inputs, and due to my noviceness in LabVIEW still, I'm having a hard time determining whether your code is continuously sampling or if it is just outputting the same data over and over again.  I say this because the trigger level is very steady on the waveform and I notice no changes, which naturally makes me skeptical.  Also, is the wait until next ms multiple function needed in the while loop?

Thanks again for your help.

Jeremy 

[jchsu]

Also, does anyone have any clue where the number 384,615 Hz could come from?  At first I thought it might have to do with the aggregate sampling rate (1MS/s) but this sampling rate is always the maximum whether I'm sampling 2,3 or 4 channels at a time (haven't tested more, higher frequencies do work for just one channel though).  Not only that, but it doesn't seem to have a result that makes any kind of sense when divided with any significant parameter.

[Hillman]

Hi Jeremy ,

Good Morning and I hope your well today.

I would ask you to look at the following example in the NI Example Finder, titled Cont Acq&Graph Voltage - Int clk.vi. It is a continuous task because firstly the DAQmx Timming.vi sample mode input is configured for Continuous Samples. Then the fact there is a loop around the DAQmx read, means the task will read 1000 samples (samples to read input)every time the loop iterates. The timing vi is not required, the DAQmx read self regulates the loop - but you must make sure the loop isn't slowed down to much, it must iterate fairly quickly to read all the samples out of the buffer before it runs out of memory. The buffer size is set based on the rate and the number of samples per channel input on the DAQmx Timming vi. As the example shows, it is always good practice to open the task, and start the task outside of the loop, and then once the acquisition is complete - to close the task, again outside the loop. 

You are correct that the limit which it errors is a strange number - but this is expected.  The devices can be over-clocked slightly and also depends on the software design of the code. If your code is too slow, it will cause unexpected results. If you implement code such as the example you will not see these issues.

The sampling rate for the usb 6251 is,

NI 6251....... 1.25 MS/s single channel,
           ....... 1.00 MS/s multi-channel (aggregate)

I.e. if you have 4 channels then the sampling rate per channel is 1Ms/s / 4 channels = 250kS/s. You can test the example by setting the example to use 4 channels at a rate of 250kS/s. Then stop the code. Ask the code to use 8 channels at the same rate, and you will get a DAQmx error, either as the task starts or once the DAQmx task has been completed - informing that you will have lost samples. 

Hope this helps, 

[jchsu]

Ok, sorry about the confusion Jason, but after examining the code some more, and discussing with my supervisor, I do need to keep the sample clock at finite sample mode.  This is because this DAS is capturing data everytime the system outputs a wave.  Basically, the system will output a wave (not shown in the original code), and then capture the reflection of that wave.  Therefore I can only sample when an output is being sent, hence the original big while loop in my original code.

Jeremy 

[jchsu]

There's also one more thing I'm having problem with James.  It seems that when I sample more than one channel, the waveforms for each channel are identical.  For instance, if I sample ai0 and ai1 and leave ai1 unplugged and ai0 to a function generator, the waveform for ai1 will be identical to the waveform in ai0.  This happens for 4 channels as well.  However, if I only connect ai1 (only one channel by itself), it correctly outputs noise to the waveform (since it is not connected).  

I have tried many ways to create the string that is being input to the DAQmx create virtual channel VI and none of them work.  Is there something wrong with how I'm outputting the waveforms?

Thanks again James, or anyone else who stops by.

Jeremy 

[Dennis_Knutson]

The behavior you are seeing with an unwired input is expected (search for 'ghosting'). What do you think should happen?

Why are you trying to create a string for the DAQmx Create Channel.

[jchsu]

If this is typical, shouldn't I see the same function generator wave even if I only sample one channel at a time (vs doing both of them)?  I understand that the unconnected port will have some properties of the connected port, but not the EXACT same amplitude of it.  It should be a much smaller magnitude.

Also, I'm connecting a string because the Create Virtual Channel's physical channel input says you can "also wire a string that contains a list or range of physical channels to this input."

Jeremy 

[Dennis_Knutson]

Before commenting, please do the search I recomended. The amplitude will not be a much smaller.

Of course you can wire a string but why? And if it does not work for you, you need to show the code with the string and with it populated.