Timed while loop speeding up?

[JW-JnJ]

I apologize in advance for not posting all the code, but it's a fairly large project and I think I've already narrowed down the problem.

The data logger loop (below) sends a GPIB read command and sends the data to a queue for writing and processing. This VI will only execute once, so the sample rate is only sent to the timed while loop once.

The stop VI is shown below, which causes the loop to stop when an error occurs, an error anywhere in the project occurs, or a stop is sent. So if an error did occur in this loop, it would have stopped.

Now down to what happened. The technicians came in and said there was an error window that had popped up (they didn't save it sadly) and the logger was going REALLY fast. I looked at the saved data and it shows that at 65 hours in (~46980 GPIB read commands), the logger suddenly sped up. It started at 5 seconds reads for most of the test, went to ~1.4 seconds for one data point, then blazed on at 0.24 seconds for the remainder of the test.

I don't know the error, but I think that is a moot point now and could have been caused by the speed up. The biggest question is why did my loop suddenly speed up between iterations? Any error "should" exit the loop.

I'm working to see if the error will repeat (65 hours from now), but I do know I ran tests on another machine that went 80+ hours so I'm not holding my breath.

[JW-JnJ]

One more thing. It was compiled and installed.

The problem occured on a different computer than the successful test run.

[JÞB]

I'm confussed.  The Loop should finish uncompleted frames untimed and exit on error! since there is only 1 frame stop.vi would never get an error in and can only stop with stop set from some other location.  Nothing should be able to hack into the dt and change it's value that I can see from here.  Is there perhaps some method that can restart the loop with bad values?

[JW-JnJ]

---

@JÞB wrote:

I'm confussed.  The Loop should finish uncompleted frames untimed and exit on error! since there is only 1 frame stop.vi would never get an error in and can only stop with stop set from some other location.  Nothing should be able to hack into the dt and change it's value that I can see from here.  Is there perhaps some method that can restart the loop with bad values?

---

Nope, the parent of this VI doesn't have a loop. It's only executed once.

I have a feeling I may be using the error inputs to the while loop wrong. Do they not act as a shift register as well as error handling? The help (and googling) is rather vague to me on that topic.

**edit** I understand what you're saying. The error would cause the loop to exit and not send the global stop to the rest of the program. My structure is wrong so thanks for pointing that out. Yes, I'm still confused as to why it would start running faster.

[JÞB]

The code shown could not (to the best of my eyeballs ability) cause a loop speedup.  The error chain does act inplace so essentially like a SR except for the untimed finish for the error frames downstream of an error (Not happening here since you have a 1 frame loop)

This points me back to the caller possibly a corrupted enum that forgot to get type-def'd or a typo in a case selector string?  A wrong queue reference? silly stuff like that that causes an unintended state transition and relaunches your loop (heaven help you if its reentrant share clones)  All little bugs that mess with your QSMs and are easy enough to write but a bear to debug.

[JW-JnJ]

---

@JÞB wrote:

The code shown could not (to the best of my eyeballs ability) cause a loop speedup.  The error chain does act inplace so essentially like a SR except for the untimed finish for the error frames downstream of an error (Not happening here since you have a 1 frame loop)

This points me back to the caller possibly a corrupted enum that forgot to get type-def'd or a typo in a case selector string?  A wrong queue reference? silly stuff like that that causes an unintended state transition and relaunches your loop (heaven help you if its reentrant share clones)  All little bugs that mess with your QSMs and are easy enough to write but a bear to debug.

---

I'm all for things I don't expect, but this is a very linear program. The parent VI is the compiled executable.

It runs gathers information from the user, runs setup, then splits into parallel loops (Logger loop mentioned above, GUI loop, data handler, and disk writing loop with queues for data communication). If any of them exit, the program hits the error handler and then will exit completely. No state machine and no way for it to loop back to this VI.

I haven't hit the level of LV programming where I use state machines for everything. Probably why I'm stuck at this level.

Thanks

[JÞB]

---

@JW-L3CE wrote:

---

@JÞB wrote:

The code shown could not (to the best of my eyeballs ability) cause a loop speedup.  The error chain does act inplace so essentially like a SR except for the untimed finish for the error frames downstream of an error (Not happening here since you have a 1 frame loop)

This points me back to the caller possibly a corrupted enum that forgot to get type-def'd or a typo in a case selector string?  A wrong queue reference? silly stuff like that that causes an unintended state transition and relaunches your loop (heaven help you if its reentrant share clones)  All little bugs that mess with your QSMs and are easy enough to write but a bear to debug.

---

I'm all for things I don't expect, but this is a very linear program. The parent VI is the compiled executable.

It runs gathers information from the user, runs setup, then splits into parallel loops (Logger loop mentioned above, GUI loop, data handler, and disk writing loop with queues for data communication). If any of them exit, the program hits the error handler and then will exit completely. No state machine and no way for it to loop back to this VI.

I haven't hit the level of LV programming where I use state machines for everything. Probably why I'm stuck at this level.

Thanks

---

Well-  How about zipping the whole ball of wax I'll put eyes everywhere

[Ben]

Wild guess.

The Loop is NOT configured to discard missed...

When the queue backs up (is it fixed length?) the loop stalss missing cycles and it tries to recover.

Done with the wild guess thing.

"Finished Late?" is a property returned by the Timed Loop.

Ben

[JW-JnJ]

---

@JÞB wrote:

Well-  How about zipping the whole ball of wax I'll put eyes everywhere

---

Heh, normally I would hem and haw about proprietary but this took a few days to make and it's not worth it.

If you have the time, thanks. There is a variant of the Logger Loop VI that I'm about to try out using the next MS multiple. Haven't tested it out yet.

Sorry about the slightly messy code, this was a fast and furious development.

[JW-JnJ]

---

@Ben wrote:

Wild guess.

The Loop is NOT configured to discard missed...

When the queue backs up (is it fixed length?) the loop stalss missing cycles and it tries to recover.

Done with the wild guess thing.

"Finished Late?" is a property returned by the Timed Loop.

Ben

---

This is a VERY slow logger (5 second sampling, decimated by 4 to disk, run for days on end) so I'm running on the assumption that I should not have a queue backup. Saved coding time, but it's probably what bit me when the instrument reading loop went crazy.