Best way to continuously assign and compare two time stamps for an indefinite amount of time

[Mr_Papagorgio]

I am writing a VI that calculates the flow rate, in GPM, of the output of a flow meter. The VI works fine I'm just wondering what is the best method for continuously assigning time stamps for an indefinite amount of time.

Currently every time voltage is rising and is greater than 0.02V I am assigning a time stamp to that event, using the Tick Count block, then performing the flow calculation to determine GPM. Essentially I'm using the period of the waveform to determine the flow rate.

Since the Tick Count block rolls over after a certain amount of time I'd like to know if there is a better method for assigning a time stamp.The program will run for an unknown amount of time and I'd like to avoid the roll over condition. Thanks.

[billko]

How about Get Date/Time In Seconds Function to assign a real timestamp instead?  You can do simple subtraction to get relative time between two events.

Edit:

Ugh, you need better resolution.  Sorry.

[paul_cardinale · Accepted solution]

Instead of "Tick Count (ms)", use "Get Date/Time In Seconds".

I've also put a few other improvements in your code.

[Mr_Papagorgio]

Paul,

Thanks for your help. Would the roll over condition now occur as time changes from AM to PM and PM to AM?

[MichaelBalzer]

If you store the tick count as a U32 (not coerced to double), you can do a subtraction of the two and not worry about the roll-over condition*. For example if your previous tick value is just before the U32 rollover (say 4294967290) and the following tick value has rolled over (say to 5), then the difference is calculated correctly as 11 ticks:

*Of course this won't help in the case where your previous tick is from a previous roll over (ie more than ~50 days ago), but it's probably unlikely you won't have some sort of flow in that time period.

[Kevin_Price]

Better yet, you've already set up a hardware-clocked task.  You're gonna get much better accuracy and repeatability if you base your delta time calculations on the *that*.

You should probably read multiple samples per loop iteration and then keep track of the cumulative sample # index where your criteria are met.  I'd also recommend reading as a waveform so you get the real "dt" value.  Due to quantization, it may be different from the nominal (1 / requested_sample_rate). 

The difference in indices from previous to now can be multiplied by the dt to give you a more accurate time interval measurement.  Also, by using the buffering feature of DAQmx, your time measurement accuracy no longer depends on your software loop or Windows.

-Kevin P

[paul_cardinale]

---

@Mr_Papagorgio wrote:

Paul,

Thanks for your help. Would the roll over condition now occur as time changes from AM to PM and PM to AM?

---

There is no rollover on timestamps.  They just keep getting bigger.