07-08-2010 03:20 PM
I have my current LV files including the .lvproj files in directory C:\avionics. My old files are in C:\xAvionics.
The other day I loaded one of the old files to verify how something was done. When it loaded it loaded lots of dependencies. I closed it without making changes. The next time I ran my project from TestStand it loaded a great number of files from the old directory. I noticed things didn't look right so I opened the .lvproj file and it complained of conflicts. Why does this happen and how do I look at old files without causing a problem?
thanks,
jvh
Solved! Go to Solution.
07-08-2010 03:57 PM
One thought. Did you make sure to open the most recent version of LabVIEW with your new files in it before you opened TestStand? TestStands editor will use the last version of LabVIEW that was opened.
07-08-2010 11:36 PM
When you opened the old file, did it ask that you already had the file in memory (the new version) and whether you want to look a the old or the new (I think it is actually something like replace or cancel)?
If the new is in memory (and thus all other files in memory link to it) and you open the old and you say," yes show me the old", the old file now becomes the one in memory, and all linkages will be to that assuming you save the higher level files. (Or maybe just save the .lvproj).
When you opened the old VI, did you just open the VI, or did you open the old project as well and then open the VI. I think if you have both projects open, the the old VI will open in the context of the old project, the new VI will remain open in the context of the new project. And they shouldn't cross-link. But if you open up just the old VI, it will be in the context of the new project, and the higher level VI's might cross link to it.
One way to fix is to open up your new VI first. Then open up the higher level VI's and they should now pick up the new VI since it is already in memory. Then go and save those higher level VI's. Otherwise, do it all in the context of the project, and try to use its mechanisms to replace one VI with another and resolve the conflicts. (I find I have to spend a lot of time reading those dialogs, paying attention to paths, and clicking the right one to get the conflicts resolved. It really isn't fun.)
07-09-2010 06:52 AM
I have had this problem alot. The reason being LV referring to files by names as unique identifiers, thus if you already have the same name loaded that one will be used. Regardless of where from, and due to the autolinking features all other VI's will switch to this one.
To avoid the problem, close all of LV (ctrl+q) before opening an old project.
To fix it, you can change the folder name of one project and open the other, then it wont find some files and will search down the hierarchy from the active folder, switching back to the original files.
If you dont have all of the project in a direct hierarchy but at "neighbour" level it's abit messy but you should get the "point to vi".
/Y
07-09-2010 08:06 AM
I am sure I had the new one in memory when I opened the old one as I was modifying the new files. I thank all of you for your posts but it seems there is no really good solution available. This became a big can of worms and it seems I was correcting dozens of files through the project dialog. I finally changed the name of the old project's directory and it all loaded better.
The sinister part of it is the fact that it was transparent and there was only indirect evidence of a problem. I have submitted a ticket and well let you know if Austin has a solution. For now I am making the project file read only as it contains well over 1000 items and additions will be few.
jvh
07-09-2010 12:15 PM
Austin's reply suggests using source control which I already use. I have .lvproj checked out because I am modifiying the project so should I draw the inference "don't modify the project"? Just kidding. Since it is under src control I can go back and get the original. The problem is the fact I didn't know I needed to do so.
Here is their response.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi Stephen,
I've been looking into the best way to avoid the relinking of files to old versions. Unfortunately, LabVIEW is going to continue relinking the VIs and there's not a built-in option to work around that. What we can do is use Source Code Control.
Source Code Control allows us to save changes that we make to the VIs and revert to specific versions, in case we wanted to try out old code or remove any new changes that we add to our programs. This is a huge benefit in that we can immediately log and view any changes we make to our VIs (especially large applications, such as your own).
LabVIEW does allow you to use Source Code Control software, such as Perforce, so that you can share files with your colleagues. You can find more information on it here: http://decibel.ni.com/content/docs/DOC-1681 .For a quick, free, and highly effective Source Control software, you can use Subversion and TortoiseSVN. Both of these programs are free and TortoiseSVN integrates directly into Windows Explorer, so you can quickly and easily commit and revert your changes.
You can find the Subversion server software here:http://subversion.apache.org/packages.html#windows, but I downloaded the version at this website: http://www.collab.net/downloads/subversion/.TortoiseSVN can be found here: http://tortoisesvn.net/downloads . Onceinstalled, you can find directions on using this software with your application development at the article here:http://digital.ni.com/public.nsf/allkb/C751F800E258087B86257535006DB160?OpenDocument.
I apologize that there isn't a quick and easy fix built into LabVIEW. I hope that you'll find that using any form of Source Code Control will not only benefit your current application, but any future large application development projects. If you have any questions today, you can reach me by replying to this email or by calling ...
07-09-2010 12:40 PM
I am not often opening an old version and a new version at the same time so I had little oppertunity to see this situation myself, which I have not seen.
What Ravens Fan said was correct and I have only one idea to offer.
Do you have aut-save enabled?
Perhaps LV saved it when you were not looking.
Ben
07-09-2010 01:02 PM
And since you are using TestStand, you should know that if you open the VI from there, you are not using the project. TestStand simply references the VI itself so you can easily crosslink if you are not careful.
07-09-2010 01:42 PM
@Dennis Knutson wrote:
And since you are using TestStand, you should know that if you open the VI from there, you are not using the project. TestStand simply references the VI itself so you can easily crosslink if you are not careful.
To aviod cross linking issues I use "Tree.vi" that hold all of the VI's that run top-level in the app. I open that first to ensure I load everything in the app. before I open any other VI.
I also carefully watch for dirty dots and save or don't save depending if I expect the VI to change. If I did not expect it, I start looking before I say OK.
Ben
07-15-2010 08:13 AM
Ben,
What is Tree.vi, is it part of labView or is it your top level vi?