zeros in charts

[exo]

It certainly stops quicker but the sample rate adjustment isn't right. I'll see if I can figure out what you did.

[exo]

I think I see what's wrong. The true case need one execute once.

[RavensFan]

Yes, the first point isn't taken until the sample time is up.  An alternative would be to take the iteration node, put in an =0 condition and wire that to the existing conditional statement with an OR.   That way it will execute on the first loop iteration getting the point, and then after every time interval after that.

Message Edited by Ravens Fan on 01-17-2008 12:27 PM

[exo]

Like this? This didn't work

[TroyK]

just a couple of refinement suggestions...

The way that your vi is currently wired, the Stop button is read immediatly once the loop executes.
That means that after you press the stop button, you still have to wait for the remainder of the 1000ms to lapse, then it loops again because the value of the stop button has already been read as FALSE before you pressed it.

To fix this problem...
Check the value of the Stop button AFTER your main case executes. (Maybe put it in a sequence structure wired to an output of the main case.)

Instead of using a 'wait(1000ms)', use a 'Wait Until Next ms Multiple'.
Move the 'Wait Until Next ms Multiple' into the FALSE case of a new case structure from the value of the Stop button. (So you only wait the 1000ms if the stop button hasn't been pressed.)



That should help it to stop faster and without executing another loop. It may be a bit crude, but it will work.

Message Edited by Troy K on 01-18-2008 12:53 PM

[TroyK]

Actually, now that I think about it again, unless you make it check the value of the stop button AFTER the wait time has elapsed, it will loop around again regardless.
So the solution is similar to what I suggested in the previous post...


Checking the value of the stop button should be the last thing you do in the loop.


Message Edited by Troy K on 01-18-2008 01:07 PM

[RavensFan]

---

exo wrote:
Like this? This didn't work

---

Yes, that will be sure that a point gets read immediately, then waits 60 seconds to take the next point.  But the loop overall loop will run much faster for a much quicker response to the stop button.  In what way does it not work?  Please provide details.  What is it not doing the way you expect it to?

Troy wrote:

The way that your vi is currently wired, the Stop button is read immediately once the loop executes.
That means that after you press the stop button, you still have to wait for the remainder of the 1000ms to lapse, then it loops again because the value of the stop button has already been read as FALSE before you pressed it.

To fix this problem...
Check the value of the Stop button AFTER your main case executes. (Maybe put it in a sequence structure wired to an output of the main case.)

Instead of using a 'wait(1000ms)', use a 'Wait Until Next ms Multiple'.
Move the 'Wait Until Next ms Multiple' into the FALSE case of a new case structure from the value of the Stop button. (So you only wait the 1000ms if the stop button hasn't been pressed.)

---

Yes all of what you said is true, but I don't think it's a major concern.  The original problem was like you said, but the wait times were 60 seconds, thus it could conceivably take almost 2 minutes for the Stop button to act.  Now the code should do what he wants it to do, and the lag time would be down to about 1-2 seconds.  Not a huge problem.  If that is too long, then the wait could be reduced to about 100 msec, and that would seem like near instantaneously to a user.  I don't think there is a significant difference between wait msec and wait until next msec in most use cases.  But, I'll give you that the Wait until next ms would be the better choice.

[TroyK]

The main reason I suggested the 'wait ms multiple' was because it would give more consistant timing on the loops. If the code takes 50ms to execute, then you wait 1000ms, loop time will always be 1050ms, giving inconsistant time stamps. Using the 'wait ms multiple' will give you much better timing in that case.

If the 1000ms timer was originally a 60000ms timer (I didn't read through entire post) then as you suggested, perhaps changing it to a 100ms timer in it's own while loop checking the stop button would be much better.


Message Edited by Troy K on 01-18-2008 01:50 PM

[RavensFan]

The original problem was a 60,000 ms timer.

Yes, the wait until next ms would give more accurate loop timing.  Given that the problem was based on a 60 second interval, it didn't seem like the application demanded such precise timing.  Even if you accumulated almost 60 loops of 1050 ms, thus accumulating 3000 ms of error, the condition mechanism would stop it after 60 seconds the the error would probably be only on the order of a couple hundred ms which is nothing compared to the overall 60 second interval and the fact that the communication is being done by TCP/IP.  Nothing about the application seems to indicate msec precision is required. 

But yes, I agree with you that wait until next is better.  I just put down some code to get the concept across because the poster didn't seem to be understanding by way of words.  And 100 msec would be better than 1000 msec for speediness of response.  The key point I wanted to show was that some sort of wait is necessary because the false case which would execute 59 out of 60 seconds or (59.9 out of 60) is doing nothing and would probably use 100% of CPU resources.

I also decided to use timestamps rather than the tick counter because I figured there could be some hiccups whenever the tick counter rolled over, or perhaps when the clock rolls over at midnight.

[TroyK]

Ahh, I understand now.
Yes the ms timer rolls over every 42 days or something like that.