cDAQ-9181 with NI 9402 : After first read cycle Counter is missing some counts in all following cycles.

[B_Sharma]

Hi,

I am trying to read TTL pulses from a function generator using a counter. I am applying a 1KHz signal to the counter. Every time counter reads the pulses correctly in first cycle of measurement, but it miss some counts in all following cycles.

I am using NI cDAQ 9181 Chassis and NI 9402 module with LabVIEW 2014 and NI Max 14.0.

My computer has Windows 8.1 operating system.

Please find the attached VI and image of Front Panel after RUN.

I also used the same VI with cDAQ-9171 USB chassis. Result were improved but the same problem still persists.

What could be the reason for that, please guide.

Thanks !

B. Sharma

[John_P1 · Accepted solution]

1.  The loop time is software-defined and so is not going to be consistent.

2.  You are re-starting the counter task between every loop iteration--while the task is restarting it is not taking samples.  The re-start is faster on the USB device compared to the ethernet device due to lower bus latency, so this explains why the behavior is improved on the 9171 compared to the 9181.

Using the 2 counter method would be a clever way (perhaps too clever...) to implement what I think you are looking for:

This will configure a second counter (ctr0 is paired with ctr1, ctr2 is paried with ctr3) to generate a signal of a known period (Measurement Time).  The counter will count the number of external pulses during that measurement time, and since we are reading back data in terms of "Ticks" it will give you back the count that occurred during the measurement time.  This measurement will repeat for the specified number of Cycles without any software-timing or latency between cycles.

The read call will need a timeout value long enough to ensure all cycles have completed (or you could poll to see if the task is done first to give the user the option to abort the measurement).

Best Regards,

[B_Sharma]

Hi John,

Thanks for your reply.

Your suggestion was helpful and it solved the problem.

But, I have some doubts which I hope you may clarify.

1. In my counter program (using one counter, for loop and while loop), I am configuring and starting the task inside FOR loop. Reading operation is inside the WHILE loop, which is programmed to run for user defined time period (in my case 1s).

Then, How reading operation is getting affected by the counter configuration as it's been completed before read cycle ?

2. I have used the same code with PCI-6036 card and LabVIEW 2010 and result were with in reasonableness of our requirement. See the attached VI and image files. Please clarify. "PCI Counter Testing_LV-2010.vi" .

3. And I tried to implement your solution to our existing system with PCI-6036 card and LabVIEW 2010. Every time it shows 0 (zero) for the first iteration cycle. What could be the reason for that? see the attached VI file " PCI Counter Testing_LV-2010_using two counters.vi ".

As I am new to the LabVIEW and not quite familiar with different NI DAQ architectures, I am have so many doubts and asking lot of questions.

Thanks & Regard !

B. Sharma

[John_P1 · Accepted solution]

1.  The Elapsed Time VI starts counting when you first call it, so the first loop will take about the desired amount of time (although OS timing is not very reliable anyway).  The Express VI will reset itself as soon as you hit the time target.  Then, you wrap back around and reconfigure your task.  This takes time (during which the DAQ task is not counting, but the Elapsed Time VI has already been reset), and so all subsequent acquisitions will actually run some time less.  For example, if the configuration took 100 ms and you wanted to acquire 1 second of data, you would only get ~90% of the count.

2.  The time it takes to reconfigure the task is going to vary dramatically with the bus you are using due to latency (ethernet > USB > PCI/PCIe).  So it makes sense that the problem was not noticeable with PCI, and it was most severe with ethernet (9181) compared to USB (9171).

3.  Discarding the first sample on buffered counter measurements is a behavior change with STC3-based DAQ products (e.g. X Series, C Series, 621x) compared to older NI DAQ products (e.g. E Series, M Series, 9172).  In your case, when you use the E Series card the first measurement represents the count measured between the arming of the task and the first edge of the gating counter (which toggles almost immediately, you are very unlikely to receive an external 1 kHz clock edge during this time).  Since this measurement is often not desired and can be confusing, it is discarded in the newer NI hardware.

Here is the behavior from the M Series and X Series user manuals (I know not your exact hardware, but I know that the diagrams are in these manuals and your E Series and cDAQ systems respectively will behave the same).

From M Series User Manual:

From X Series User Manual:

Best Regards,