labview lags while programming when finnaly totally freezes

[Jorick]

I have a problem with Labview, this only happens in the program I currently working on.

The problem that I have is that when I’m programming Labview starts to lag after a random time working just fine. In the attached video I’ve been working for about 6 minutes before it started to happen, I’ve cut the video when it started to happen to reduce the size of the file.

If you watch the complete video you will see that it's getting worse but this time Labview didn't completely freeze.  (When Labview started to lag while I was making the video I just started doing some random stuff)

I've also made an executable and it seems as it also tents to do the same thing while running the .exe but I don't know for sure jet. It could also be a mistake I’ve made in the program itself.

I really hope you can give me a solution for this problem because programming this program is a hellish job right now....

The screencapture video:

http://www.youtube.com/watch?v=3StKujH_o4U

Sorry for the bad quality of the video but I think the problem I have can be seen quite good.

[Jorick]

Here is an additional video I've made of the problem I have with labview

http://www.youtube.com/watch?v=ZT46955dXHc

[mikeporter]

What version of LV? What OS? What is cpu and memory utilization doing while this is going on?

Mike...

[Jorick]

Labview 2011

Windows 7 x64

Intel® Xeon® Processor E5-1603 (Quad Core, 2.80GHz, 10MB)

4GB DDR3 SDRAM 1333MHz

When the problem starts it will hold the CPU at 25% usage, but when it's running like it supposed to do the CPU usage will be about 5%

I've opened the program on several different computers and not on every computer and not everytime the problem will show, it's completely random.

I've also tried to remove a large number of controls used in the program and it seems like it starts to work better after doing that, but I really do need all the controls. and I really don't think I've reached a limit of controls that may be used, if there is a limit build in labview, which I doubt but I don't really know.

I've said in a previous post that the executable seems to have the same problem, but that isn't the case anymore, that was a programming error. (the problem still exist while I'm programming with labview).

[altenbach]

LabVIEW 2012 has a compiler opimization setting that allows setting a tradeoff between compiler optimization and editor responsiveness. I guess NI felt there was a need to be able to increase responsiveness under certain scenarios. LabVIEW 2012 also has an indicator for code complexity on the "vi properties...memory" page. I would be curious what the complexity of your VI is if opened in LabVIEW 2012. Would you mind attaching it?

Why do you have such a fine grid on the diagram? I guess this also needs more effort to be redrawn.

Do you have many overlapping objects on the front panel?

Does the situation improve if you force a recompile with ctrl+Run (hold the ctrl key and press the run arrow)?

[mikeporter]

Christian makes some excellent points. Is this 32 bit LV or 64 bit LV? I ran 32 bit LV of a 64 bit Win7 machine and while I saw it do a lot of strange things, this is not one that I noticed.

When it is lagging, is the hard drive running a lot? What happens if you let the lagging system sit without touching it for a half hour or so, does it get better? Just to be clear, you are seeing this problem on multiple computers and the only thing in common between them all is that they are all editing your code.

I don't obviously don't know what your code is trying to do, but from what I can see in your video it seems very complex. How many subVIs are there in your application? How many are being called directly by this top-level VI?

Again, from what I can see, I looks like you are using a tab control, yes? If so, that could be a problem. Tabs have a long history of causing problems, and especially with graphs, which is which is why I very rarely ever use them. A better solution for a main program interface is to use subpanels. They simplify your code and can provide better modularity..

Mike...

[altenbach]

---

@mikeporter wrote:
How many are being called directly by this top-level VI?

---

More importantly, how many are inlined?

[Jorick]

Thanks for your reactions, I have attached my program to this post (in a .zip file)

The version of the labview I'm using is a 32Bit version.

To answer a few of your questions:

altenbach : Why do you have such a fine grid on the diagram?        

I don't really know why the grid is on but I've never had any problems with it, and the lagging also occurs on PC's where labview is installed and which doesn't show a grid in the blockdiagram.

altenbach : Do you have many overlapping objects on the front panel?  

The only overlapping objects I have on the frontpanel are in different tabs , I've got 5 tabs, 2 with graphs, 2 with quite a load of controls (by fare the most I've ever used in a program, and hopefully the most I will every use.....)    and one tab with a illustration and some textboxes etc. But not an absurd amount.

altenbach : Does the situation improve if you force a recompile with ctrl+Run (hold the ctrl key and press the run arrow)?   

No it doesn't. When I simulate the program while labview lags it will also lag in the simulation, but it doesn't lag when using a executable of the program.

mikeporter :

When it is lagging, is the hard drive running a lot? What happens if you let the lagging system sit without touching it for a half hour or so, does it get better? Just to be clear, you are seeing this problem on multiple computers and the only thing in common between them all is that they are all editing your code.

First of all, the hard drive isn't running a lot for as far as I've noticed but when I do sit without touching the program for about 15 minutes (that is the longest I've waited), it will work fine for about lets say 3 minutes and the whole thing starts again with lagging...

The only thing that the computers have in common where I've tested the program on, is that almost all have the same labview versions, three of them don't and still show the same problem. The problem only occurs when I'm programming, so I'm changing the frontpanel or the blockdiagram, it doesn't matter labview will start to lag after a couple of minutes (sometimes after 5 or 15 or even 20 minutes but it will start lagging).

mikeporter :

I don't obviously don't know what your code is trying to do, but from what I can see in your video it seems very complex. How many subVIs are there in your application? How many are being called directly by this top-level VI?

This question is best answered if you look at my program as it is right now (see attachment)  this is the way I've learned how to program with labview from one of my former teachers and I've used that since and never had any problem with it until now.

mikeporter :

Again, from what I can see, I looks like you are using a tab control, yes? If so, that could be a problem. Tabs have a long history of causing problems, and especially with graphs, which is which is why I very rarely ever use them. A better solution for a main program interface is to use subpanels. They simplify your code and can provide better modularity..

If you have a good example of how to use a subpanel in a program like mine than I would really want to see that, I'm not familiar with the usage of subpanels and the times that I've used them it didn't really help with programming but maybe I've been using it wrong. So an example would be nice.

[Jorick]

O and one other thing, I've never seen the problem occour in the executable, the one time that I've seen that, it was a programming error I had made.

and the program uses an Agilent U2351A  so maybe you will have to download the drivers for it to see the program in it's complete 'semi-working' form.

[johnsold]

Greedy loop!

Your while loop has no Waits or other mechanism to slow it down.  It runs several hundred thousand iterations per second. That is completely meaningless for a loop which appears to be intended to display things to human users.

Put an indicator on the "i" terminal in the loop and run it.

Put a Wait (ms) function in the loop. Set the value to something which is reasonable for your application.  If this is for human interaction, 100 to 200 ms is reasonable.  Even a 1 ms wait reduces the CPU load from all of one core to a small percentage.

Lynn