Article - U64 Millisecond Tick Count Utility

[BobHamburger]

Here's a useful little tidbit on my blog

[PaulG.]

"With a U64 output, this millisecond timer will wrap approximately every 584 million years."

Very cool, Bob. This is something to send over to OpenG.

[eaolson]

QUOTE (BobHamburger @ Aug 5 2008, 10:52 PM)

Here's a useful little tidbit on http://labviewinsights.blogspot.com/2008/08/u64-millisecond-tick-count-utility.html' rel='nofollow' target="_blank">my blog

Darn useful. Two quick questions:

1. Why the conditional disable structure? Are there targets for which the Tick Count VI isn't valid?
   
2. Shouldn't the indicator really be outside the loop? I ask not because I suspect it would impact performance, but because I'm just not really clear when putting indicators and controls in a loop does or doesn't.
   

[TobyD]

QUOTE (BobHamburger @ Aug 5 2008, 08:52 PM)

Here's a useful little tidbit on http://labviewinsights.blogspot.com/2008/08/u64-millisecond-tick-count-utility.html' rel='nofollow' target="_blank">my blog

Thanks Bob! That should handle most peoples needs :thumbup:

[BobHamburger]

QUOTE (eaolson @ Aug 6 2008, 10:23 AM)

Darn useful. Two quick questions:

1. Why the conditional disable structure? Are there targets for which the Tick Count VI isn't valid?
   
2. Shouldn't the indicator really be outside the loop? I ask not because I suspect it would impact performance, but because I'm just not really clear when putting indicators and controls in a loop does or doesn't.
   

1. For PXI RT, there is a specific tick count primitive that's tied to the hardware clock. The general tick count primitive is supposed to be also tied to the same time source, but... if that's the case, then why is there another one specifically for RT? It's just hedging my bets.

2. As a functional global, the loop only executes once anyway, so the indicator gets updated exactly once per call. In this case, inside or outside the loop doesn't really matter. The only reason that there's a loop structure in the first place is to support the uninitialized shift registers used to hold numerical values from one call to the next.

[Tomi Maila]

Cool There is one weakness I noticed by inspecting the code. The result will be incorrect if the delay between consequetive calls is more than 2^32 ms.

[jpdrolet]

I did it with doubles some time ago. It is good for 70ky(?) or so, though. I didn't make initialization on first call since its output on first call is arbitrary anyway.

QUOTE (Tomi Maila @ Aug 6 2008, 12:29 PM)

Cool There is one weakness I noticed by inspecting the code. The result will be incorrect if the delay between consequetive calls is more than 2^32 ms.

That can be fixed by running a daemon VI calling it once every 49 day. If that daemon VI does wait and timeout on a notification, it won't take much CPU.

[ragglefrock]

QUOTE (jpdrolet @ Aug 6 2008, 11:53 AM)

http://forums.openg.org/index.php?showtopic=61&st=0&p=172entry172' rel='nofollow' target="_blank">I did it with doubles some time ago. It is good for 70ky(?) or so, though. I didn't make initialization on first call since its output on first call is arbitrary anyway.

That can be fixed by running a daemon VI calling it once every 49 day. If that daemon VI does wait and timeout on a notification, it won't take much CPU.

You could also use the actual system time to see if more than 2^32 ms had elapsed since the last call.

[jpdrolet]

QUOTE (ragglefrock @ Aug 7 2008, 09:41 AM)

You could also use the actual system time to see if more than 2^32 ms had elapsed since the last call.

Yes if you can keep the user from changing the system time. I have an application where the client has a financial interest for reports to be emitted sooner than they should so I couldn't trust the system time and I relied on the timer tick only.

[BobHamburger]

QUOTE (jpdrolet @ Aug 7 2008, 11:28 AM)

...if you can keep the user from changing the system time.

Exactly. The variability of the system time is what motivated me to create this utility. I had an application that extensively used the system time to determine time intervals in a number of different contexts, and there were strange faults in these various modules that eventually were traced to the time primitive not behaving as desired.