Can someone clarify how this works?

[GregFreeman]

http://forums.ni.com/t5/LabVIEW/tick-count-vs-get-date-time-in-seconds/m-p/1074081/highlight/true#M4...

The link above is to one of Ben's posts where he says calculating the difference using tick count wont have problems when rolling over. How does this work? I am wondering because I am using a tick counter in FPGA to calculate RPM by storing the last value in a shift register and when a certain event happens, getting the current tick counter value and finding the difference. Pretty trivial. I just want to make sure when it rolls over to zero, I don't get something like the following

1 revolution/(0 - 4 billion).

That would result in a spike to essentially 0 in the RPM data

[tbob · Accepted solution]

Tick count output is a U32.  The maximum value of a U32 is 4294967295.  Create a small vi with two U32 controls and one U32 indicator.  Subtract the first U32 from the second one and send the result to the indicator.  Set the first U32 to 4294967294 and second one to 5, to simulate the tick count rolling over past the max value going to 0 and then to 5.  The difference should be 7.  Tick count went started at 4294967294 and went 4294967295, 0, 1, 2, 3, 4, 5.  This is 7 ticks.  So the rollover to 0 does not affect the tick counts.  This is due to the upper and lower limits of a U32.  If you did the subtraction manually, 5 - 4294967294, you would get a negative number.  Since U32 cannot be negative, it takes the 2's compliment and the result is a positive number, which comes out to be 7.  So you can safely use Tick Count at any time.

The following example shows this is true:

[smercurio_fc]

The rollover issue used to exist with earlier versions of LabVIEW. Somewhere along the way (not sure which version), NI made the subtraction "smart" in that it takes into account this rollover issue and gives you the expected result.

[tbob]

---

@smercurio_fc wrote:

The rollover issue used to exist with earlier versions of LabVIEW. Somewhere along the way (not sure which version), NI made the subtraction "smart" in that it takes into account this rollover issue and gives you the expected result.

---

Are you sure about the rollowver issue in earlier versions of LV?  Just a plain old subtraction of two U32s gives the desired result.  Lets say the first tick count is 4294967295 and the second is 1.  If you create two U32s, and subtract the greater from the smaller, the U32 result will be 2, not using Tick Count at all.  If you set all to I64, then 1 - 4294967295 = -4294967294, which is beyond the limits of a U32 (cannot go lower than 0).  Convert the I64 to a U32 and you will get 2.  It has nothing to do with Tick Count function.  It is all in U32 representation.  See example below:

Pehaps in older versions of LV the Tick Count output was I32.

[smercurio_fc]

---

@tbob wrote:

---

@smercurio_fc wrote:

The rollover issue used to exist with earlier versions of LabVIEW. Somewhere along the way (not sure which version), NI made the subtraction "smart" in that it takes into account this rollover issue and gives you the expected result.

---

Are you sure about the rollowver issue in earlier versions of LV? 

Pehaps in older versions of LV the Tick Count output was I32.

---

I'm sure. That's why we always had to use a VI to perform proper subtraction of tick counts when timing things. It wasn't I32 - it was U32. For the example you gave before, if you use LabVIEW 6.1, the subtraction yields 4294967290.

[tbob]

---

@smercurio_fc wrote:

.... For the example you gave before, if you use LabVIEW 6.1, the subtraction yields 4294967290.

---

I've used Labview since 5.1 and never knew this flaw existed.  I must never have used Tick Count, or I got lucky that I didn't encounter a rollover.  It seems like it was actually a flaw in the subtraction of U32s, when the result yielded a negative number.

[smercurio_fc]

Actually, a correction: LabVIEW 6.1 behaves correctly as far as the subtraction is concerned. I had simply done the subtraction incorrectly. I do know the issue with the Tick Count existed in earlier versions, though.