Debugging with Highlight Execution make GUI non-responsive

[dbaechtel]

I am running LabVIEW 2010 on an Intel i5-750 (4-cores) 2.67 GHz system with 4GB of DDR3 dual channel RAM. The system is very fast and very responsive in most applications.

When I run my LabVIEW applications in debug mode without Execution Highlighting, the system runs very well with less than 5% CPU usage. When I run LabVIEW applications with Execution Highlighting, the GUI gets very sluggish and non-responsive. It won't respond to any mouse inputs for almost a minute. I can not move screens around quickly so that I can see what is going on. The scroll bars on the LabVIEW Windows will not move. The Windows Task Manager still shows the system CPU usage at less than 5%. Sometimes the Windows Title bars in LabVIEW show "not responding". The rest of the non-LabVIEW windows and application are running fine and are very responsive even with LabVIEW running with highlighting.

How can I get LabVIEW environment to be responsive to my commands when running with Execution Highlighting?

If the CPU usage is very low, what is making the LabVIEW environment sluggush and non-responsive when running with Execution Highlighting?

How can I debug my application with Highlighting when I can neither see what is happening or provide inputs in a timely manner?

What can be done to improve this?

[tinnitus]

Hello,

it is normal that GUI is very slow in highlighting mode because it a way to see all operations

at same time for a human being so pc run as quick as eyes can run (more or less).

To debug highlighting is not the only way i d'ont know is i ever use it, may be at beginning.

You can place probe in your code to see data evolution, you can also place debug point ...

A way i also use is creating an FGV that store values i want to monitor and send it to graphic loop.

Regards

Tinnitus

[blawson]

This happens to me sometimes when I'm using highlight execution, also.

I usually chalk it up to the fact that its tracing code through event structures where the case that is executing is set to "lock front panel until completion" which is generally the default. Basically it's doing exactly what it should do if the code in the event structure were to take a (very very) long time.  It is pretty annoying that you can't do stuff like turn off highlight execution when it's in the middle of this.

On the other hand, this demonstrates why it's a good idea to make sure that code inside event cases runs in as short a time as possible, sending the work out in a producer-consumer type of architecture when necessary.

In order to confirm that this is what's happening, make sure you can see the block diagram of some GUI code with case structures before you get running.

[dbaechtel]

Highlighting Execution does not HAVE TO make the rest of the LabVIEW GUI slow and non-responsive. Why should the menus and scrolling and other Windows functions be slowed way down just because Execution is being Highlighted? These should be separate functions and one should have very little effect on the other. I am just saying that I can not use Exection Highlighting effectively if the rest of my Windows functions aren't responding.

I also use probes for debugging, but sometimes Execution Highlighting would be more effective, if it didn't make the Windows non-responsive.

I am looking for a workaround to fix this issues. Obviously getting a bigger, faster CPU or RAM is not the solution. What else can be done to make LabVIEW Windows responsive while Execution Highlighting is active?

[tinnitus]

hello,

more power full pc will not change

as mentionned

Are you using  producer- consumer design   to separate event loop from code itself ?

if is the case have you notice this kind of thing with previous release of LV ?

regards

[tinnitus]

do you have a little example of code that reveal this probleme ?

[dbaechtel]

I am using Producer/Consumer and Sate Machine models.

My code runs very fast when execution highlighting is turned off. Profiling says almost all VIs are running in 0 milliseconds.

I do not think that this problem is because of my code design.

[blawson]

---

@dbaechtel wrote:

Highlighting Execution does not HAVE TO make the rest of the LabVIEW GUI slow and non-responsive. Why should the menus and scrolling and other Windows functions be slowed way down just because Execution is being Highlighted? These should be separate functions and one should have very little effect on the other.

---

If the cause is what I mentioned above (highlight execution is running in event cases that have "lock FP until completion" checked, which is the default) then different GUI functions are NOT separate in fact, that option does not allow any other LV-handled GUI actions to execute until the current case is done.  Scrolling and menus are both locked if this is checked (which makes sense, as these are events that you can filter off of).

You could test this by unchecking lock until completion on some events.  You could also test this by making sure that you can see code that is executing in highlight execution mode: be sure that the FP is open and visible before the code runs, hit Ctrl-E if you can't see it while it's running.

[dbaechtel]

---

@blawson wrote:

If the cause is what I mentioned above (highlight execution is running in event cases that have "lock FP until completion" checked, which is the default) then different GUI functions are NOT separate in fact, that option does not allow any other LV-handled GUI actions to execute until the current case is done.  Scrolling and menus are both locked if this is checked (which makes sense, as these are events that you can filter off of).

You could test this by unchecking lock until completion on some events.  You could also test this by making sure that you can see code that is executing in highlight execution mode: be sure that the FP is open and visible before the code runs, hit Ctrl-E if you can't see it while it's running.

---

THANKS.

Where cn I find this " lock until completion" option?

[smercurio_fc]

---

@dbaechtel wrote:

Highlighting Execution does not HAVE TO make the rest of the LabVIEW GUI slow and non-responsive. Why should the menus and scrolling and other Windows functions be slowed way down just because Execution is being Highlighted? These should be separate functions and one should have very little effect on the other. I am just saying that I can not use Exection Highlighting effectively if the rest of my Windows functions aren't responding.

---

Because the stuff has to be drawn on the screen and it's not instantaneous.

---

@dbaechtel wrote:

Where cn I find this " lock until completion" option?

---

This is documented in the LabVIEW Help on event structures. Did you check?

Regardless, the "lock until completion" will NOT solve your problem, as it has nothing to do with it. The issue you have is a fundamental drawing issue, not that the front panel is locked when a specific event case is being executed. That option simply allows the event structure to queue up events if it's inside one of the cases running some VI that's taking a long time. It doesn't matter whether highligh execution is on or off. You would see the same exact issue if all you had is a large diagram with just a while loop. With execution highlighting LabVIEW has to draw the little bubble to travel down the wire. I do not believe that LabVIEW uses any kind of graphics acceleration when doing this, so this is fundamentally an issue with how powerful your 2D graphics drawing capabilities are.