LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

microsecond tick count

I can easily measure loop times in the low microseconds after doing some modifications.

Try a loop time of 0, 1, 2, or 3 ms for example. You'll also notice that on many modern processors, a 1ms will turn into a 2ms wait.

I am still not entire sure about the U64 division. Maybe it is OK.

See attached example (LabVIEW 8.2)

 

Message Edited by altenbach on 09-03-2007 01:56 PM

Message 11 of 15
(4,697 Views)
The file is saved on v8.2. Can you please save it as v8.0?
0 Kudos
Message 12 of 15
(4,525 Views)

Althought this thread is just short of 2 years old, I have some questions regarding sub millisecond timer work, such as in the HighResTimer.vi that was posted here.

 

One of the comments in this thread indicates that on some chipsets and multicore systems, the QueryPerformanceCounter does not necessarily work correctly. 

 

On the MSDN boards for QPC, I found this remark:

"On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function."

 

So, is the problem of QPC in Labview only that it may poll the Counter from a different thread? Is there a way to circumvent this, with the SetThreadAffinityMask function to only call the HighResTimer.vi using a specific thread?

 

 

Other things I've read about this:

"If there's heavy bus traffic, on many, common chip sets, even very new ones, this timer may suddenly jump between one and four seconds forward in time (boo!). I believe there is some internal race WRT this counter being 64 bits, but kept in two separate 32-bit registers, but don't hold me to that."

 

 Is all of this true?

 

What I want to do: monitor parallel port and determine the time between consecutive pulses. The pulses are spaced approximately 25ms apart, so using the ms tick counter, even one ms off and I have a 4% change... I don't want much more resolution, really 1-2% margin of error is okay. Will the QPC be alright for my purposes?


Or is my misunderstanding of this all skewed?

 

 

 

Thanks

Brian

0 Kudos
Message 13 of 15
(4,170 Views)

Here is an 8.0.1 version of the code (Windows only!).  It includes VIs to query the frequency of the counter, the tick count, and calculate the interval from two tick counts.  It will only work on processors which have a high resolution timer (I think this was introduced with the Pentium Pro, but it has been awhile and I could be wrong).

 

Note that due to the multi-tasking nature of Windows, you should probably take a large set of measurements and then take your minimum.  Be sure to take into account your infrastructure time (loop time, VI call time, etc.).  It can be challenging, but it is also fun to figure it out.

 

Let us know if you need more info.

0 Kudos
Message 14 of 15
(4,150 Views)

FYI:

 

If using LV Real-Time is an option then sub-microsecond measurements can be performed by uisng hardware clocked counters. Using NI stuff I used an 80 MHz clock to meassure node to node SCRAMNet trasfers. Please ntoe that at these time intervals the overhead of calling VI WILL affect your mesurements.

 

Have fun!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 15 of 15
(4,147 Views)