LabVIEW Timed Loop falls waaay behind, unknown delay or error

[Ben]

Yes sir!

Ben

#5000

Message Edited by Ben on 12-14-2006 02:57 PM

[LabVU_Dog]

I tried that, I'm testing it now.

I think we are getting a little off base in our troubleshooting, tho. When I use a regular while loop with my own timing, running on the same computer, with the same DAQ HW, and attached to the same process, I don't EVER get these errors. The operating system doesn't change between the two apps!!!! It's tough to see how the OS could cause these problems only with timed loops, and never with regular while loops. It seems that the problem is more likely with the timed loop than the operating system.

The only explanation I could think of for timed vs regular loop is the priority. Timed loops (TL) run in their own priority (between highest and time critical). I can choose to put my regular while loop in a subVI marked time-critical, which is higher than timed loop. It may be that certain OS functions have higher priority than TLs, but lower than LV-designated time critical code. Any ideas? 

[Ben]

"I think we are getting a little off base in our troubleshooting, tho."

Thank you for reminding me about the while loop working correctly. The problem is usually the other way around. All of the suggestions I posted generally help regardles of the loop type.

At this point I ahve to ask "Are you absolutely sure the while loop does not have the problem?" If I were doing it myself, I would want to run for at least twice as long as the other method before I would be convinced it works.

I will probably not have the time to look closer unti lthe week-end but I will try to do so.

Since I do not have any hardware, I will be limited in what I can do.

If you reply indicating that the while loop runs for double the amount of time it takes to hit the timed loop, I'll request an AE get involved to test your code using hardware.

If things are truely as they appear, you may have found a bug. Since I have always seen the timed loops run better than while loops, I am leaning that direction.

Still trying to help,

Ben

[LabVU_Dog]

Great, thanks.

I have never run for more than 4 hours without an event, while using the timed loops.

I ran for 5+ days (24 hours a day) without incident using the regular while loop. I think this meets your criteria.

Lemme know if you need anything else. Thanks for your help resolving this.

[Ben]

I requested support take a look at this.

Make sure the posted zip is complete and they have details on how to recreate the issue.

I will watch for the results.

Ben

[LabVU_Dog]

After all of this, I may have found something. I turned off the fast indexing, and the system ran overnight without issue, using the timed loop. This is longer than it has ever run successfully before. I will continue testing, but I may have been able to narrow it down further.

If it turns out to be the issue, I wonder if there's anything NI can do about it?? Somehow time-critical designation in LV is higher than the indexing service, but high priority is not.

[Ben]

Thank you for the update LabVU_Dog.

You wrote;

"

If it turns out to be the issue, I wonder if there's anything NI can do about it?? Somehow time-critical designation in LV is higher than the indexing service, but high priority is not.

"

Under Windows, there may be no hope. OS's that support virtual memory do so by using the disk drive. So way down in the kernal there are routines that make disk I/O of greater importance.

The good news is that VISTA is just around the corner and MAYBE M$ got it right this time.

Please keep us posted one way or the other.

Ben

[LabVU_Dog]

"Under Windows, there may be no hope..." Many of us have known this for some time!!!

I ran the experiment over the weekend and had no problems. It is still controlling correctly with the timed loop version, indexing service turned OFF. It certainly seems as though we've found the source of the issue.

[Ben]

"It certainly seems as though we've found the source of the issue."

Thank you.

I'll put another check in the "disk indexing" collumn.

Ben