Labview slows down by pictures in frontpanel

[Patrick Kerstholt]

Hello

I programmed a Labview application but after adding some pictures the program slows down terribly,

When adding a delaytimer to the loop so it loops every 100ms the loop will slow down to only one cycle every 2 a 3 seconds.

Without the delay the cycle time is also reduced from 100 loops a second to 1 loop every second.

When I remove the pictures and the background the problem is gone!

It also only appears when moving the mouse. When the mouse is unused the speed is increasing but still doesnt run at the expected speed.

What is causing the problem? The images are not hugh, and are imported to clipboard in labview, the original file type is .PNG.

Can anyone help me solving this problem? Is there are work around to keep a nice layout but the speed is normal again?

Thanks in advantage!

[Pete.Dunc]

Hi Patrick,

The issue comes as LabVIEW redraws the entire front panel when you mouse over it.  If we think about the amount of data being processed this can account to several 100 MB/s (for a 2MP, colour image) - this causes the the front panel update rate to drop substantially.

Can you attach your code?  I am interested in why a delay of 100 ms would cause your look to slow down so greatly.

There is a work-around for this, that being to programmatically defer front panel updates.  However, we should take a look at the existing program before approaching this technique.

[Patrick Kerstholt]

Hello

The code is for a project wherefrom I unfortunally can not provide the source.

It is used for distribution testing purposals in a enrichment centrifuge so this is really impossible.

The images are only 70kb, and there are only 5 different pictures that are used multiple times.

Can i compress them?

Thanks in advantage

[EvenDeejay]

What about using parallell loops and just update the frontpanel in one loop while the other loops do all the math, DAQ, etc. You would need ques for this. It should help since the updating happends in a independent loop.

[Patrick Kerstholt]

I don't really understand. Can you provide an example?

Thanks in advantage

[Coq_Rouge]

Have you worked with Labview for a long time? For a beginner in Labview. It is very easy to make code that may work but, are very very inefficient. In such code it is often enough to change minor things before the code start to react slow.  Code like is often recognized by local/global galore and abuse. Using EXpress VIs and the  dynamic datatype may slow things down. Also placing graphics or control/indicators on top of each other. May force the front panel to be updated more often. Another things that slow things down are graph or chart that contain a lot of data. In such cases it will often help both speed and readability to present a downsampled version of the information.  

[EvenDeejay]

Open example finder in LV and search for Queue Basics.vi. I guess you got only a single loop? Like a big while loop with all the code inside? If you do so there can be a problem with timing if you got the frontpanel update within the same loop.

This structure is called producer/consumer. It got two or more loops that runs in parallell and they can run at different speeds. You time critcal stuff can run in one loop, and then you just update the frontpanel i.e. every 200ms with the other loop. 

[Patrick Kerstholt]

Now I understand,

I already do that but because the VI should work realtime the frontpanel will have got a time lack of almost 2 seconds.

There must be something to fix this problem because the images are not big. The largest image I use is only 30kb!

[EvenDeejay]

Could you reproduce this in an example and maybe post that? I often use pictures and I haven't had this type of problem before.Are there any controls/indicators over the image? You see, the image will update if there are i.e. an indicator over it that updates. It seems that you images tries to update every time the loop inerates.

[Matthew_Kelton]

Don't confuse the file size with the memory size.  If you are using a compressed file format, 30kb is not the amount of memory needed to open the picture.

Also, the problem is not necessarily the size of the image, but rather the fact that LabVIEW has to redraw it.  It has been several years since I did the testing, but I found that a better graphics card was more important than a better processor when it came to LabVIEW.  We were seeing some extremely slow test times when we switched to a PXI controller (this was the first generation PXI controller).  I used a MXI card and a significantly slower machine and ran the test on the order of 2 times faster (3 minutes to 1.5 minutes approximately).  It came down to the graphics chip the controller was using was fairly entry level, which my PC has a dedicated, mid-range graphics card.

One of the issues in my case was decorations.  I had several stacked decorations underneath indicators.  NI explained to me that LabVIEW isn't smart enough to realize it only has to redraw the top layer, it redraws everything from the bottom up.  I don't know that is still the case, but I would be surprised if it isn not.

So, if you are using a low-end graphics card or one built in to a motherboard, you could improve performance by getting a better graphics card.

Without the pictures, how much CPU does your program use?