How to read a ctr when counts can be zero?

[DieselPower]

I need to measure two frequencies from a device.  One is 30-90 kHz, and one is 1024 pulses per revolution.  If the engine is not spinning, one of the counters will not sense a rising edge over the measurement period.  This is on a real time system.  I want to read the counter values at 10 Hz and then calculate values based on the change (or no change), in counter value.  I have verified that counter 0 does measure pulses using NI MAX Test Panel.  I have a few questions:

1. Can I make the counter task stop crying about no edges and just return 0, or do I need to handle the -200474 timeout error?

2. Is the period in the task setup the period of time that I want to count pulses?  On a real time system can I assume the period is extremely accurate?  The number of pulses that I count for speed is dependent on the duration of my read. 

3. Is this function call returning frequency or the number of rising edges over my measurement period?

4. What would be the best method to implement this?  Right now it looks like the 30-90 kHz clock is rolling over periodically so I get bad measurements from time to time, and I also have crappy resolution.  I am getting measurements of 4,948 Nm (torque) or 5,015 Nm at 90 kHz precisely, when the measurement should be 5,000 Nm.

if (flagUseHBK)
{
	/*********************************************/
	// DAQmx Configure Code
	/*********************************************/
	DAQmxErrChk (DAQmxCreateTask("HBKSpeedTask",&speedTaskHandle));
	DAQmxErrChk (DAQmxCreateCIFreqChan(speedTaskHandle,"PXI1Slot5/ctr0","",2,120000,DAQmx_Val_Hz,DAQmx_Val_Rising,DAQmx_Val_LowFreq1Ctr,0.1,1,""));
		
	DAQmxErrChk (DAQmxCreateTask("HBKTorqueTask",&torqueTaskHandle));
	DAQmxErrChk (DAQmxCreateCIFreqChan(torqueTaskHandle,"PXI1Slot5/ctr1","",30000,90000,DAQmx_Val_Hz,DAQmx_Val_Rising,DAQmx_Val_LowFreq1Ctr,0.1,1,""));

	/*********************************************/
	// DAQmx Start Code
	/*********************************************/
	DAQmxErrChk (DAQmxStartTask(speedTaskHandle));
	DAQmxErrChk (DAQmxStartTask(torqueTaskHandle));	
}

	if (flagUseHBK)
{
	char message[100];
	/*********************************************/
	// DAQmx Read Code
	/*********************************************/
	if (DAQmxReadCounterScalarF64(speedTaskHandle,0,&HBKSpeedData,0) == -200474) HBKSpeedData = 0;
	if (DAQmxReadCounterScalarF64(torqueTaskHandle,0,&HBKTorqueData,0) == -200474) HBKTorqueData = 0;		
	sprintf(message, "Speed: %.0f\tTorque: %.0f", HBKSpeedData / 1024 * 600, HBKTorqueData * 0.166667 - 10000);
	Terminal_Writeline(message);
}
	

[Kevin_Price]

Brief answers:

1. When doing frequency measurement, you'll need to handle the -400474 timeout errors.  You may want to give some thought to your timeout duration -- too long makes your code get "stuck" waiting, too short may not wait long enough.

    Since it appears that you're in software-timed "on-demand" mode, your timeout should be at least 2x the longest interval you intend to measure.  In on-demand mode, if you attempt to read an instant after one of the edges just occurred, you won't get a measurement until 2 more come in -- which requires 2x the interval you're measuring.

2. I dunno the CVI syntax, only LabVIEW.  There, when one configures a freq measurement task the estimate for min and max freq are really only used to let DAQmx choose an appropriate timebase.  Other than fairly unusual circumstances, it'll default to use the fastest timebase giving you the maximum precision.

    No comment on software timing accuracy under real-time.  I don't see anything in the posted code that would control timing.  And I don't have any knowledge about its consistency under CVI anyway.

    When you do a counter-based frequency measurement, that will all be happening at the hardware level with hardware-level accuracy.  Each time you perform an on-demand Read function, your counter will be armed and then wait to see 2 edges.  It'll be tracking the time between the edges with a hardware clock (probably at 80 or 100 MHz) and giving you back a very precise and quite accurate frequency for that specific interval.

3.  In your on-demand mode, your software is not in control of the measurement interval.  The best you can do is try to control how often you attempt to *initiate* a measurement.  When that measurement comes back to you depends on the hardware signals themselves.  When there's no encoder motion and no hardware edges, there's no "interval" to measure and you'll have to deal with the timeout error.

4. Would need more info.  From what I can see, frequency measurement should *not* be subject to counter rollover when the signals you measure are 30-90 kHz.  Rollover generally requires intervals in the range of 1 to hundreds of seconds (depending on timebase frequency and # bits in counter).

    Further, the quantization you mention is a little over 1%.  If the problem were on your measurement end, it should be closer to 0.1% b/c NI's devices typically have 80 or 100 MHz timebases (so quantization around 1 part per thousand).   I'm a little inclined to speculate that the quantization might originate with the source signal, which apparently generates a frequency in proportion to torque.  

   What device are you using to do this frequency measurement?

-Kevin P

[DieselPower]

1. I generally use continuous measurements for AI, so I think I should do the same here.  The example was not continuous, however.  I'll search for other examples.

2. It isn't as accurate as I would have thought.  Speed should go from 600-2500 RPM for this application which is ~10 kHz to 43 kHz.  I wasn't able to get 1088 RPM or something like that.  It was bouncing from 1087 to 1089.  I am playing with a 32-bit counter now instead of 24-bit to see if resolution improves.  It probably still depends on the sample clock, not bitness.  I am also playing with the three counting modes (one counter, two high frequency, two high count), but surprisingly, one counter seems to have the best resolution.  This test is not complete so don't quote me on this.

3.

4. Does the counter reset counts after a measurement?  I am using a PXI-6733 and now a PXI-6602.

[Kevin_Price]

1. Continuous would normally be preferable.  However, there's a non-negligible chance that you could run into some limitations of your older DAQ devices and the PXI bus.   A bunch more info in this thread I'm also in (and follow the link I mentioned too).

    Note that you'll need to use "Implicit" timing mode rather than a sample clock when measuring frequencies with the counters on your devices.

2. The 6733 uses the DAQ-STC timing chip which has 24-bit counters and, IIRC, a 20 MHz max timebase.   The 6602 has 32-bit counters and a 80 MHz timebase, and will be your better choice for counter work.

    That said, the limitations you see don't entirely make sense to me.  The slower-than-I-accounted-for timebase of the 6733 means the expected quantization error from the 30-90 kHz clock could be ~4x to 5x the 0.1% I suggested earlier.  But you were getting something more like 1.3%.

    As to your encoder, 1088 RPM at 1024 pulses per rev puts you in the realm of 18 kHz.  With a 20 MHz timebase, quantization should be about 1 part in 1000.  But you were seeing twice that much.

    Switching to the 6602 should help due to its faster timebase.  In your usage here, the extra bits won't matter much unless you approach counter rollover.  But that'd take 2^24 / 20e6 ~= 0.84 seconds, which is a frequency less than 1.2 Hz.  (The 6602 wouldn't rollover until 2^32 / 80e6 ~= 54 seconds).

    Finally, the 1 counter frequency measurement method is pretty much all I've ever used.  The claimed advantages of the other methods can generally be derived with some fairly straightforward post-processing of the raw frequencies captured by the 1-counter method.

4. During continuous measurement of frequency (or period, semi-period, pulse width, or two-edge separation), each time a measurement is captured the count register will then reset to 0.  It does *not* reset after sampling an edge count or an encoder position.

-Kevin P

[DieselPower]

Here are some observations from yesterday:

I ran a continuous measurement from 15:00 yesterday through 07:30 today.  No glitches on the speed channel, but the torque channel is not counting and wasn't yesterday afternoon either.  I'm going to disable the speed channel and try only torque.

Two counter high frequency absolutely has better resolution than a single counter.  It was "dead nuts" accurate at 30, 60 and 90 kHz, whereas the single counter was 29.996-30.008, 59.97-60.015, and 89.988-90.090. 

I can get the two counter method to work using NI MAX and creating a task, but it will not work in my application.  I can't figure out what else I need to do to get it to work.  I have consulted a sample project and I don't see any other configuration beyond what is shown below.

Example:

DAQmxErrChk (DAQmxCreateTask("",&gTaskHandle));
DAQmxErrChk (DAQmxCreateCIFreqChan(gTaskHandle,chan,"",min,max,DAQmx_Val_Hz,edge,DAQmx_Val_LargeRng2Ctr,0.001,divisor,""));
DAQmxErrChk (DAQmxCfgImplicitTiming(gTaskHandle,DAQmx_Val_ContSamps,1000));
DAQmxErrChk (DAQmxRegisterDoneEvent(gTaskHandle,0,DoneCallback,NULL));
DAQmxErrChk (DAQmxStartTask(gTaskHandle));

//They call this in some kind of panel timer.  I am using real time so I can't actually run the sample programs.
DAQmxErrChk (DAQmxReadCounterF64(gTaskHandle,gSamplesToRead,10.0,gData,gSamplesToRead,&numRead,0));

Mine:

DAQmxErrChk (DAQmxCreateTask("HBKSpeedTask",&speedTaskHandle));
DAQmxErrChk(DAQmxCreateCIFreqChan(speedTaskHandle,"PXI1Slot5/ctr0","",10000,120000,DAQmx_Val_Hz,DAQmx_Val_Rising,DAQmx_Val_HighFreq2Ctr,0.1,4,""));
DAQmxErrChk (DAQmxCfgImplicitTiming(speedTaskHandle,DAQmx_Val_ContSamps,1));
DAQmxErrChk (DAQmxStartTask(speedTaskHandle));
//Called in a 1 Hz Loop
if (DAQmxReadCounterF64(speedTaskHandle,1,0.5,&HBKSpeedData,1,&numRead,0) == -200474) 
{
	HBKSpeedData = 0;
	Terminal_Writeline("Speed timed out.");		
}

I tried their lower sample time, but still I got nothing.

[DieselPower]

So it seems I can get better data when asking for multiple samples and averaging them, but I need to know about the sample rate.  When I set up the channel I set up a measurement time of 0.1 seconds.  I need data at 10 Hz, and since my request of 1 sample was noisy, I'd have to have 10 measurements that are taken every 10 ms.  I would have figured getting one sample that is ten times longer would have the same noise, but now I'm not sure.

When using low frequency measurement and calling the read at 1 Hz, how often are readings being stored?  Aren't they measuring all the time, even when not calling the read?

[DieselPower]

It looks like the two counter method needs a second clock per this website.  I could use another counter on the card to generate that pulse train so it would actually require three counters to read one clock if I'm understanding this correctly.

https://www.ni.com/docs/en-US/bundle/testscale-feature/page/large-range-frequencies-two-counters.htm...

I have it working with the single counter method.  The last issue I am running into is that the signal floats at very low frequencies.  I was able to handle lack of a clock signal when requesting a single sample, but not that I am running continuous it won't just time out and allow me to set the counter to zero.  I am hoping that the solution is not to have to poll the counter at explicit intervals and calculate frequency rather that measuring frequency.  I wish this frequency measurement did not have to see rising edges and would work all the way down to zero.  Any ideas?

[Kevin_Price]

You hit on an awful lot of things in these last few posts, more than I can respond to.  I don't mean the following to be harsh, I'm just looking to promote clarity here.

I think you have a few fundamental misconceptions about how counters work, and these are causing you to think and try things that aren't fully productive.  Much of this probably comes from the fact that counters really are unique in several ways.  Where AI, AO, DI, and DO share quite a lot of commonality in how you think about capturing or generating signals, counters are often quite distinct from those other forms of IO.

To pull a quote from your last post:

I wish this frequency measurement did not have to see rising edges and would work all the way down to zero.  Any ideas?

These wishes are fundamentally not "counter-like".  Counters use logic circuitry that heavily *depends* on seeing edges.  Working "all the way down to zero" means working when there are no edges at all.  You have square peg wishes for your round hole counter hardware.  They simply won't fit.

Once you set up a buffered measurement using Implicit Timing, it's the frequency signal itself that causes samples to be captured and delivered to the task buffer that you read from.  You simply can't make a fresh and instantaneous measurement at a pace of your own choosing.  It's inherent to the nature of logic circuitry.  Stuff happens in reaction to edges or state changes.

    All you can do at a pace of your own choosing is check and read the buffer of measurements that were already made.

   I don't know the text language syntax, but DAQmx *does* offer a way to query a task for the # of new samples available.  You could do this query at your desired loop rate, and then make your override decision when there are 0 new *real* measurements available that interval.  When there's a non-zero # available, you can read them all and figure out whether to average them, use the latest value, accumulate over multiple loop cycles, whatever.

   Just keep in mind that the measurements you retrieve from a buffered task were previously captured some time in the past.  Maybe not far in the past, but definitely in the past.

   Non-buffered "on-demand" mode gets you a fresh new measurement but makes you wait for it.  When you get it, it's just barely in the past.

   There are tradeoffs and limitations that simply can't be entirely avoided.

-Kevin P

[DieselPower]

In my mind a counter is a device that stores numbers in a register based on, in this case, a rising edge.  Every time the rising edge happens, the register is incremented.  If you simply query the register you will get the counts.  If you query it two times in a row with no rising edge sensed, you would query the same number.

Now if you want to know the frequency of the measured signal, you query change in counts over change in time.  Let's assume some arbitrary counts sampled at 1 Hz whose rate magically changes in perfect 1 Hz intervals.

Time	Counter Value	New Counts	Counts/s (Hz)
1	0
2	0	0	0
3	0	0	0
4	10	10	10
5	20	10	10
6	40	20	20
7	80	40	40
8	80	0	0
9	100	20	20
10	100	0	0

Getting the counts is easy.  Sampling it at a perfect interval is very important.  We can do this by software which would suck, or we could do this by hardware using a clock.  That way we can fix the interval within the limits of the clock signal.  In this case it shouldn't cause the counter to hang up.  It's just polling a register value.

So NI wants to be nice and give us some function calls to return frequency by doing the same thing so that we don't have to make the calculation ourselves, but it gets mad if the counts don't change. 

Is my understanding of everything until the last statement wrong?

I am using LabWindows/CVI.  It does report number of samples read.  I'll check this for numRead == 0 and report back with my findings.

		/*********************************************/
		// DAQmx Read Code
		/*********************************************/
		if (DAQmxReadCounterF64(speedTaskHandle,10,0.5,SpeedArray,10,&numRead,0) == -200474) 
		{
			HBKSpeed = 0;
			Terminal_Writeline("Speed timed out.");		
		}

[Kevin_Price]

---

@DieselPower wrote:

Is my understanding of everything until the last statement wrong?

Just the opposite.  Everything *but* the last statement was spot-on right.

NI isn't doing things the way you expect when you set up 1 counter frequency measurement.  (I'm pretty sure I recall that *one* of the 2 counter methods *does* work that way though.)

   This is one of the ways counters can be different - they allow for a flexibility not available with the other IO types.  Here, what NI actually does is to "swap roles" between the measurement signal and the known, fixed-rate clock.  Specifically, it counts edges from a high-speed internal timebase (80 MHz for the 6602) and puts the measurement signal itself in the role of acting as the sample clock.  So no new edges means no new samples.

They say it's for "low frequencies" because that's what keeps quantization error low.  There's pretty much always a +/- 1 count quantization error to deal with. So if you measure an 80 kHz signal, you can expect quantization error to be 1 part in a thousand or 0.1%.  Slower frequencies will have lower error, faster ones will be higher.  An 800 Hz signal would have 0.001% error while an 800 kHz signal would have 1.0% error.

    Bear in mind that the one counter method would give you individual freq measurements at an effective sample rate of 80 kHz.  You're then free to do a variety of post-processing if you'd like.  So you could average across every set of 80 samples to get an average frequency at an effective sample rate of 1 kHz.  And you could do this either as disjoint sets of 80 or as a sliding window.  With the sliding window, through most of your capture time you'll be averaging across 80 samples, but updating your average at 80 kHz.

    The raw information available from the one counter method allows for lots of options for processing and interpretation, which is why it's the method I've pretty much always used.

When you go the *other* way (the way you were describing), you count edges of the measurement signal and sample with a fixed-rate clock.  NI says this is for high frequencies.  The reason is that higher frequencies will lead to lower quantization error.  To achieve the same 0.1% error would require you to see 1000 edges of the measurement signal between sample clock.  For an 80 kHz signal, you'd need to measure at 80 Hz.  What you then get *inherently* is an *average* frequency across that interval.  It's impossible to recover any further detail than that, it's already been averaged before you can retrieve it.

    Anyway, at that same 80 Hz sample rate a slower frequency like 800 Hz would yield a 10% quantization error while a faster frequency like 800 kHz would yield a 0.01% error.  Hence the reason NI says it's best suited for higher frequencies.

-Kevin P