creating an accurate stopwatch withing a loop containing daqmx read

[brubie]

So I switched the mechanical action to switch when pressed, so it works, but now it stays pressed after the program is done. Ive look around and saw someone say that you can wire a false to the stop after the program has run to reset it, but havent found how to do this.

So I also reworked the inside of the stopwatch loop so that it will start and stop when the switches are pressed. It isnt pretty, but it kinda works. However, just from what Ive seen when testing it, it looks like im getting the same kind of issue I had in my first post. It seems like even with the stopwatch out of the loop, values are only sent to the start and stop property nodes after the read loop has finished its iteration. Maybe Im wrong on this one, but thats just my initial thought.

As for the error out forcing dependency. Im wondering how exactly that helps things. Will it just make the program go more smoothly and even faster by having it run things in a certain order?

Thanks again, I am learning lots from you!

[JÞB]

Brubie,

Nice work! I added a few edits to stop some unexpected behaviors (see notes in code).  

The other behaviors you noticed can now recieve some comment.

Using the error chain (or other data dependancy) to enforce execution order is not mandatory however, by not enforcing execution order you offer LV a chance to change the order each time the VI recompiles- In large projects this can really be a headache because what used to work can get a race conditionin a section of code completely unrelated to an edit you made.  Its good practice to enforce execution order especially with time functions.

You are correct that you only update Start and Stop once per read loop iteration.  You only write new values to these indicators from the read loop.  Congrats! you've just created a simple Producer-Consumer vi!  If you want to update them from another location too you now know how to use property nodes to set a value - and you now know how to create a second "Producer" loop.

Good work!

[brubie]

Jeff:

"You are correct that you only update Start and Stop once per read loop iteration.  You only write new values to these indicators from the read loop.  Congrats! you've just created a simple Producer-Consumer vi!  If you want to update them from another location too you now know how to use property nodes to set a value - and you now know how to create a second "Producer" loop."

Alright, so by writing the new start and stop values from the read loop, this causes the values to be updated only when the iteration is over? Which causes the stopwatch to be inaccurate because its not getting the values quickly enough? (I need the stopwatch to be accurate to even a thousandth of a second at least) When you say update them from another location, would that solve my inaccuracy problems? Im not sure how writing values to property nodes and creationg a second "producer" loop will solve my problem..

[JÞB]

---

brubie wrote:

Jeff:

"You are correct that you only update Start and Stop once per read loop iteration.  You only write new values to these indicators from the read loop.  Congrats! you've just created a simple Producer-Consumer vi!  If you want to update them from another location too you now know how to use property nodes to set a value - and you now know how to create a second "Producer" loop."

Alright, so by writing the new start and stop values from the read loop, this causes the values to be updated only when the iteration is over? Which causes the stopwatch to be inaccurate because its not getting the values quickly enough? (I need the stopwatch to be accurate to even a thousandth of a second at least) When you say update them from another location, would that solve my inaccuracy problems? Im not sure how writing values to property nodes and creationg a second "producer" loop will solve my problem..

---

It won't.  sub-mSec resolution is going to be pretty tricky as you are sampling the voltage mS intervals but we can get to 1mS resolution.  We will need to change our focus a bit though. 

It turns out that you don't want the "time" that  LabVIEW calculates that the minimum voltage of the data reaches a threshold.  You want the time that that sample was recorded!    

Here is a code snippet of how to get the timestamp of the minimas.  we can pass this value to the consumer loop as well and use it as either Start time or stop time depending on the state of the start and stop booleans.  You will need to change the data type of the shift register and modify the cases to use this value instead of the current time

 

[brubie]

Hey Jeff. I think that I like where this is going, haha. I added your snippet of code and understand everything that it is doing. I just need a few little things cleared up.

I created a property node and used the property of value. So I wrote to this in the read loop. Now, its just a matter of putting the read property node in the right place in the stopwatch loop? And to deal with the data type, will I only be using timestamp now instead of double? And then I change it back to double at some point and subtract the start and stop times to get the real elapsed time?

[brubie]

Ok, I think I got it. I didnt even have to change the data types at all. I just replaced the "get date/time in seconds" function with the read time minima property node when the start and stop values were true. I think its working. The times Im getting are much more precise and they are 3 decimals long which is good enough for what Im doing i think. This is just what I wanted! 

[JÞB]

OUTSTANDING! 

1 last tip.  "It's OK to have fun!"