04-30-2018 01:33 PM
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.
Solved! Go to Solution.
04-30-2018 02:13 PM - edited 04-30-2018 02:17 PM
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.
04-30-2018 02:16 PM
Instead of "Tick Count (ms)", use "Get Date/Time In Seconds".
I've also put a few other improvements in your code.
04-30-2018 02:25 PM
Paul,
Thanks for your help. Would the roll over condition now occur as time changes from AM to PM and PM to AM?
04-30-2018 10:31 PM
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.
05-01-2018 11:32 AM
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
05-02-2018 11:40 AM
@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.