cDAQ-9184/9401 counter issue?

[lebecker]

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

[Corey.Rotunno]

lb,

  So I do not have a great answer yet as to why you are seeing that 5 count bump periodically. I can say however you cannot increase the read rate of the 9401. The 9401 uses implicitly timed read tasks. In fact, 9401 really is not a counter at all, the 4 counters are actually on the backplane of your chassis. That being said, your maximum read rate is a function of the pulse rate supplied to the input. I was using the 9401 for 4 counter read tasks, frequency or discreet count depending on the requirement of the test being run. It worked for years but I have since moved to the NI9361 which actually is a counter card and has on-board dynamic averaging, allowing for hardware timed read tasks. I love this thing. Ill have to dust off one of out 9401's and see if I cannot reproduce the issues you are seeing. I will say, I was not aware you could even use digital filtering with the 9401...I have only enabled it since switching to the 9361.

 EDIT: Forgot to address the different clock sources producing the same result. Increasing the clock source rate will not have an effect on the read rate of the task. The NI9401 will only give you a new value when it gets a new pulse from its' input.

[lebecker]

Thanks for the quick response, Corey. The fact that the 9401 uses a timed read task explains a lot about the 3-4 milliseconds observed for continuous reads...I actually saw increased latency in count values when I replaced the while loop with a timed loop.

Would you happen to have any experience with using the 9361 with a stream or channel data structure? I'm wondering about the ability of the 9361 to be read to a millisecond accuracy, or able to produce count values in a multiple sample read that has some semblance of synchronicity.

Thanks for your help, Corey, I had resigned myself to being painted into a corner.

lb 

[Corey.Rotunno · Accepted solution]

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.

[Corey.Rotunno]

I am looking at my old code using my old counter. I made a mistake, I was using the 9411, not the 9401. I have to read about the differences, but I think most of what I said applies. I will edit this post in a few minutes once I look into it. Ill try to provide a quick example of how I handled the reads with my 9411.

EDIT: The 9411 and 9401 are very similar in that they both use the chassis onboard counters. I was looking at my code and it appears that you were on the right track. All that stuff I was talking about regarding oversampling really only seems to apply to frequency measurements. From looking at my code it looks like I am sort of over sampling the discreet count read tasks, even with the 9411. I'll try to get a 9411 to refresh my memory, I haven't used them in a couple years.

I do notice though that in your counter2_snip you just ask for a set number of values. I do not think that is valid as you never set a read task timing source....you can't for a discreet count task with that module. The first attempt was closer to what I would expect to work.

[lebecker]

Before I forget let me thank you for taking the time for your thoughtful replies...

So if I understand correctly, the 9401 'counter' read rate is bound by the DAQmx driver which employs a timed structure of some sort to produce count values? But the 9361 is a true hardware-based counter that you can read at 10k? This is a really good rate for what I'm trying to do here. BTW, what version of DAQmx do you use, and did you need to upgrade to use the 9361? Or was this in the LVRT environment of which I have no idea of the instrument driver suite used?

[Corey.Rotunno]

lb,

  My pleasure, wish I could have given more concise answers. So, regarding the timing thing. For discreet edge counting it does not seem like the concept of a read rate really applies, but I am not very familiar with discreet count tasks.....I use them but they just seem to work, haven't put too much thought into them. What I was talking about might apply only to frequency or pulse width stuff. And no, the driver does not provide a timed structure. The timing for those types of tasks is referred to "implicit timing". The timing is a function of the pulse rate you send it. For example, if you are sending it a 10Hz square wave, it can only recalculate the frequency every 100ms; it can't recalculate its frequency until it gets a new pulse. There is a lot of reading available on frequency calculations...it isn't as easy as it appears on the surface and there are multiple ways to do it.

The 9361 is much different. It does the calculations in the module itself. So when you are asking it for a frequency value, it gives you the actual value as many times or as often as you want it. For the 9411 and 9401 you are going to the counter, getting pulse and timing information and calculating it in the daqMX task itself, I believe. The 9361 does require newer drivers as it is a pretty new module. 

All that being said, the 9361 is a much more expensive module. I do not suggest switching to it just because of the issues you are seeing. You can overcome your issues while still sticking with a 9401. I was doing discreet counting reliably with a similar module. The reason I switched to the 9361 is that the threshold is programmable and it has 8 onboard counters, meaning I can do 4 frequency, an encoder, and a discreet count channel. That many channels are just not available on the 9401. Also, being able to synchronize the reads with analog tasks makes things easier, but you can fake it with a 9401. In truth, the 9361 is kind of faking it in a way to, but it is done in the module rather than your code. Frequency and count measurements are kind of funny.

FYI - Im running daqMX 16.0.1. I run on both windows development/runtime and embedded RT platforms. They all use same set of drivers, or at least all have matching daqMX version numbers.

[Corey.Rotunno]

Ok, so I dug up one of my old 9411's to try and recreate your issue. Let me ask, how did you wire it up? Did you leave CTR Source terminal unwired? You should only be using CTR Gate.

[lebecker]

Here's my latest incarnation based on your suggestions which seems to produce the most stable results.

[Corey.Rotunno]

Good to hear. I see you are reading 3 values per read execution? Without a timing source assigned to your task how does that behave? I would expect to get 3 values really quickly, then a wait for the loop to iterate, then 3 more values in a clump and so on. Or do they come in at pretty even intervals? For my discreet count tasks I have always done a single value per iteration and let the loop timer control my read rate. However, I never used that method to read any faster than 100Hz.