08-11-2010 06:06 PM
There is a new VI in LV2010 which returns a high-resolution tick count, however it is not on the palettes, and there appears to be no documentation for it. It is called <vilib>:Utility/High Resolution Relative Seconds.vi
This is present on Windows 32-bit (at least).
08-11-2010 06:25 PM
Wow, that's a neat VI. I didn't know about it either. I checked its diagram...just a callback into an internal LabVIEW function...no cool hidden functions or anything...
08-11-2010 06:58 PM
08-12-2010 05:48 AM
@Darren wrote:
Wow, that's a neat VI. I didn't know about it either. I checked its diagram...just a callback into an internal LabVIEW function...no cool hidden functions or anything...
My version of that vi is password protected. If it nothing fancy why password protect it?
08-12-2010 07:53 AM
It is also present in the Mac version.
Coq Rouge,
I think one of the NI people said that VIs in vi.lib which are not on the palettes are subject to change and are not recommended for routine use. These are often password protected, even though they do not contain any great secrets.
Lynn
08-12-2010 08:30 AM
@johnsold wrote:
It is also present in the Mac version.
Coq Rouge,
I think one of the NI people said that VIs in vi.lib which are not on the palettes are subject to change and are not recommended for routine use. These are often password protected, even though they do not contain any great secrets.
That sound at least reasonable. By the way is this VI used in some example, or somewhere else? Just curious 😉
08-12-2010 09:27 AM - edited 08-12-2010 09:33 AM
@Darren wrote:
Wow, that's a neat VI. I didn't know about it either. I checked its diagram...just a callback into an internal LabVIEW function...no cool hidden functions or anything...
I think we need a better explaination of what the VI output means.
Playing around I created this snippet- Interesting results? Especially the Total elapsed time / mean = 0.5
08-12-2010 05:37 PM
Jeff - not quite sure what you're doing here. The loop is subtracting the current tick count from the previous difference -- so the first value in your array is negative near zero, and the rest are getting more and more negative. The rest is pretty much meaningless - and if you show more digits on the division, you see it's almost 0.5 but not quite, and with a little thought, it will be obvious why that's the case.
The output of this function appears to be simply a high-res tick count (with a precision in the sub-microsecond range) that rolls over at some value - no idea what the "zero" is, but it seems arbitrary. So using it will probably require a check of it being reset. Perhaps someone with access to the block diagram can make a more definitive statement.
I don't think it's used in an example - I just noticed it in the directory.
08-13-2010 09:01 AM
DOH
08-13-2010 09:18 AM - edited 08-13-2010 09:20 AM
Just wiring before coffee. Not a good plan for me.
Fixing the code yields a open loop resolution of @1.2uSec with a Std dev variying with other processes being run. Hmmm. almost could use it to calculate the rest of the CPU load.....