LV 2021 vs. newer, VI management in memory

[MaSta]

---

@Kyle97330 wrote:

What you're describing sounds a little bit like what would happen if you had LabVIEW open, with a VI and subVIs loaded, and then you somehow replaced one of the subVIs on disk (like, if you downloaded a new version of it from source control), and then LabVIEW noticed that the version it has in memory no longer matches the version on disk.  So it's almost like you're loading different instances of LabVIEW at the same time for each VI somehow instead of just having one instance open.

---

Yes, exactly that is what I described and what happens. But I don't replace the files, I just open, modify and save. And yes, an earlier loaded copy loaded by the main VI is most likely in the memory. That's exactly the point. Instead of LabVIEW asking me to load or reload the modified version of the VI and replace it in the memory, I'm only given the option to (german) "Wiederherstellen", which means to restore. It's a small pop-up with two buttons. 

[MaSta]

---

@GerdW wrote:

What about dependencies management? Has nothing to do with this problem

What about handling shared variables? No shared variables used.

What about handling targets? No targets used.

What about handling project symbols? -> ???

What about handling code separation to ease SCC usage? -> ???

[BertMcMahan]

---

@MaSta wrote:

---

---

I came from LV 7 and never learned the purpose or benefit of these project files, except for compilation. Currently, I have 83 sub and 1 main VI, plus many from installed LVLIB. The main VI is added to the project, the dependencies show all the subs. Looks organized.

---

There are many benefits to the project file, but one of the main ones is precisely this purpose. A project instance is how LabVIEW manages all of the connections between VI's in memory. No, you don't have to have one to code, but if you don't have one then LabVIEW doesn't have a way to manage what VI's are in memory or not, what's loaded or not, etc.

The other things GerdW listed are other benefits to the project file, not solutions to your problem. You might not need all of those things but like it or not, LabVIEW as an IDE uses a Project file to handle all of your different files and dependencies.

You can code in C using Notepad then compile from the command line. It will work, but will be a giant pain in the butt. Using some sort of IDE (even a simple one) will help dramatically with anything larger than a very small programming task.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

---

@GerdW wrote:

What about dependencies management? Has nothing ALL to do with this problem

You asked for "benefits of using projects within LabVIEW" and I named some of those benefits!

Btw. the first item, of which you think it "has nothing to do with this problem" is the exact reason why you should use a project file (as others already explained, too) to solve the problems you described in your first message!

It is the MISSING dependency management why LabVIEW asks you about "changed" subVIs again and again!

[Bob_Schor]

I just tried to cause exactly the same problem that MaSta described.  I've been using Projects since they were developed.  To help me keep my Projects organized, both in the Project File and on disk, my "virtual" Project Folders exactly mimic my disk Project Folders (and sub-Folders, sometimes several layers deep, as I isolate sub-VIs from TypeDefs, and may have a section for Data Acquisition and Data Analysis).

I've never seen the type of problem that MaSta describes, but I thought my "timing" might be a little different.  I opened a Top-Level VI, opened a sub-VI that it called, modified the sub-VI, closed and saved the sub-VI, and when I opened it from the Top-Level VI, I saw the modified version.

I then tried it again, modifying the sub-VI, but not saving it (but leaving it in memory).  I could close the Main VI, which didn't ask about saving anything, and when I opened it again, it showed me the modified (but not-yet-saved) sub-VI.  As near as I can tell, this is exactly the pattern I've been seeing since the Project (and its files) were introduced.   

I have not installed LabVIEW 2022 or 2023, so can't comment on whether this situation that is affected MaSta is present on these systems.  Maybe MaSta should create a small "Demonstration Project" that shows this behavior and post it so we could try to help.

Bob Schor

[UliB]

---

@Kyle97330 wrote:

What you're describing sounds a little bit like what would happen if you had LabVIEW open, with a VI and subVIs loaded, and then you somehow replaced one of the subVIs on disk (like, if you downloaded a new version of it from source control), and then LabVIEW noticed that the version it has in memory no longer matches the version on disk.  

---

A few years ago I faced a similar problem, but I can't remember all the details.

I was working on a network drive at the time. Every time I saved a VI, an operating system process accessed the VI and added 2 seconds to the file time. So LabVIEW was complaining about the VI being changed outside of LabVIEW. I remember being able to see the change in File Explorer and prove the file change with file monitoring software, but never found the guilty server process.

I started working on the local drive and never had this problem again.

[wiebe@CARYA]

---

@MaSta wrote:

Hello!

The latest LV version we have in use in our company is 2021. Considering to update (need to renew our maintenance contract first) I would like to know one thing. Particular version 2021 has this, as I didn't experience it with version 2015 or older and didn't use the versions in between 2015 and 2021: I call it "annoyingly bad internal VI memory management".

What I mean: you load some VI with sub VIs. Then you open any of the sub VIs, modify and save. Switching back to the higher level VI you would expect LabVIEW to automatically load the modified sub VI though it has the old version in memory. LabVIEW does notice that the sub VI has changed and comes with a pop-up that asks to "Restore" the VI (whatever that means) or to "Cancel". What I would expect is an option to "Reload". If the concerned sub VI is used, let's say, 8 times in other sub VIs, this pop-up would up come 8 times. "Restore" is, of course, no option, because I want the higher level VI to use the modified version. The only way to get rid of the over and over popping up requesters is to close all VIs and to open the main/higher VI again. This is extremely annoying and cannot be the solution. Like I said, this hasn't been there before.

Is this solved in a higher LabVIEW version, like 2022 or 2023? 

---

It make a difference if the 'higher level VI' is in memory when the subVIs change. If the higher level VI is in a class, it is loaded when the project loads. If it's not in a class, it needs to be opened or in a sub VI of a loaded VI to be in memory. If it's not in memory, it won't do modifications until it is in memory.

It also depends on the changes made to the sub VI. Only if the feed through status of input\outputs change or if the connector pane changed (,maybe reentrancy or other VI properties), the callers need to be updated. If the calling VI doesn't store compiled code, this is even less often.

So the compiled code option will make a big difference too. Maybe the defaults are different between versions?

When this is all kept consistent, I never noticed any difference between LabVIEW versions since 8...

[MaSta]

---

@GerdW wrote:

You asked for "benefits of using projects within LabVIEW" and I named some of those benefits!

Btw. the first item, of which you think it "has nothing to do with this problem" is the exact reason why you should use a project file (as others already explained, too) to solve the problems you described in your first message!

It is the MISSING dependency management why LabVIEW asks you about "changed" subVIs again and again!

---

I didn't ask, but you came up with this project topic which might be the solution. I still don't see how and, most of all, why I would need to manage dependencies and not LabVIEW. I mean, I didn't change a name or the dependency itself. The sub VI is just changed in its code, so no dependency hurt.  

What's also not clear: can LabVIEW manage dependencies itself completely, partially or not at all? If it does, no matter how, do I just have to the have the project file open? 

[wiebe@CARYA]

---

@MaSta wrote:

---

@GerdW wrote:

You asked for "benefits of using projects within LabVIEW" and I named some of those benefits!

Btw. the first item, of which you think it "has nothing to do with this problem" is the exact reason why you should use a project file (as others already explained, too) to solve the problems you described in your first message!

It is the MISSING dependency management why LabVIEW asks you about "changed" subVIs again and again!

---

I didn't ask, but you came up with this topic which might be the solution. I still don't see how and, most of all, why I would need to manage dependencies and not LabVIEW. I mean, I don't change a name or the dependency itself. The sub VI is just changed in its code, so no dependency hurt.  

---

If the VI changes the way it needs to be called (reentrancy, connector pane change, feed through changed) the caller needs to be updated.

So, dependency hurt...

If the caller has separate compiled code on, it's less likely the VI needs to be changed (the compiled code is changed automatically).

[MaSta]

In this case the sub VI is greyed out, you instantly see, you reconnect and done. This pop-up hell is a different story.