Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

USB 6210 first measurement different from the following

Hi!

(USB6210 running on opensuse 12.1 and nidaqmxbase-3.6.0 and gcc)

 

Starting from /usr/local/natinst/nidaqmxbase/examples/ai/contAcquireNChan.c I added a loop for aquiring 100 measurements see code below. Unfortunately the first measurement differs completely from the following measurements:

-0.105892    -1.122168    -1.527890
-0.036518    -0.048354    -0.057231
-0.037504    -0.049012    -0.057889
-0.036847    -0.048683    -0.058218
-0.036847    -0.049012    -0.056574...

 

Is there an error in my code?

Dieter

 

    float64     data[bufferSize * 16];

...

    DAQmxErrChk (DAQmxBaseCreateTask("",&taskHandle));
    DAQmxErrChk (DAQmxBaseCreateAIVoltageChan(taskHandle,chan,"",DAQmx_Val_Cfg_Default,min,max,DAQmx_Val_Volts,NULL));
    DAQmxErrChk (DAQmxBaseCfgSampClkTiming(taskHandle,clockSource,sampleRate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,samplesPerChan));
    DAQmxErrChk (DAQmxBaseCfgInputBuffer(taskHandle,200000)); //use a 100,000 sample DMA buffer
    DAQmxErrChk (DAQmxBaseStartTask(taskHandle));
for (j=0;j<100;j++){
    t = time(NULL);
    tt=localtime(&t);
    DAQmxErrChk (DAQmxBaseReadAnalogF64(taskHandle,pointsToRead,timeout,DAQmx_Val_GroupByScanNumber,data,bufferSize*2,&pointsRead,NULL));
     printf("%ld\t", t );
        for (i = 0; i < 16; ++i)
            printf ("%f\t",data[i]);
    printf("\n");
    sleep(1);

}

 

0 Kudos
Message 1 of 7
(3,943 Views)

Hi,

 

try this example attached. It's continuous.

 

This example demonstrates how to use Every N Samples events to acquire a continuous amount of data using the DAQ device's internal clock. The Every N Samples events indicate when data is available from DAQmx.

 

Then you only have to stop at a special amount of data.

 

Best regards

Suse

______________________________
Certified LabVIEW Developer (CLD)
0 Kudos
Message 2 of 7
(3,922 Views)

Thanks for the reply Suse!

Unfortunately on Linux I have to use nidaqmxbase and I don't think, continuous is supported. Please correct me if I'm wrong.

 

Dieter

0 Kudos
Message 3 of 7
(3,902 Views)

Hi Dieter,

 

there are some NI-DAQmx versions you can use with Linux too:

http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/de/pg/1/sn/catnav:du,n8:3478.41.181.549...

 

Does this help?

 

Best regards

Suse

______________________________
Certified LabVIEW Developer (CLD)
0 Kudos
Message 4 of 7
(3,863 Views)

Suse -

Unfortunately my NI USB-6210 is _not_ supported....

 

Dieter

0 Kudos
Message 5 of 7
(3,858 Views)

Hi Dieter,

 

maybe you can find some help in this documents:

 

Transition from Traditional NI-DAQ (Legacy) to NI-DAQmx using ANSI C and LabWindows/CVI: Part Three:

http://www.ni.com/white-paper/5959/en

--> Part 1 to 4 is linked below.

--> There is code included, also for NI-DAQ in CVI.

 

Maybe it helps if you open an example for DAQ in CVI for continuous acquisition and modify this one.

Help --> Find Examples (in CVI)

 

Best regards

Suse

______________________________
Certified LabVIEW Developer (CLD)
0 Kudos
Message 6 of 7
(3,836 Views)

Seems bizzare--I'd hope to think that the problem has more to do with a floating input or something of that nature rather than an issue with the DAQmx Base driver.  Which channels are in your AI task and how do you have them wired?  What is the signal source?  "DAQmx_Val_Cfg_Default" should result in differential configuraiton for AI0:7 and RSE for AI8:15, maybe one of the (-) terminals is floating?  It's odd that the behavior goes away immediately after the first sample has been taken, but if you have charge built-up on the inputs when you start your task then perhaps this is what you are seeing.

 

If this a driver issue I'd expect somebody else would have ran into it and posted it here already (I didn't see anything relevant after a quick search and haven't heard of this behavior myself), but I guess it is possible (in which case I'll have to defer to NI to investigate).  

 

This probably isn't a very good suggestion and you really shouldn't have to do this, but you could always just throw away the first sample and be done with it (assuming the rest of your data doesn't have any issues).  I'd be more interested in getting to the root cause though so it might be a good idea to try to play around with it a bit and try to determine which circumstances cause the behavior.  For example, what happens if you are running for a while, then stop, then immediately restart?  What happens if you remove your external signal source and short across the inputs?

 

 

Best Regards,

John Passiak
0 Kudos
Message 7 of 7
(3,820 Views)