Continuous buffer with interrupts doesn't refill the buffer

[Kenn_N]

Gil,

Ok these work.  I have one last request.  Can you check for errors in your disarm calls.  I am curious if there is an error we are not catching.  Please try this and let me know what happens.

Regards,

[grivlis]

attached in dist.zip are new versions of t5.exe and t6.exe (with source code) that do error checking for the disarm function.
There is no change in the output and no errors detected.

Gil

[Kenn_N]

Gil,

I am a bit confused why you set this line in your code.

// (8) synchronize pads (for low frequency)
        ReportError(s_nCTDevNum, nC, _T("GPCTR_Change_Parameter/ND_COUNTING_SYNCHRONOUS"), GPCTR_Change_Parameter(s_nCTDevNum, s_nCTChanNumber[nC], ND_COUNTING_SYNCHRONOUS, ND_YES));

The help says this about this function

(NI-TIO-based devices only) This paramID is applicable only for buffered counter measurements. In particular, synchronous counting mode is recommended for buffered counter measurements (except buffered position measurement) where the signal (internal or external) connected to the source input of counter is of a lower frequency than that connected to the gate input of that counter.

In your case the gate is the lower frequency.

Secondly

// (5) set to continuous (circular) data acquisition
        ReportError(s_nCTDevNum, nC, _T("GPCTR_Change_Parameter/ND_BUFFER_MODE"), GPCTR_Change_Parameter(s_nCTDevNum, s_nCTChanNumber[nC], ND_BUFFER_MODE, ND_DOUBLE));

The available options for ND_BUFFER_MODE are ND_SINGLE for single buffer operations or ND_CONTINUOUS for continuous-buffer operations.

What happens if you change these options? 

Just get rid of the step 8 and change step 5 to ND_CONTINUOUS

Regards,

[grivlis]

Hi Kenn,

Attached dist.zip with modified exe and cpp. There is no change in the output and no errors.

By the way:
(1) The 'ND_COUNTING_SYNCHRONOUS' is needed for my purpose. In my actual application the gate may be faster than the events. However, I removed it in the attached code.

(2) I actually already tried ND_CONTINUOUS. I know the docs say ND_CONTINUOUS, but the example code had ND_DOUBLE so I tried it too.
In the attached code I changed it to ND_CONTINOUS.

Let me emphasize that the acquisition is continuous for for the DMA channel but doesn't refill the buffer for the interrupts channel, all other things being equal. (that means with the ND_DOUBLE and the ND_COUNTING_SYNCHRONOUS).

Gil

[Kenn_N]

Gil,

Thanks for yor patience through this.  I was able to get your code working in Visual Studio and I can compile it and run different scenarios.  For example, if I use only one channel and transfer via interrupts it works, but if I use two channels, both using interrupts it will not work.  And of course the scenarios you have already presented function as you have described.  That said, this is a problem in the Traditional DAQ driver.  We appologize if it is causing serious problems. This application should work in NI-DAQmx, where the C API matches very closely to the LabVIEW API and the driver is in a more active development.  The C API in Trad DAQ is very different from the LabVIEW API.  Any new features for DAQ will be presented in the DAQmx driver and not the Trad DAQ driver.

A workaround is to only use 3 counters at a time for buffered measurements (all with DMA).  Thanks for your help in pinpointing this problem.

Regards,

[grivlis]

Hi Kenn,

Does this means that there are no plans on fixing traditional NIDAQ? It is a bug after all.

As for NIDAQmx, I would love to use it and have tried it a few times. However,  and I have encountered performance problems that I didn't have with the old NIDAQ. Briefly, I have two major problems with NIDAQmx:
(1) The latency for event callbacks is bad. The first few versions of NIDADmx didn't have callbacks at all. The newer versions have them, but they are not nearly as accurate, timing-wise, as the ones in NIDAQ. In the old NIDAQ I was able to get very accurate 1ms callbacks---no such luck with NIDAQmx.
(2) There is no direct access to acquisition buffers. I understand that it is not safe to access buffers directly, but I find that the buffer transfer functions are too slow. Probably because of thread context switching and synchronization. In traditional NIDAQ I can access the buffers directly (and carefully), in NIDAQmx, as far as I know, I cannot.

Gil

[Kenn_N]

Gil,

That's right, there are no current plans to patch Trad DAQ in this manner.  We understand these drawbacks you have stated in DAQmx for your particular application.  We will continue to work to improve these latency issues in future versions.  We also understand we have made some decisions in the way memory is allocated to keep things safer.  There may be some ways to work through these issues as you develop like we have done in this post to make your application more efficient.  Any specifics on these problems could be addressed in another post under that title.

Regards,