Hi All, I'm trying to develop an IRIG-A format (ie., millisecond accuracy) generator on the cheap using an IRIG-B time source with a 1-PPS output square wave. The 1-PPS signal is used as the phase-locked input into a 1-kHz frequency multiplier. This TTL output is input into the cDAQ-9184 with DIO module 9401, where an onboard counter is configured to provide millisecond timing information to the main program by a dedicated LV-2015 DAQmx edge-counter read loop. I've tried a couple different approaches to the counter read code as shown in the snippet attachments. Counter1_snip is a single channel/single sample counter value read in a while loop that apparently can't be read any faster than every 3-4 milliseconds, as shown by the plot in front panel counter1_FP that displays the difference in successive counter values. With or without the wait function to prevent a tight loop, and regardless of the wait msec value (0 or 1), the result is the same. Counter2_snip is a single channel/multiple sample read in an attempt to get a faster read on the counter values. Alas, as the front panel counter2_FP indicates, the successive value difference plot (bottom) shows a 5-count value hiccup every 125 samples, suggestive of a systematic interrupt of the 10000 sample read function. Is there a more accurate way to read the counter or have I run into a limitation of LV-2015 that really requires LVRT/FPGA? Also, how fast does the multiple sample scheme read the counter, since I got the same result with different sample clock rates (100kHz, 20MHz, and 80MHz clock sources)? Any insight to the NI counter mystery is greatly appreciated! Thanks, lb

lb, I have used both the 9361 and the 9401 with streams when using a RT chassis and with array queues with a standard USB cDAQ. I have not updated to LV2016, so no "channel" wires for me. However, the different methods of passing the data around is really independent on the type of module you are reading from. The biggest difference of the 9401 vs. the 9361 is that the 9401 is an implicitly timed task, meaning that if you must read a 9401 at 1kHz lets say, you might need to do weird stuff like use shift registers to store the last valid read and duplicate that value until you get another valid read. With the 9361 you can ask for values as fast as you want as it is a true hardware timed task. It may give you duplicate values if you oversample it, but you are still getting valid "reads" every time. In my application I actually "read" my 9361 @ 10kHz. In my case I am basically always over sampling it, but it makes it much easier to synchronize it with my analog and digital read tasks. For all of my read tasks I get 100 values every 10ms (giving 10kHz) and then I put all the values from the different read types into a 2d array that I then populate a queue or data stream with. That way I can just pick off different columns in different parts of my application when I want a certain channel instead of dealing with separate queues for each read type.

LabVIEW

cDAQ-9184/9401 counter issue?

Solved!

Author

Yeah, I was using the single sample read as well but decided to try this after you mentioned reading 100 samples every 10 msec. Reading 3 samples produces somewhat the same result as the single sample read in that there can be 2 or 3 or 4 count differences between changes in count value. I don't think pulses are skipped but rather the 'implicitly timed read' you referred to earlier. I'm going to experiment a little with the pulse rate and see what effect it has on the reported values.