LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI Will Not Abort

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

0 Kudos
Message 1 of 14
(2,851 Views)
Do you have any evemt structures? Go to events handled by this case and deselect defer front panel updates. If this fixes it you have some architectural issues. Can you post the VI?
=====================
LabVIEW 2012


0 Kudos
Message 2 of 14
(2,841 Views)

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

 

--------------------------------------------------------------------------------------------------------------------------
Help the forum when you get help. Click the "Solution?" icon on the reply that answers your
question. Give "Kudos" to replies that help.
--------------------------------------------------------------------------------------------------------------------------
0 Kudos
Message 3 of 14
(2,839 Views)

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?

 

 

Download All
0 Kudos
Message 4 of 14
(2,833 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 5 of 14
(2,822 Views)

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

0 Kudos
Message 6 of 14
(2,818 Views)

@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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 7 of 14
(2,816 Views)

@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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 14
(2,807 Views)

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. 😉

0 Kudos
Message 9 of 14
(2,799 Views)

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 🙂

0 Kudos
Message 10 of 14
(2,770 Views)