Timed while loop speeding up?

[JÞB]

I see nothing obvious except some nice code.  Which of course means its odd odd odd.  humor me and put an always copy on the dt input to the loop

[JW-JnJ]

---

@JÞB wrote:

I see nothing obvious except some nice code.  Which of course means its odd odd odd.  humor me and put an always copy on the dt input to the loop

---

I will always humor suggestions from this forum, but fair warning. The first error happened 65 hours in and I'm currently running a test to see if it even repeats. Not exactly an agile debug capability.

[Ben]

1) check the system event logs at or about the time of the strnage behaviour.

2) The Finsihed Late boolean will tell you if the loop was delayed.

3) What is your time out fo rthe VISA set to?

Work-out the math and figure out if the total number of iterations for that period of time matches up with what it should have done in theory.

Ben

[JÞB]

---

Ben wrote: 

3) What is your timeout for the VISA set to?

---

VISA gets me thinking..... I notice you are using the generic instr class and the old VISA open.  The System API might give you better performance for searching available resources.  The choice of a generic class for a specific bus is not going to effect the loop timing though.  Knowing if there are any discarded (Late) iterations may be of value for debug reasons.

So I suspect one of two things.  A) the buffer holding dt is corrupt (hence the always copy to force a buffer allocation or B) some rare event occured that caused the loop to change behaviour.  mSec timer rollover is one of those rare events that can get associated with timing changes.  So if noone's done anything silly like re-booting the machine this occured on read the mSec timer on the machine the error occured on and calculate when the last ms timer rollover happened.  Is it proximal to the timing change?  if so we REALLY need R&D notified.

[JW-JnJ]

---

@Ben wrote:

1) check the system event logs at or about the time of the strnage behaviour.

2) The Finsihed Late boolean will tell you if the loop was delayed.

3) What is your time out fo rthe VISA set to?

Work-out the math and figure out if the total number of iterations for that period of time matches up with what it should have done in theory.

Ben

---

1) Oddly quiet. Not connected to internet, no virus software, no anti-spyware, not much of anything. I did notice Adobe periodically trying to update.

3) Default. I think it's 2 seconds.

If I'm stuck on debugging this. Would the best option be to use a regular while loop with wait for next ms multiple?

[Yamaeda]

My knee jerk reaction is, replace the loop with a normal loop with a wait command, but even so, a ms rollover will cause some issue, but should only cause 1 loop erroneosly (sp?).

/Y

[Ben]

---

@Yamaeda wrote:

My knee jerk reaction is, replace the loop with a normal loop with a wait command, but even so, a ms rollover will cause some issue, but should only cause 1 loop erroneosly (sp?).

/Y

---

If we are going to ignore "why" then I am on the same page as Yamaeda.

It may be just a matter of canging the config for the TImed Loop to NOT try and catch up. But then again, if you wait a couple of minutes Jeff will point out that is clearly not the problem so broken clock but how???

Ben

[JÞB]

---

@Ben wrote:

---

@Yamaeda wrote:

My knee jerk reaction is, replace the loop with a normal loop with a wait command, but even so, a ms rollover will cause some issue, but should only cause 1 loop erroneosly (sp?).

/Y

---

If we are going to ignore "why" then I am on the same page as Yamaeda.

It may be just a matter of canging the config for the TImed Loop to NOT try and catch up.

Ben

---

it is set to discard missed periods maintain original phase.  So the why is pretty important because LabVIEW is doing the unexpected.  ms rollover is a odd corner case but may have absolutly nothing to do with it.  (I'm fishing by feel here)

[JÞB]

I just whipped up a vi I'll run in a week or so and see if I can duplicate but it will take some time i'm 11 days to rollover

No I won't post the source I hacked at the OPs stuff without renaming and he would justifiably harm me.

[JW-JnJ]

---

Jeff·Þ·Bohrer wrote:

No I won't post the source I hacked at the OPs stuff without renaming and he would justifiably harm me.

---

You mean the stuff that's currently zipped and already placed in public view? Heh. Either way, thanks for the discretion. I guess I don't get to justifiably harm you today.

Ok, so the theory is that the ms rollover caused this? That might explain a few discrepencies that have been confusing me. We ran this all weekend and it worked before.

Finally, on the topic of wait until next ms multiple. Would this would only cause a problem once during the rollover and only cause the next frame to be delayed? So if I'm doing 5000ms, the last iteration before rollover would be at 4.294965e9, it would then run 2296ms and another 5000ms. So I would only be off by 2.3 seconds? That's noise for me if that's the only potential problem.