Showing results for 
Search instead for 
Did you mean: 

Best way to measure time?

I have labview 7.0 and SC-2345 with several digital inputs. I have to measure time between digital input(rise or fall)and stop signal comes in my program with compare etc.
I have tried to measure time with 4 sequences and "get date/time in seconds" and i have also tried to use loop with shift register.
It seems not to work or accuracy is not enough. so how to do that?
0 Kudos
Message 1 of 16
Try with Tick counts (ms). That's the usual tool for software timing. Not very accurate (Windows may introduce lags), but simple to use.

Chilly Charly    (aka CC)

         E-List Master - Kudos glutton - Press the yellow button on the left...
Message 2 of 16
We can help you better if you you help us!

The SC-2345 does not tell us much about the nature and capabiilites of you data acquisition hardware.

Please provide as much info as you can provide.

Also post an example of the code you have developed to date. We may be able to spot something that is simple and you can be on your way.

What kind of acuracy are you after?

This can mak a big difference in how the problem should be resolved.

So, again, please help us help you by providing more details of what you need to do, what DAQ you have and what you have done to date.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 16

So here is my program, or piece of it.
My system is:
Computer, Fujitsu amilo P4 3.2 GHz 512 mb
PCMCIA card, DAQCard-6036E
SC-2345 signalbox, 3 SCC-CI20 analog inputs, 5 SCC-DI01 digital inputs.
Labview 7.0

i would like to measure elapsed time of the program, accuracy should be 10 ms ? or 100 ms, 1 ms is very good, 100ms is not so good...
In my program, user must give option which sets stop signal, option are: value of the slider or time.
In my real program, options are travelled distance, value of the pressure or time.

Is it bad if i have in my real program several parallel while loops? like 10 ?
I also read values from analog input.

thank you, i gladly re-post if you have more questions.
0 Kudos
Message 4 of 16

Like the above posts have said, that this will not be extremely accurate and you will have to run it to determine the exact accuracy. Nonetheless, you can use the Get Time/Date, and use it at the beginning of your program, and then at the end. You can then subtract the times, to figure out the elapsed time. The parallel loops are fine to use. Have a Great Day!

0 Kudos
Message 5 of 16

A few general comments about your code:

You use multiple terminals with identical names so their local variables would look exactly the same. This is just asking for trouble. A mixup will lead to infinite grief in the future.

There is no conceivable reason to even have the orange local variables. Simply wire from the "prompt user" ouputs to the appropriate locations.

You write to the boolean local in up to three parallel cases and at the same time also read from it, all in paralell. The behavior is completly unpredicatble.

What is the purpose of the FOR loop on the left? It simply spins at full speed, consuming all CPU doing nothing and starving all other processes at the same time.

I am sure your code could be simplified to 20% of it's complexity, in the current form it cannot be trusted. Where does your digital input tie into it?
0 Kudos
Message 6 of 16
FOR-loop ? i dont see any for loop, how to find it?
thank you for your answer, but i recommend you to be little more friendly...
i can change my system anytime to away from national instruments and that is not what NI wants..
but thank you
0 Kudos
Message 7 of 16
Hello Jani,

no reason to be angry... I don't think Mr. Altenbach was unfriendly, when he commented your code. He only pointed out some programming rules, that can be found in the guide lines...

I also would add a sentence from the actual thread "LabView proverbs": "The shortest connection between two points is a straight line". Just keep your wires short...
For the parallel cases: There's an unpredictable behaviour when writing/reading the boolean local. And why do you compare the controls with their own locals? How should it be possible that option1 is greater then option1 ? They should always be equal, so boolean is always true - you can also wire a boolean constant to it (or the case selector, as this is the true case).

Also your timing is very "critical". You count the times you wait for 1ms multiple. I doubt this will give you the elapsed time value. It should be better (more accurate) to get the time (or tick count) before/after the big while loop and just get the difference of both.

Mr. Altenbach surely meant the smaller while loop at the left. It has no timing included, so it takes full CPU time. This was bad coding 20 years ago and it is bad coding today... As mentioned above: check the programming guide lines.

Best regards,
Best regards,

using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 8 of 16
I am very sorry If you feel I came across unfriendly in any way, my intentions were sincere and I wanted to help you improve your code by pointing out some common mistakes. Believe me, some of my early labVIEW diagrams from 10 years ago are much worse. In the meantime I have accumulated some experience with daily use, but am still learning every day. 🙂

By the way, I an not affiliated with National instruments. This is mostly a peer help forum where LabVIEW users from all over the world help each other improve their coding skills. (Only users with blue names are employed by NI!)

Certain things are not obvious looking at your code and once the desired functionality is clear we can help you to a more optimized version that actually works. 🙂 Whatever you are feeding to the "elapsed time" indicator has nothing to do with elapsed time, but counts the iterations of the middle while loop. It is either 1 or 2, depending on the inputs. There has to be a more interesting output (see my next post!). 🙂
For example, let's just look at your inner while loop (see attached image). (1) The number of iterations is known when the loop starts, thus a FOR loop is more appropriate. (2) You are comparing a DBL with an integer using "equal". If by chance the operator would enter a fractional time (e.g. 1000.5), the comparison would never become true and this loop would go on forever. Your program will never finish! Not good!
An alternative, but safe code is shown below in the image. For integer times, it has exactly the same functionality.

Apparently, you want to measure elapsed time, and I am guessing elapsed time used by the code in your middle loop. I will attach a simplified example based on your program in the next message here.
Message 9 of 16
Sorry, I forgot to attach the image mentioned above. Instead, you'll see the suggested inner loop replacement in the attached example that I whipped up in a few minutes (sorry, it probably has a few little bugs but should show the basic ideas).

Basically, I tried to duplicate your comparison logic but created data dependency to prevent the race conditions mentioned in my first post. The code measures the actual time in ms used by the code in the inner sequence using "tick count".

(In your actual VI where you measure the timing of the state of a digital line, quite a few changes must be made, of course.)

Let me know if you have any questions. We're all here to help. Happy wiring. LabVIEW is fun!
Message 10 of 16