lag while programming LabVIEW 2012

[PeterB16]

After reading a few different posts about lag, I havent found an answer for my question.

I am currently running LV 2012.

Windows 7, 64bit

16gb ram

Intel chip

I get extreme lag while programming and occasional lag while running the VI.

The programming lag gets so bad at times that it will freeze after every single movement of either an item on the front panel or the block diagram. 

While checking the memory usage under VI Properties, I have seen the memory total as high as 105634.5k.  Compiled Code Complexity is 6.1.  I have been running the compiler slider on 5.

Normally, while programming it will reach @65000.0k.  It freezes frequently (not responding).

I am using Tab Control. I have 12 tabs, 6 of which have 2 graphs each.  The other 6 tabs are control and monitor pages.

I am not sure where to begin looking.  I don’t know what questions to ask?  All I know is that it lags greatly.

Thank you

Very frustrated

Pete

[crossrulz]

Your problem simply comes down to the fact that you have a way too large of a VI.  Your diagram is HUGE.  You really need to work on breaking that code up into subVIs.

And so many local variables.  Those are just asking for race conditions.  Not to mention that each one is a data copy.  Reducing those will reduce your memory usage and block diagram memory usage.

[0utlaw]

Hello PeterB16,

The issue is LabVIEW's undo buffer requirements.  When you have a large VI open in the IDE and you make multiple changes, recall that those changes are being cached in memory as you go. Depending on the changes made, you may be juggling as many as 100 "live" copies of the (already large) VI in memory. Are you by any chance running this VI between edits?  If you are, any data cached in the front panel (read- chart data) will also go into the undo history buffer. If you have local variables that also hold that data, you have even more copies and more memory to keep track of.

In my experience, you'll see the biggest slowdown when reaching the undo history buffer limit (99, by default) reducing the buffer size and/or clearing the history periodically

are my suggestions.

Regards,  

[PeterB16]

I will work on creating some SubVIs.  I dont know where to begin.  Its overwhelming enough as it is.

Thank you.

[PeterB16]

I am running the VIs between some changes.  There are times I make quite a lot of changes between saves and runs.  Lately however, as soon as I make one change, the VI goes unresponsive.  I have reduced the undo memory from 99 to 50. 

[camerond]

---

@PeterB16 wrote:

I will work on creating some SubVIs.  I dont know where to begin.  Its overwhelming enough as it is.

Thank you.

---

I would begin by looking at the program functionally (setting parameters, manipulating machine controls, reading data, calculating physical results, drawing graphs, saving data to files, etc.). Use a different state in a state machine to run each of the functions when needed without having to activate the rest of them. Each state could just open one subVI (and the subVIs can also contain subVIs themselves, with branching or not, as needed). The subVI activated can then be set to open its front panel when called, and revert to the main program's front panel when dismissed. Your data, constants, file paths, etc. can be bundled into arrays so there are just a few inputs and outputs to each subVI - LV allows a maximum of 28 inputs and outputs (8 on each side of the square), but in my experience (although many here have much more experience) you can almost always get by with 16 (5 on each side) or less by using reasonably thought-out arrays for your connections.

Using a state machine with subVIs also lets you eliminate a lot (maybe all) of your local variables (They look like even in your VI at least some of them could be replaced with wires, if so, they are there just so the whole program isn't completely covered with wires). It has another major advantage that you can fix portions of your code separately, and they stay fixed unless you change the whole architecture of your program - even then, often you just have to make a few changes.

Using arrays for similarly-functional objects also lets you take advantage of autoindexing and pulling out whole subsets of arrays to work on instead of having to run a wire for each and every one. Your main BD may still resemble a railyard, but it won't be Grand Central Station, anyway, and everything will go a lot smoother and faster.

Cameron