measure time lapsed from reaching threshold to execution

[nighthawk117]

Thank you for your help. Much appreciated. 

For the sake of comparison, the 2nd image does not suffer the same time lapse increase problem

------------------added --------------

I do not fully understand how this solved the issue but it seems now I no longer suffer from the time lapse continuing to increase.

[RavensFan]

You still need to move the Create DAQmx outside of your outermost while loop.  And you still need to close the task after the while loop is done.

[nighthawk117]

If i move it outside my outermost while loop, I get the error message shown below. 

I think I need to keep them all inside my outermost while loop though..The outermost while loop is for the program to check which buttons Im pressing on the front panel. 

I can move the physical channel outside the outermost while loop without getting an error message.  

[RavensFan]

Because now you actually put the close task in there, but you left it inside the loop.  So it kills the task after the first iteration.  The Close Task needs to be AFTER the while loop.

Please look in the Example Finder at DAQmx examples!

[nighthawk117]

I hope I got it right this time.

Thank you for your patience. 

[JÞB]

---

@nighthawk117 wrote:

I hope I got it right this time.

Thank you for your patience. 

---

That is a lot closer.

Now let's look at the fine details of loop timing.  The times loop will iterate at the lower of, DAQmx read acquisition time or, 1kHz.

You should remove the timed loop.

[nighthawk117]

Ah.. i just left my lab.  I will edit this post once i have access to the computer and remove the time loop.  It's not clear to me how i would trigger the clocks but ill think about it. I was getting anywhere between .5ms and 3ms.  (The gap between the two groups of times was huge. I never got values inbetween.  Never 1ms )

[JÞB]

---

@nighthawk117 wrote:

Ah.. i just left my lab.  I will edit this post once i have access to the computer and remove the time loop.  It's not clear to me how i would trigger the clocks but ill think about it. I was getting anywhere between .5ms and 3ms.  (The gap between the two groups of times was huge. I never got values inbetween.  Never 1ms )

---

That is because of the multiple timing dependancies.  And, 1 read per loop will time the loop just wonderfully.

Its obvious that you have been reading help files and listening to advice here.  Our patience won't wear out while you continue to improve. 

[nighthawk117]

After much thinking, below is what I came up with.

I activated "highlight execution" and watched when the timers were getting triggered. 

It appeared that the first timer was getting triggered when the outer case structure was touched.

It appeared that the second timer in the inner case structure was triggered last after the turn off command was executed. So it does seem that I am accurately measuring the time lapse from the moment the voltage is getting read and the power source turn off command is executed.  I am not sure what ensures that "the high resolution relative clock" knows when to get executed. 

[JÞB]

The basic idea is "Dataflow"  any node in an executing diagram or sub diagram that has all of its inputs can execute.   The error chain is often used to enforce order of execution.   For nodes with no inputs, like hi res timer, a sequence frame can be used to enforce order of execution. 

Highlight execution forces LabVIEW to run in a single thread.  With it off, nodes can ru. At the same time.  So, you are tricking yourself again.