Scrolling of Frontpanel produces high CPU load and crashes COM-communication

[Leffop]

Hello, I am using Labview 2014 32 Bit on a Win 7 machine (8 GB RAM, 6 core AMD).

I have developed a very complex measurement software over the last years with communication with > 15 external devices. Therefore my code is very big (many sub vis, many controls etc). Basically, I use a producer and a consumer loop using Queues. Additionally I have a device loop for time sensitive communication with my LASER

Recently, I noticed that the CPU load increases drastically when using the scroll bars. As a result of this my device loop for my LASER is not running as designed. Unfortunately, my laser needs to receive a command from PC every 500 ms - otherwise it will turn itself off. And this is my problem: When scrolling while the VI is running, the CPU load increases and the loop execution gets delayed to the point that my laser switches itself off and on until stopping the scrolling. I also used time-controlled loop with high priorities without solving my problem.

My question to the community: Is this a common problem for very big GUI - VIs? Is there an easy fix (except hiding the scroll bar)?

 I would appreciate any help I could get.

Best Regards

PS: My wait for event structure has almost 150 cases - could this be a possible reason?

[Norbert_B]

I think your bottleneck is the UI thread. Pllease verify that you run most code in other threads.

I am not sure about VISA in context of serial, but i think it shouldn't execute in the UI thread.

However, if it runs outside the UI thread, your application binds it to it.

In order to solve this, i recommend you to:

1. Move to producer/consumer design pattern rather than a simple event handler

2. Make sure to run as little code as possible in the UI thread

[Ben]

Do you have property nodes in the laser loop?

Ben

[Leffop]

Dear Ben,

not really.

I transmit a cluster of settings and a cluster of readings to my communication vi and receive it back. In the bottom is a case for refilling the Queue.

Maybe I should wait with the refreshing of the clusters on my frontpanel and only refresh it every 1-2 seconds.

best regards

[Leffop]

---

@Norbert_B wrote:

I think your bottleneck is the UI thread. Pllease verify that you run most code in other threads.

I am not sure about VISA in context of serial, but i think it shouldn't execute in the UI thread.

However, if it runs outside the UI thread, your application binds it to it.

In order to solve this, i recommend you to:

1. Move to producer/consumer design pattern rather than a simple event handler

2. Make sure to run as little code as possible in the UI thread

---

Dear Norbert,

actually I don't know about anything of what you just wrote. I never thought about UI threads. I will read up about this topic - maybe I can optimize my code.

to your #1: I have this - I atleast think i do. I have a producer(erzeuger) loop and a consumer loop (Verbraucher). Producer has an event handler. Consumer a case handler.

Best regards

[MarcDub]

I can see in your first laserloop.PNG file one property node (false constant assigned to a boolean beginning by "GasExc").

This might be a possible explanation. Property nodes use the UI thread. If the UI thread is busy with scrolling, the property node execution might be delayed (the UI and property node cannot be accessed at the same time).

For your complex application, you probably have already passed the point where you need to look into design patterns and general good practices (LabVIEW Core 2, 3, Advanced Architectures courses would help).

Just a few quick recommendations:

• Avoid local and global variables, and assigning and reading values using property nodes.
• Breakdown your application in several processes. Each process should have its own loop. Not all loops need to be in a single block diagram. You can use subVIs and/or spawn processes (which can be useful for assigning priorities).
• Make one of these processes your UI process. This loop should only handle UI. If property nodes must be used, that's where they should be.
• Use controls and indicators on your front panel only to receive inputs from the user and to provide information to the user. Use shift registers and queues to distribute those values where they are being used by your processes.
• Communicate between loops using queues and back to the UI loop using User Events.

Good luck

[altenbach]

Some other comments:

• Make sure you don't have overlapping controls on the front panels. This increases the load on resources.
• Avoid controls with tons of data (e.g. graphs with millions of points, charts with large history size, gigantic tables, etc.)
• In your laserloop2.PNG" image, you have an event structure inside a case structure. We cannot see the rest of the code, but can you guarantee that the event structure has a chance to service all generated events?
• Do you really need all these local variables?
• ...