Jump to content

Article - U64 Millisecond Tick Count Utility


Recommended Posts

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

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.