LabVIEW Developers Feature Brainstorming

[johnsold]

James,

I have been doing some cross-platform development, developing on a Mac for deployment on Windows. I copied the DAQmx VIs from the Windows machine to user.lib on my Mac. I did not put them in vi.lib because I did not want an upgrade to LV to wipe them out.

So, every time I move the program from one platform to the other and open a VI which uses DAQ I get about 800 warnings that all the DAQmx VIs were not found in the usual vi.lib place. This makes it very hard to sort out the four or five VIs which may have linked to an obsolete version or had some other problem that I really wanted to know about.

(Of course DAQmx for the Mac would fix that particular problem, but that is outside the scope of your query.)

Lynn

[JLoftus]

Thanks again, Lynn -- that's exactly what I wanted to know.

[tst]

---

tst wrote:

If you want something faster than that, how about writing a simple VI which will go into the tools menu and just return a popup with the version of the VI it's called from?

---

Another option (which is probably what Dataact's LabVIEW version chooser does) - write an application which will register the VI extensions - when it is called, it will open the VI in the current working LV version through VI server and throw a popup if it was saved in an earlier version. Personally, I probably couldn't stand it.

[jccorreu1]

Often times I'm working with various copies and backups of my projects in different directories.  Many times when I load from a particular directory it will automatically pull files from one of my other versions.  Even when that particular file exists in the location I am opening, and I've just opened Labview so there are no subvi's in memory.

Manually relinking becomes a pain.  I'd like the option of which of the 2 versions/places that labview will load, instead of it just telling me that its loading the wrong one.

thanks
James

[tst]

LabVIEW maintains the position of a subVI as a relative path to the VI calling it. If you are moving your VIs manually instead of doing a Save As, there are two options:

1. LabVIEW can't find the file where it expects to find it. It then begins searching through several locations until it finds the file it's looking for.
2. The relative path is the same, but is the version you don't want.

Another option is that while you don't have that subVI in memory now, you did have it at a previous time and the wrong subVI got linked to the calling VI. When you saved it, it remembered the wrong VI (as it should).

What you might want to do is one of two things -

1. If you want to keep working with your current scheme, you will need to make sure that you don't work from the backup folders. If you want to check the backups, you should make sure to close and open everything each time to avoid cross linking.
2. Use source code control. It's designed specifically to backup versions of code over time and to allow you to return to previous versions if necessary. We use Subversion with TortoiseSVN as a client, both of which are free and open source. So far, its biggest advantage was that it makes it considerably easier to synchronize code on different computers, as long as the users have some discipline, but it also allowed us to return to some old code when someone messed up. It doesn't integrate into LV (not natively, anyway), but we just use it on the files and it works great. Getting the updated version of a folder requires two mouse clicks in Explorer.

[jccorreu1]

In most cases I absolutely agree with you.  In fact I have been thinking about using somekind of code checkout system, just havn't wanted to get into it yet. 
Because of this I have been careful about what I have in memory(though can't say I have always caught all of it).  But this time I think it may be a little different,

here's what I did...
Labview is closed.  I have a directory containing my vi's.  I make a copy of it.  I then open the top most vi from that new copy directory.  I expect that Labview will look in all the sub directories of this new copy directory.  And for the majority of the vi's it does exactly that.  But for a few cases it tries to pull them from the original directory, even though the files exist (are in fact exact duplicates) in the new directory.

It seems odd to me that things should work this way.

And am I the only one who thinks it might be useful sometimes to over-ride what Labview is automatically trying to load?

[TCPlomp]

In the LabVIEW 8.5 project environment you have quite some posibilities to do (semi)automatically relinking. I think it's one of the key improvements for 8.5 for code-management.

Ton

[tst]

jccorreu1 wrote:
In most cases I absolutely agree with you.  In fact I have been thinking about using somekind of code checkout system, just havn't wanted to get into it yet. 

Taking the first step is difficult indeed (you have to read up and be aware of all kinds of new stuff), but for us it was worth it, if only because of the need to sync the code between different computers. Around the time we did the transition, we had all kinds of cross linking issues, mostly because there were utility VIs which were saved with each project on the different computers. I spent a couple of days writing, running and verifying the results of a small program which allowed me to resolve that - essentially, it created a copy of the hierarchy and renamed all the VIs as it did so to have a single name-space. It prompted for a namespace and for which will folders will have their files copied. After I ran it, I ended up with duplicate VIs, but they were all namespaced, so that was OK. Everything worked after some cleanup and testing (e.g. for VI names embedded in the code which needed to be changed) and it was worth it for us. The relinking options Ton mentioned might help as well.

here's what I did...
Labview is closed.  I have a directory containing my vi's.  I make a copy of it.  I then open the top most vi from that new copy directory.  I expect that Labview will look in all the sub directories of this new copy directory.  And for the majority of the vi's it does exactly that.  But for a few cases it tries to pull them from the original directory, even though the files exist (are in fact exact duplicates) in the new directory.

---

Here's one example of how this can go wrong. You have c:\1\main.vi which calls c:\2\A.vi which calls c:\1\B.vi. You then create a copy of c:\1. When you open c:\copy of 1\main.vi it goes one folder up and then into the folder called 2 to load A.vi (it looks like this ..\2\.A.vi). A.vi wasn't changed, so it still correctly calls c:\1\B.vi, even though you created a copy of c:\1. Another option is that the VI is called from more than one place and the second place still calls the original VI.

And am I the only one who thinks it might be useful sometimes to over-ride what Labview is automatically trying to load?

---

There already is. If you open the subVI from the copied folder and then the main VI, it will be the one which is used. I wouldn't want this to happen when loading the VI, because I can't think of a reasonable interface for doing this for hundreds of subVIs (which my projects often have).

[jccorreu1]

As I am still with 7.1.1 I'll not have the benefits of the changes to 8+... though anything done to the load warnings won't affect me either... I may eventaully get to using 8+, but many clients will still be using 7.1 anyway.
Yes I can see what you mean with the calling chains.
And while I've been working alone most of the time, there have started to be other people involved (on a very minimal and irregular basis) and I'm working on a good way for deployment (currently just using straight FTP), so I know I'll have to take the plunge soon anyway.
I like the idea for using namespaces, I did it with C++, never thought of it for labview.

I do also have around 500-600 vi's in this project, and I expect most of mine will be (is this considered large by most people?) 

But when the warnings come up on load I do actually look through the entire thing.  I scan it and have gotten used to the format so can easily pick out what I'm looking at, and usually have some idea of what is expected or out of place.  And it's usually only a relavtively small subset of the total number of vi's in the project, they just get listed over and over for every place they are found.

So there brings an idea....  make an entry for the vi that is changed, and a list of all the places, so as to avoid the clutter of the redundancy.

As for how to decied upon which version to load, with that single entry of that altered vi, have next to or below it a button or box that toggles which to load.  And have each entry individually marked as such.  (Besides I do not always remember the names of all of them I have to change so I wind up going back in and launching it again to get my list, yeah I could write it down but..)

As far as I can imagine currently, the question of version loading review will always require manual perusal, and action that requires a directed human touch, and time.  We can make the manner in which the data is displayed a little more arganized and easier to look over, and we can add some functionality right there that we otherwise will have to go through a more lengthy process.

james

[Albert.Geven]

Hi

If you have to live with LV7 I can share a tool that shows vi's in memory with there disk location.
For projects in 8.5 it is part of the system, so we don't need it less