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?
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.
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 String.vi, 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!
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
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.
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.
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!