How to access "stranded" data due to 32 bytes DMA transfer with the NI PCI-6534

[apopa]

We are using the NI PCI-6534 in change detection mode in order to make acquisition. The NI PCI-6534 is used together with a NI PCI-6602. The

purpose of NI PCI-6602 is to record the time passed between two consecutive detected changes. In the past, a NI PCI-6533 was used.

The problem we are facing now is that we are loosing some samples from the end of the acquisition because the NI PCI-6534 is performing DMA

transfers in 32-byte blocks while the NI PCI-6533 was performing DMA transfers in 4-byte blocks. Therefore, if the acquired number of bytes is

not a multipe of 32 bytes there will be "stranded" data. We make acquisition on two ports so sample is 16bits long, therefore we can "loose" up to 15 samples which is not

ok for our purposes.

We are using Traditional NI-DAQ and this is how we stop the acquisition:

....
//if in ChangeDetection mode, then check how many samples are left
nStatus = DIG_Block_Check(m_nDeviceNumber, m_nChannelNumber, &ulRemaining);
if(0 == nStatus)
{
 m_ulSampInBuf -= ulRemaining;
}

// Set trigger mode to initial state.
nStatus = DIG_Trigger_Config(m_nDeviceNumber, m_nChannelNumber, 0, 0, 0, 0, 0, 0, 0);
// Clear the block operation.
nStatus = DIG_Block_Clear(m_nDeviceNumber, m_nChannelNumber);
// Unconfigure channel.
nStatus = DIG_Grp_Config(m_nDeviceNumber, m_nChannelNumber, 0, 0, 0);
....

In our case DIG_Block_Clear will stop the ongoing acquisition.
The question is how can we know how many samples have really been acquired and what is happening with the "stranded" data when we call DIG_Block_Clear? Is it transfered in our buffer so we can access it?

[MickeyD]

Hi,

I have been looking at your issue and the problem you seem to be having is with the DMA transfer.  It seems if you used an IRQ transfer instead you might be able to control the block size of the tranfer, which would avoid you missing the bytes.

As far as checking for the information after calling the DIG_Block_Clear, that is not an option, and it does not tell you how many samples have really been acquired.  Looking at the way a DMA transfer works I just don't see a way you could avoid that issue.  I will continue seeing if there have been user solutions to this trouble, but please post if you have any further information I could consider, or if you have any further questions with this issue.

Have a great afternoon,

Michael D
Applications Engineering
National Instruments

[apopa]

Hello,

Thank a lot for your answer. I will try the IRQ transfer, but it might not be fast enough for me. I will see.

But I would still like to try to make it work with DMA transfer. So up to now I figured a way to find out how many samples have been acquired (I make change detection and use NI PCI-6602 to measure the interval between changes and the counter board puts all the samples in the buffer as I would expect it to do.)

My problem is now how to access the "stranded" data. I have found the following in the Support section of the NI site (with blue):

DIG_Block_Check Always Returns 1 When Using NI 6534

Hardware: Digital I/O (DIO)>>High-Speed>>PCI-6534
Problem: I am using the NI 6534 and the NI-DAQ API. DIG_Block_Check is supposed to return the number of items remaining to be transferred after a DIG_Block_In or DIG_Block_Out call; however, it always returns 1. Why does the call think I always have one more sample remaining to be transfered?

Solution: The NI 6534 always performs DMA transfers in 32-byte intervals. Therefore, if the data is not transferred in groups of 32 bytes there will be "stranded" data. This different behavior (compared to the NI 6533) is due to the addition of onboard memory to support high speed transfers.

At the end of the DMA transfers, the stranded data will be retrieved manually, and status should be updated to indicate that the transfer is truly finished.

It is recommended that you either make the sample count a multiple of 32 bytes, or change your source code to recognize the end of transfer when DIG_Block_Check returns 1 instead of 0.

It seems that there is a way to get the samples but I do not know how to "retreive them manually".

Thanks for your help.

Adrian.

[cogansco]

I am also interested in the response here... any ideas?

[Ed W]

Hi,

I am looking into this issue.  I will post back with the results as soon as possible. 

Ed W.

Applications Engineer

National Instruments