Buffered event counting: migration from E/M series to NI-USB 6210

[LucaTesi]

Hello,

I create a project developed in LabWindows CVI that does buffered event counting.

The project ran on E/M series for a year. Now I have to migrate to NIDAQ-USB and precisely NI-USB-6210 (that is a M-series). The problem concerns reading acquired samples. The buffered event counting that I need is performed in this way:

1) Start a buffered event counting task

2) After n seconds, read the number of samples and read the samples

3) Stop the task

This procedure works fine on E/M series on PCI bus, but it does not work with NI-USB. With NI-USB, the number of samples is always 0. I link a project that demonstrates that (the "after n seconds" clause is simulated by pressing "stop" key).

After many tries, I saw that the problem is in reading number of samples and so I modified the sequence of operation in this way:

1) Start a buffered event counting task

2) After n seconds, try many times to read the number of samples

3) Read the samples

4) Stop the task

After some houndreds of attempts, the number of samples moves from 0 to the correct number of samples...It seems a bad working....And I don't know after how many attempts I can surely assert that no samples effectively "crossed" card input....

Is there an error in my procedure? Have I made some incorrect operations? Or maybe is there a inconsistency in NIDAQmx driver?

[Chuck_81]

Hello,

after debugging a bit your code I noticed a strange behaviour:

• The statement: "DAQmxErrChk (DAQmxGetReadAttribute (gTaskHandle, DAQmx_Read_AvailSampPerChan,
               &numRead, 0));", at line 235, always returns "0" for the variable numRead; this happens only with USB M series devices, since I tried also the project with a PCI-M series board and everything works correct;
• I've attached the the modified project which now avoids to take into account of "numRead" value: this seems to be ok and the program returns the edge counted at the end of the program (when pressing "stop");

I hope this helps,

best regards

[LucaTesi]

Hello,

thank you for your help.

The behavior seems to be due to the data transfer mechanism in USB cards (http://digital.ni.com/public.nsf/allkb/BFBC9983653C184186257227007A1527).

The problem is that my application doesn't know the number of samples before the acquisition.

So I think that the only possible workaround to this behaviour is to do countinuos reading of the number of available samples during the acquisition and to read the samples at the end of acquisition. In this way it seems to work fine, but I'm not sure that it's a reliable procedure. What do you think about that?

Bye

Luca

[Chuck_81]

Hello Luca,

I changed the code a bit and I found something interesting about your situation; in the attached VI there is your CVI project modified as follows:

• After the Stop button hes been pressed, and the corresponding callback function is called, we read the acquired samples two times: the first one we ask for 1 sample only. This allows to avoid the USB transfer mechanism issue and then, with the second read function it is possible to get all the remaining samples acquired (selecting -1 as "number of samples to read");

Hope this helps you,

Best regards

Fabio Mussi

P.S. A SR request about this problem has been opened too. If you need more information, call me at 02-41309217;