Vi stays open after closing the project.

[Braggel]

Hi All,

I think we're on to something here. There is one of the RT branches where I have the actual .vi included in the project (auto populating folder). But it is not repeated in an auto populated folder in the other RT targets that are using the same code base. In these other RT targets, there is only copy of the (same) main startup vi and the other ones are all included through the dependencies. This may be the source of our problems. I always open the vis through the main startup vi and then I "drill down" to the actual vi I want to change.

Unfortunately I didn't have the time to pull all the opened vis list yet. I'll try to do this today still and check where they come from (dependencies from inside the other auto populating folders or from outside). I'll keep you posted.

Kind regards,

Filip.

[JÞB]

Yup.  You need to "Floss" your project.  https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/A-Tidy-Project-is-a-Happy-Project/ba-p/3487453

I highly recommend reading that

[billko]

---

@JÞB wrote:

---

@billko wrote:

I'm quite sure you know this, but just in case, only the VIs belonging to the project will close with the project.

---

File close all this project will close all vis belonging to a project.  But not dependencies. 

Closing a project closes the project. It does not remove any vis from memory or close any open vis.  That is how it works.  

You should not be opening dependancies.  Put them in the project or leave them alone.   Depancies are reuse code that belong elsewhere like vilib or userlib.   

---

Are you sure about that?  I just closed a project (LV 2014) with the [x] button and all the project VIs closed along with it.

[Braggel]

---

@JÞB wrote:

Yup.  You need to "Floss" your project.  https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/A-Tidy-Project-is-a-Happy-Project/ba-p/3487453

I highly recommend reading that

---

I became morbidly afraid of "Flossing" my project since I had a huge corruption (twice) after such a "Floss" action. I was checking and fixing dependencies and moving around some classes physically on the drive for my project to have a more logical structure. While doing this, LabVIEW crashed on me and left me with a crashing/corrupted project. So there was no way to reopen it again, ever... My source control (GIT) genuinely saved my life there. I was hoping that it was a "only this time flaw", but when doing the clean for the second time, I reproduced the crash/corruption. Ever since, I don't want to lose my time anymore in doing this cleaning... As soon as it's clean enough to compile and if it works fine, I leave everything else be...

That was my experience with the "Floss" or cleaning of (another) project. 😮

Greets,

Filip.

[JÞB]

Flossing is easy to screw up.... auto pop folders make it impossible to move classes without breaking stuff.   Lvlibs can really shine in these instances since library members know they belong in a lvlib.  

The lvlib should have it's own Development project complete with the lvlib or lvlibs ( Public APIs, shared friends and private cores) as well as documents like requirements readmes and test reports.  And Unit tests, sandbox code, Soft front panels as needed etc...then drop the lvlib into the main project and leave it alone there.  Even if the API only has shell code!  The main project will gain the abilities as you work on the lvlib in its lvproj. And the main project won't bloat with Development noise.

It sounds an awful lot like you have only 1 lvproj.  Don't be like that! It makes it too easy to cause problems like you caused yourself.  Modularity is always the best practice in Development.   It makes maintenance a whole lot easier and keeps the developer (you) from messing up the whole shebang with a minor mistake in a small section. 

[mbremer]

@Braggel: Were you able to fix the issue.  I'm seeing something very similar ever since I moved to a new computer.  I can open a project, then open a VI in a class, then close the project, and the VI remains open.  Also, if I reopen the project it opens instantly as if it never closed (just closed the window).  Seems like things aren't being removed from memory properly.  This only happens in LabVIEW 2018 for me, and I've only been able to replicate the issue if I have an RT target in the project.

[mbremer · Accepted solution]

I think I found the source of the issue for me.  Seems configuring external timebases for C-series modules is causing the problem.  I've split off into its own thread here: https://forums.ni.com/t5/LabVIEW/LabVIEW-Bug-When-Sharing-Module-Timebases/td-p/3895817

[Braggel]

This was indeed the issue. Thanks a bunch for the suggestion! Unfortunately, I can't remove the export of the timebase... 🙂 So I'll have to live with this issue.

[Oksavik]

Hello, 

I'm also having this issue with LabVIEW 2018 on a new computer.

My project has multiple Targets (cRIO and extensions), and one of them uses FPGA.

I noticed this post on Lava:

https://lavag.org/topic/18446-labview-2014-project-close-not-unloading-project/

which seems relevant, even though that was LabVIEW 2014.

My project was converted from 2016 to 2018.

A different project, with no Targets, also converted from 2016 to 2018 works like it should.