10-03-2011 08:44 PM
Hi All,
I'm dealing with a condition now where a VI will not respond to the "Abort" button, or will respond on a very delayed timeline. What can cause this?
Regards,
Ken
10-03-2011 09:04 PM
10-03-2011 09:11 PM
Without seeing your vi or knowing what it's doing we can only guess.
Here are some other guesses:
1) Do you have loops with no delay that cause the CPU to be maxed out?
(Check this with Windows Task Manager)
2) Is there Network or instrument communication in the vi?
Check the timeout settings
3) Are there Queues or Notifiers waiting for certain conditions to occur?
That's a start without knowing any details,
steve
10-03-2011 09:27 PM
It looks like it's this VISA FInd Resource Function, which appears twice in my code. Once in the Arduino libraries and once in my custom "Serial port ID" search code.
Can I keep this function from blocking?
10-03-2011 10:06 PM
Your code has greedy loops. without any delay or VI which waits for some event the loops run as fast as possible. They are starving the CPU of cycles making your code unresponsive. At a minimum put a Wait with a 0 wired to it. Even this will allow the scheduler to invoke other code or process events such as the abort button.
On another note you should not use the abort button to end your application. You should have UI code that processes the user interactions and controls the execution of your code.
10-03-2011 10:10 PM
Hey Mark,
I overlooked that, thank you. Out of curiousity, does anyone have a link to an explanation as to why loops are "greedy" by default. Is the "greedy behaviour" solely responsible for causing these loops to act this way? I use the Abort button a bit more than I should, but I always have a proper stop as well, which was also hanging due to this.
Thanks!
- Ken
10-03-2011 10:14 PM
@xkenneth86 wrote:
Hey Mark,
I overlooked that, thank you. Out of curiousity, does anyone have a link to an explanation as to why loops are "greedy" by default. Is the "greedy behaviour" solely responsible for causing these loops to act this way? I use the Abort button a bit more than I should, but I always have a proper stop as well, which was also hanging due to this.
Thanks!
- Ken
Core loop structures should never have built in delays. It should be up to the programmer to control execution. There are times when a greedy loop is desireable. You just have to make sure they don't run forever or wait on some other process that is getting starved.
10-04-2011 01:41 AM
@xkenneth86 wrote:
Hey Mark,
I overlooked that, thank you. Out of curiousity, does anyone have a link to an explanation as to why loops are "greedy" by default. Is the "greedy behaviour" solely responsible for causing these loops to act this way? I use the Abort button a bit more than I should, but I always have a proper stop as well, which was also hanging due to this.
Thanks!
- Ken
Very often loops are used to perform calculation or operations on a limited data set (as FFT) in which you dont want to introduce delays.
The greedy behaviour is most probably the sole reason, it's a common problem of "laggy" feeling.
/Y
10-04-2011 02:15 AM
I seriously doubt that your loops are the problem. Your VI1... loops over a (hopefully) small list of resources while VI2... does not loop at all (the while loop is not even needed to retain the current functionality). What is the actual output of "VISA find resource"? Can you run it in a small VI and show us the output?
I think your problems are elsewhere. Can you attach the actual VI?
What else is there?
btw: you can eliminate wiring to N and indexing based in the iteration terminal by simply autoindexing over the array at the loop boundary. Keep it simple. 😉
10-04-2011 06:48 AM
It's not the loops honeslty, it;s the VISA find resource function which hangs on IO. It's searching for serial port aliases.
I'm sorry I can't attach the VI, like a lot of LabVIEW code the majority of it is proprietary. 😞
I usually don't use the for loop N terminal, that code is part of the LabVIEW Arduino toolkit 🙂