How to use the PCI-6534 onboard memory ?

[Tom_W_[DE]]

HI MES-

I misunderstood your question.  The NI-DAQmx C Reference Help is easily obtained by installing the NI-DAQmx driver, which can be downloaded here.  You'll then be able to find the programmer's reference under Start>>Programs>>National Instruments>>NI-DAQ.  You can also get started testing programs for your device using NI-DAQmx simulated devices before your hardware even arrives.

Hopefully this helps-

[MES]

Thank you so very much!

[Dmytro Chumakov]

MES makes a good point. The data provided in the documentation is very basic and useless, having often nothing to do with instrumentation specifics. Yes, one can fine some valuable info, but having wasted a couple of days digging through examples, notes, forums.

Did I get the point right...

1) the onboard deep memory is of no advantage as long as PCI bus (for PCI 6133 for instance) can transfer the measured data to the PC buffer without interruptions....

2) user can make as much as nothing with the onboard memory, it is only for DAQ's seamless transfer management

3) the onboard memory stores data when the DMA transfer is impossible for some reason. It help to cover the interruption of DMA availability

pls confirm or pinpoint the errors in my understanding

[Tom_W_[DE]]

Hi Dmytro-

I addressed most of your questions about the advantages of onboard memory and its control in NI-DAQmx in my previous post.  Quoting:

The existence of deep onboard memory (aka SCARAB) on the 6534 means that you can operate at the full speed of the device for a much longer period of time than with a 6533.  This is true for a few reasons.  First, as the original response indicated, in the case of a continuous double-buffered operation, the onboard FIFO will be used to buffer samples if there is no PCI bus bandwidth available at the time.  This is a significant advantage over the 6533 because the 16 sample buffer on that device will overflow quickly when using a high acquisition rate if the bus becomes temporarily unavailable.  This advantage will be handled seamlessly by the NI-DAQmx driver, just as the Traditional NI-DAQ driver would have done previously.

In the case of a finite acquisition less than 32Msamples you can make use of the FIFO to acquire all samples onto the card independently of PCI bus activity and then later transfer the data across after the time-critical acquisition period.  This behavior is controlled by adjusting the DAQmx Channel Property "Data Transfer Request Condition" to only transfer samples from the board's FIFO when an acquisition has completed.  This is done in C using the "DAQmxSetDIDataXferReqCond(TaskHandle taskHandle, const char channel[], int32 data);" property, or in LabVIEW as shown here:

So, users can make explicit use of the onboard memory in the case of a finite acquisition, and in the case of a continuous acquisition the increased buffer space allows you to run at a higher rate for a much longer period of time.  So, in short, 1)the memory can be strategically taken advantage of in some cases, 2)the user CAN make much more than nothing with the onboard memory, and 3)in the case of a continuous acquisition, the onboard memory automatically attempts to cover interruptions in DMA availability.

Hopefully this helps-

[Dmytro Chumakov]

thanks, the thinig is somewhat clearer.... have a nice day.

[Tom_W_[DE]]

Hi Dmytro-

Glad I could help out- have a nice day, too.

[MES]

As Tom suggested, I have setup my program to use: DAQmxSetDIDataXferReqCond() with DAQmx_Val_WhenAcqComplete as my parameter, so that the data would be transferred only after the acquisition has completed.  However, I am getting the error message: "specified property is not supported by the device or is not applicable to the task."  I believe the board supports this, as Tom did give that information for it.  Does this mean I can't use it for every task?  What could be stopping me from setting this property?

I'm using a PCI-6534 with daqmx on labwindows 8.0.  Currently, the board is being simulated by MAX, until it arrives.

Thank You,

MES

My relevant lines of code would be:

DAQmxCreateTask("DUT Acquire",&gTaskHandle);

DAQmxCreateDIChan (gTaskHandle, LINES, channel_name, DAQmx_Val_ChanForAllLines);

DAQmxCfgSampClkTiming (gTaskHandle, CLOCK_SOURCE, CLOCK_RATE, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, xferCount);

DAQmxSetDIDataXferReqCond(gTaskHandle,channel_name,DAQmx_Val_WhenAcqComplete);

Message Edited by MES on 03-27-2006 08:48 AM

[Justin_M]

MES,

I have a feeling it might be the result of using a simulated device.  I'll try comparing a simulated 6534 to an actual 6534 tomorrow morning, and I'll let you know if I get that error for both, or for just the simulated device.

-Justin

[Justin_M]

I just tried using that property with the real hardware, and I got the same error.  I'll have to look into this a little more to find out if I'm doing something wrong in the code.  I'll keep you updated.

-Justin

[MES]

Thanks for looking into it!  I'll stay posted.