09-18-2017 02:15 PM
Hi all, I have a VI that basically automates a temperature ramp. once the Ramp Temp button is pushed the VI pull two rows of data from a .csv file (Setpoint and duration) to create a temperature ramp. All seems to work find but in the case that I would like to disrupt the ramp and go back into manual mode, I can't stop the VI while it's holding its wait time. Is there a simple way besides aborting the whole VI since this is a small part of bigger VI? Thanks in advance!
09-18-2017 02:22 PM - edited 09-18-2017 02:25 PM
09-19-2017 02:38 PM
Thanks Gerd that was a quick response! Yeah, I came to that conclusion. Your loop still will not work since you have the long wait and the3 conditional terminal will only execute after the delay. I'm thinking to just put a constant on the wait at 500 and double the time and put it to the N count terminal of the for loop. At least it should be able to pick up a stop command every 500ms. On another note, your simplified version causes the output of the index array to change from an element to a subarray. This would be an issue for the input of the N count and next to be converted.
09-19-2017 03:52 PM
I don't see any subarrays in Gerd's VI snippet.
All he did was take what you had and simplified it. He only told you how to improve upon it. He didn't code up his suggests for shorter waits and repeat reading of the stop button and more frequent intervals.
09-19-2017 04:28 PM - edited 09-19-2017 04:36 PM
I always do timer loops like this:
Yes, there is a little more going on in here than waiting but in a nutshell the last time the loop exited (timestamp) is used in the data collection state and using a shift register fed back to the timer loop as the start time.
The scan interval (wait time) is added to the start time and the current time is subtracted until is is equal or less than 0
As you can see if the Stop button is pressed the timer loop will immediately (10mS at the most) exit.
09-19-2017 05:35 PM
(On a side note, if you would use a timed loop, you can finish the waiting loop using this tool.)
09-20-2017 08:38 AM
I was looking into this and running into an issue with it (my lack of experience with it). I going to hit up Gerd's idea with a for loop x amount of time with a smaller wait delay so I can stop it. When I have more time, interested for sure into the timed sequence and the stop option. Thanks!
09-20-2017 08:39 AM - edited 09-20-2017 08:40 AM
@RTSLVU wrote:
I always do timer loops like this:
Yes, there is a little more going on in here than waiting but in a nutshell the last time the loop exited (timestamp) is used in the data collection state and using a shift register fed back to the timer loop as the start time.
The scan interval (wait time) is added to the start time and the current time is subtracted until is is equal or less than 0
As you can see if the Stop button is pressed the timer loop will immediately (10mS at the most) exit.
Creative, nice!
09-20-2017 09:16 AM
@RTSLVU wrote:
As you can see if the Stop button is pressed the timer loop will immediately (10mS at the most) exit.
Technically, it is 20mS at most. Because you didn't enforce data flow, the stop button control could be read (as FALSE) at the beginning of the loop. If you then press Stop immediately after the read but before the Wait starts, it would not be TRUE until after the next iteration of the loop.
For your example, a 20mS vs. a 10mS delay is still negligible. But it could make a big difference if the wait time was longer (multiple seconds). I got burned a few times when I first started programming and didn't quite understand all the nuances of dataflow. There are times I will use a Flat Sequence to force reading the Stop button value after the wait competes so that the loop exits at the proper time.
NOTE: I hate using Sequences. Is there a better way?
09-20-2017 09:24 AM - edited 09-20-2017 09:26 AM
@jamiva wrote:
Technically, it is 20mS at most. Because you didn't enforce data flow, the stop button control could be read (as FALSE) at the beginning of the loop. If you then press Stop immediately after the read but before the Wait starts, it would not be TRUE until after the next iteration of the loop.
You are technically correct, and that's the best kind of correct! 😛