LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Takes too much time during editing labVIEW VI code

Hi There,

I am facing LV vi slowness issue on labview 2016 version software. I have a powerful PC with i7 processor and 8 GB RAM.
I have created a labview project in which there are one main vi and more than 100 subVIs.

Whenever I edit the VI or do anything on FP or Block diagram , its takes too much time to responce.
Most of the time its takes more than 30 minute to responce. Many time VI get crash and don't respond and I had to do end task via task manager.

This issue I don't face when I open separate new VI. I am unable to find the exact problem of this issue.My executable work fine without any lag. Its looks like LabVIEW issue.

Some day it works fine and don't take much time to respond.

 

How can I resolve this issue? Anyone have any idea?

0 Kudos
Message 1 of 18
(2,796 Views)

Several times I met a similar problem.
Check if your diagramm is too big / complex in any VI.
If there are suspicions, make subVI from code sections and check if the problem persists.
When I say "big diagram", I mean not a complex program, but something like a spaghetti-diagramm.

0 Kudos
Message 2 of 18
(2,776 Views)

There is no any big code in block diagram. All I have made subVI and used wherever required. 

0 Kudos
Message 3 of 18
(2,770 Views)

That's happened to me several times. Switch Project view to File view or even better, Close the Project and work in the VI directly.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 18
(2,767 Views)

Do you have lots of circular dependencies in your code?

0 Kudos
Message 5 of 18
(2,750 Views)

Same issue with working in VI directly without project file open.

0 Kudos
Message 6 of 18
(2,738 Views)

A new vi, or a vi from the project? If it's a vi from the project, it could still be circular dependencies. Are you using lots of classes, libraries, or typedefs? Or, do you have a large set of data stored in any vis? 

 

If you use the project template and create a new, say producer consumer template project, do you still see the issue?

0 Kudos
Message 7 of 18
(2,734 Views)

That has not been my experience, especially with LabVIEW 2016.  I'm currently working on a Project that has 162 VIs and TypeDefs when the Top-Level VI is in memory, and the entire Project (with Test routines, Support code, etc., all of which can be loaded into memory during Development) has about twice that number.  It loads speedily, responds quickly during editing.

 

I apply a principle I learned from Peter Blume's The LabVIEW Style Book that all of my VI Block Diagrams (and Front Panels) fit on a laptop screen (in my case, 1920 x 1080).  Most are considerably smaller than that.

 

Bob Schor

0 Kudos
Message 8 of 18
(2,724 Views)

I've had large VIs become slow to respond to edits in the past.  This was mostly due to a large number of cases in case select structures, combined with the use of the State Diagram Toolkit.

 

In versions of LabVIEW above 8.6, edit time compilation took a few minutes for every change in the diagram. 

 

There are a few things you could try to improve your VI.

 

Choosing between Editor Responsiveness and VI Execution Speed

 

You can make changes in the Environment options that might improve editing. 

 

Another thing to try might be to copy and paste the code into a new VI. 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 9 of 18
(2,710 Views)

Did you adjust the "compiler optimization" for the VI?  Are the wires a complete mess?  Are you using inlined VIs?  Are you OOP heavy?  These are the things I have heard of people having issues with due to compiler bugs.  Of the ones I am aware of, I think they were all fixed in a patch.  So do make sure you have the latest 2016 patch.

 

Also, if you are using the "Separate From Compiled" on your VI, you might want to try to clear the object cache (Tools->Advanced->Clear Object Cache).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 18
(2,706 Views)