Timebase ticks value vs period value

[David_Lin]

Hi,

I am testing the semi period example Buff Semi-Period-Finite but changed units to DAQmx_Val_Ticks. The counter values I got were all around 27,000. But when I changed the units to DAQmx_Val_Seconds, the data values were around 0.00035s, which I confirmed with an oscilloscope. So I am confused by the tick values vs period values. The program uses default 20MHz time base. If the semi-period is 0.00035s, the tick number should be 20MHz * 0.00035 = 7000. How come the tick values are 27,000?

Thanks.

David

[Kevin_Price]

Are you setting the 20 MHz timebase explicitly?  What data acq board are you using?  I ask because the discrepancy is kinda close to the factor of 4 which you'd get if your board was using an 80 MHz timebase.

It sounds like you're calling DAQmx functions from a text language and I only use LabVIEW so I'm not sure if the following is relevant.  In LabVIEW, part of the config for period or semi-period measurement is to inform DAQmx of the min and max expected periods.  Then DAQmx tries to make an intelligent choice of timebase that will give you desirable resolution without risking rollover.

To my mind, these inputs don't really make much sense when units=Ticks, but there we are.  I'm just wondering if it's possible that DAQmx is choosing a different timebase in your two modes depending on whether it interprets those min/max values as either seconds or as timebase ticks.  (I'm assuming here that you aren't also changing those min/max values along with the change of units).

Personally, I almost always use units=Ticks.  I got to used to thinking that way under (unitless?) traditional NI-DAQ, and have found certain advantages to dealing with pure integer data.  I mention that because I've always found the counters to behave as expected with units=Ticks, so I don't tend to suspect that this is a board or driver bug.  Can you post your code?  And a screenshot too?

-Kevin P.

Message Edited by Kevin Price on 09-24-2007 11:20 AM

[David_Lin]

Hi, Kevin,

Here is the part of the example code I tested

 /*********************************************/
 // DAQmx Configure Code
 /*********************************************/
 DAQmxErrChk (DAQmxCreateTask("",&taskHandle));
 DAQmxErrChk (DAQmxCreateCISemiPeriodChan(taskHandle,"Dev2/ctr1","",3000,80000,DAQmx_Val_Ticks,""));
 DAQmxErrChk (DAQmxCfgImplicitTiming(taskHandle,DAQmx_Val_FiniteSamps,1000));

 /*********************************************/
 // DAQmx Start Code
 /*********************************************/
 DAQmxErrChk (DAQmxStartTask(taskHandle));

 /*********************************************/
 // DAQmx Read Code
 /*********************************************/
 DAQmxErrChk (DAQmxReadCounterF64(taskHandle,1000,10.0,data,1000,&read,0));

After reading your post, I explicitly set the counter source to be 20MHzTimebase in my own developed routine , and the result is correct and the values are around 7000. Does this mean I have to explicitly set the timebase every time I need to measure ticks?

Thanks a lot for your help!

David

[Kevin_Price]

After reading your post, I explicitly set the counter source to be 20MHzTimebase in my own developed routine , and the result is correct and the values are around 7000. Does this mean I have to explicitly set the timebase every time I need to measure ticks?

Well, I'd say it's probably a good idea.   Otherwise, the DAQmx driver will decide for you, and it isn't entirely clear to me what criteria it uses to decide.  I.e., I wouldn't count on predicting it correctly.

Honestly, I still find certain aspects of the DAQmx API for counters to be kind of awkward and non-intuitive.  I got used to counters under the older legacy NI-DAQ driver where the API terminology was closer to the hardware.  Under that API it was pretty clear that counter operations were a different kind of beast than all the other data acq task types.   And because it's such a different kind of beast, it must have been difficult for NI to figure out just how to map their capabilities into the single common DAQmx config chain.   Hence the need for terminology like "Implicit" for counter sample clock timing.  It's an accurate term, and I've got no better suggestion, but it still strikes me as a kind of compromise between the oddball nature of counters and the universality of the DAQmx API.

Your problem is another illustration.  The inputs for min and max period appear to be a direct analogy to the min and max voltage inputs in an AI task.   And if you're measuring with units=seconds, it may be handy to let DAQmx do the dirty work of picking a timebase and converting the tick counts into seconds.  However, if you measure with units=ticks, it takes some trial and error to find out that DAQmx will *still* pick a timebase for you, and you won't know what it is unless you explicitly query the task to find out.

Ah well, I'll get off my soapbox.  I'm also one of those people who gets irrationally agitated by Windows' insistance on prompting me to store everything in "My Documents", "My Pictures", My Goo-Goo Ga-Ga", etc.  It's my belief that middle age earns me the right to grump a bit..

-Kevin P.

[stilly32]

Hi,

As Kevin mentioned, you can always query the timebase used with "DAQmxGetCICtrTimebaseSrc()" or the rate with "DAQmxGetCICtrTimebaseRate()". That way you can let DAQmx choose the best rate for you and factor it into your calculations when using ticks.

In defense of DAQmx, for a lot of users it is desired that DAQmx choose the best timebase for you based on the max and min pulse specs you're expecting. Though Kevin P has a completely valid point when using ticks - you would want to query the driver to make sure that your calculations aren't off. You can always just explicitly set the timebase much like you would in Traditional DAQ.

If you come across other aspects of the driver that you do not find intuitive, we are always looking for feedback. Several of our developers (including me) cruise the forums looking for this type of stuff. You can also put in a product suggestion.

In this case, I'm not sure what a good fix would be. We could (theoretically) return the timebase used based on the calculated values in the "DAQmxCreateCISemiPeriodChan()" function, but this value could be changed later programmatically and would add another variable that only those using ticks as a units would use. I'd be open to any other thoughts on the idea.

Cheers,

Andrew S

MIO PSE

National Instruments

[David_Lin]

Hi,

Actually, I did have many problems using the DAQmx API that are not clearly stated their limitation or possible problems. I think it is not the fault of the APIs, but of the poor documentation. Several of my colleagues used to complain how troublesome to find a function or to understand how a function operates. We had to do many tests before adding them into our source code. If I were you, I would leave the APIs as they are and urge whoever it may concern to polish the whole help document so that customers would know what to do with the functions.

Give you an example that just happened a few days ago. We connected a series pulses to a counter for period measurement on PCI6251 and we need to find out exactly which pulse edge generate the first valid value in the counter period measurement. The document only says "the first counter value is usually invalid". So is the first rising edge or the 2nd rising edge that causes the invalid value? Only after we did some experiments did we find out it is the first rising edge. If this sentence were mentioned in the help file, we could have saved some trouble.

Anyway, thanks for your effort to help. I appreciate that.

David

[Kevin_Price]

Andrew,

Since you asked for feedback...

Perhaps one way to improve the API is to make it a little smarter about the default values.  For example, 'DAQmx Create Virtual Channel (CI.Period)' would perform period measurement with default units=seconds and default min/max values that make sense only if units = seconds.  However, if I wire in units=Ticks, the default min/max values still have values that only make sense for units=seconds.  I expect this is at the root of the problem in this thread.  These default min/max values caused DAQmx to choose the 20 MHz timebase when units were set = "seconds", but to choose a different timebase (80 MHz) when units were set = "Ticks".

One convention present in other built-in vi's is to set the default numeric value be an illegal value.  This default may be NaN, or for period measurement, -1.  The internal logic of the DAQmx config could then detect which inputs were left unwired, and be able to make more intelligent default choices.  Then if I wire units="Ticks", DAQmx can detect whether min/max are left unwired.  If so, it can pick more sensible default values in order to select the default timebase.  These defaults should, of course, be well documented in the extended help. 

More generally...

I gave the API some thought and I don't see many obvious ways to *change* it that would be universally regarded as an improvement.  However, perhaps instead of a change, a simple *addition* would be helpful?

What I'm thinking is to add a whole additional DAQmx sub-palette.  It would be in the spirit of the way the traditional NI-DAQ palette would first categorize by task type (AI, AO, DI, DO, Counter), then it offered "Easy", "Intermediate", and "Advanced" sub-palettes underneath.   Presently, DAQmx already exposes the equivalent of "Advanced".  What's lacking is something along the lines of "Intermediate" and "Easy".

These "Easy Config" vi's would be special purpose, dedicated to setting up very specific task types.  They would provide enough input terminals to perform all the necessary config prior to "DAQmx Start."   The goal is to let users drop down a single "Easy Config" vi which can be wired directly to DAQmx Start.  (There could even be a boolean input to allow an "Easy Config" vi to start itself.)   The most important kinds of things to support with these "Easy Config" vi's are common tasks which presently require the use of DAQmx property nodes.   Some of these things include the use of "Arm Start" trigger for counter input tasks, "allow overwrite" for continuous AI or DI tasks, and more.

Personally, I've built up several of these for my own use, but it seems like the kind of thing NI could provide, much as they did for trad. NI-DAQ.  Quite a lot of the core code could be extracted from the shipping examples - just turn them into config sub-vis, with appropriate icons and terminal wiring.

Thanks for engaging the topic!

-Kevin P.

[stilly32]

David,

Thanks for the feedback. We are constantly revising our documentation to keep up with the features we add, so I value the feedback on specific parts that need work. I'll get this looked at.

Kevin,

Thanks for both pieces of feedback. I'll make sure our API guys get the feedback about the DAQmx Create Virtual channel. This would take some investigation to ensure that it wouldn't break previous developer's code, but seems feasible. I also think there's merit in the intermediate palettes -one of the challenges we contantly work with is transitioning newer users from the DAQ assistant (which is a great entry level tool but doesn't have the full functionality of the property node) to the example programs. This seems like it would help with some customers, though there is probably a reason we didn't implement it before (even if it was just to differentiate from Traditional DAQ). This is actaully really similar to the generated configuration code you can auto generate from a task - adding it to the pallete would just bypass the configuration settings.

Thanks for the feedback guys, 

Andrew S

Message Edited by stilly32 on 09-26-2007 11:06 AM

Message Edited by stilly32 on 09-26-2007 11:09 AM