Using the USB-6008 for Continuous Sampling

[mhubel]

We are planning to use the USB-6008 in a product what will require continuous sampling of the analog input at 10 KHz. The issue is how to gracefully aquire the data. Using the DAQmxReadBinaryI16 function appears to be blocking in that it will wait until the requested samples are in the buffer.

If numSampsPerChan is >0 then it appears to wait. If it is zero, then it appears to return whatever is there. which would be a random number. If this is the best that can be done it may be usable.

The ideal solution would be to use something like DAQmxRegisterEveryNSamplesEvent. This requires a "buffered task" ability. This is not mentioned anywhere in the specifications of the device. Can one plan on using this function to trigger a call to a routine for reading the data? If not is there another nice way to deturmine how much data is in the buffer without emptying it. One could then test the buffer perodically and when it has sufficient data, read only a fixed amount.

[Neil_S.]

mhubel,

Thanks for posting to the NI Forums.  The best option will be to use the DAQmxRegisterEveryNSamplesEvent.  When the callback function is executed it should then call the DAQmxReadAnalogF64.  I would not recommend using the DAQmxReadBinaryI16 since the data is return as raw data.  It is not scaled, or calibrated.  There is very little overhead in using the DAQmxReadAnalogF64. 
    Any NI-DAQ device capable of performing hardware-timed acquisitions can perform "buffered acquisitions".  The buffer in a "buffered acquisition" is actually stored in the computer's memory and managed by the driver.  It is the driver rather than the device that causes the event to fire.
    Let me know if this does not answer your questions or if you would like further clarification.

Regards,

Neil S.
Applications Engineer
National Instruments

[mhubel]

I did try to use the DAQmxRegisterEveryNSamplesEvent but in a Visual C++ 2005 CLR forms project, microsoft fights you. The types decleared for the processing routine were not accepted and casting them as follows:

DAQmxRegisterEveryNSamplesEvent (
    taskHandle,
    DAQmx_Val_Acquired_Into_Buffer,        //trigger in data input
    ADSampleSize/2, //number of samples to aquire before trigger
    0 , //The callback function is called in the thread which registered the event.
    (DAQmxEveryNSamplesEventCallbackPtr)EveryNCallback,    //DAQmxEveryNSamplesEventCallbackPtr callbackFunction,
    NULL    //void *callbackData
    );

int32 /*CVICALLBACK*/ EveryNCallback(TaskHandle taskHandle, int32 everyNsamplesEventType, uInt32 nSamples, void *callbackData)

allowed it to compile but crashed on the first call to EveryNCallback.

I have defaulted to using only calls to DAQmxReadBinaryI16 and have found that if timeout=0, and numSampsPerChan=arraySizeInSamps then the routine either returns with sampsPerChanRead=arraySizeInSamps or an error saying that there were not enough samples. This is close enough. At least it does not return with a random number of samples. It is almost impossible to interpretate the documentation to explain this operation. I don't like to do things by experiment.

On the use of DAQmxReadBinaryI16, in this case scaling and level shifting are not important, overhead is a slight issue but the biggest concern is that the loss of precision in the LSB due to the int to float and then float to int may effectively make this a 11 bit system. That is more important in this case.

[Neil_S.]

mhubel,

Thank you for the additional information.  I believe some of the issues that you are experiencing have to do with using the DAQmx ANSI C API from C++ .NET (managed C++).  The only fully supported .NET languages for DAQmx are C# and VB.  Visual C++ is fully supported in an MFC project only (full support meaning examples, code generation, customer support, etc).  The following forum describes in detail our position on Visual Managed C++ support:

http://forums.ni.com/ni/board/message?board.id=232&message.id=491&requireLogin=False

This forum speaks of Measurement Studio support but also applies to the DAQmx API.  As this forum describes, it is still possible to use the DAQmx driver from managed C++ but support for managed C++ is limited to the .NET Class Libraries.  This .NET class library API differs from the ANSI C approach you seem to be attempting.  Others have mentioned that using the .NET Class Library from managed C++ would be more straightforward that using the ANSI C API since using the ANSI C API requires marshalling unmanaged data types and other formalities.  For more information on how you might be able to use the .NET class library take a look at the following thread:

http://forums.ni.com/ni/board/message?board.id=231&message.id=4175&requireLogin=False

Hopefully this information has been helpful in working with managed C++.  Let me know if you have any additional questions (although, my familiarity with managed C++ is limited so I may not have a very good answer.)  Good luck with your application.

Regards,

Neil S.
Applications Engineer
National Instruments

[mhubel]

Thanks for the proposed paths but I think we are stuck in C (not really C++).

VB is still basic and it still looks as ugly as basic did 30 years ago, Can't quite get excited about such a mess especially for signal processing. C# is really microsoft's version of Java. I don't know much Java, have little time to get into it don't think it is a good signal processing language and the idea of using a microsoft proprietary language is a bit sicking.

We have taken the perhaps back door approach of using Visual Studio 2005 C++ to generate the screens and then put calls in that generated code to our C routines (although they have to have a .cpp extension to make the system happy). Everything important like signal processing is done in C and we have a large very important collection of this C code. No managed anything. The only issue is that, as this thread shows, sometimes in doing this the microsoft system fights you.

By the way, trying to set up a MFC only project in VS 2005 is also a bit of a problem. Microsoft also fight the process and does things behind your back to try and "manage" it. We decided that allowing things to default was the safest path through the microsoft mess. (As you can guess, No I really don't like microsoft).

[Neil_S.]

mhubel
You should be able to get a MFC project to work in Visual Studio 2005 without to many issues and using this approach will allow you to use our normal DAQmx ANSI C API which would allow the code you have included in this thread to work properly.  Unfortunately, using a different type of unmanaged project is not supported and I wouldn't really know where to start to get your application up and running.  While using the defaults may be the "safest" path as far as Visual Studio is concerned, MFC projects are the only supported unmanaged project type for the DAQmx API.

Regards,

Neil S.
Applications Engineer
National Instruments