07-10-2014 05:03 PM
When attempting to load an existing VI while a project is open and the new VI caues conflicts LabVIEW shows a warning window. If LabVIEW has a loading window open when the conflicts message appears then LabVIEW becomes unresponsive on all of its windows except for the help window. The buttons appear to function but nothing happens. I can move the Loading ... window around but none of the others. I left it for 30 minutes yesterday (different VI that I was trying to load) but no joy. I had to kill LabVIEW and lost my work. Same situation today. These were both examples I downloaded from this forum.
How can I avoid this problem in the future?
Thank you.
See attached image
Windows 7 64-bit
LabVIEW 2013, updated to current
07-10-2014 06:42 PM
It looks like the conflicted files are VIs from the DAQmx library. Why do you have copies of them that you are trying to load from elsewhere?
Find those extraneous copies and get rid of them.
Mike...
07-11-2014 12:06 PM
This is a default LabVIEW install. Fresh two weeks ago.
I searched C:\ for DAQ*.vi and *.llb. No hits on the first, the second only lives in the <LabVIEW> heirarchy.
The root of the problem both times is that when I double clicked the vi I was trying to examine (in the default Windows 7 downloads folder) LabVIEW tried to add it to the open project. The only place I see either of the DAQmx vis listed is in the project dependencies list under vi.lib. Just to be clear, the conflicting files listed do not exist outside of the llb they come prepackaged in.
I have done the same actions this morning, with the same project open and "digital input and output.vi" in the same directory as it was. I tested with the project open, then with a VI open, then with VI with unsaved changes open, and finally with the project having unsaved changes. I tried these combinations with the LabVIEW help window open as it was yesterday. LabVIEW did not hang.
At present I can have a project open and double click a nonproject vi and the nonproject vi front panel opens without conflicts. The nonproject vi is not added to the open project. I used the digital input and output.vi for testing this.
I would like to figure this out. It has happened twice and I lost 30 minutes of work the second time. LabVIEW recognized the corrupted project file and tried to repair it but all my channel setups (the last thing I was working on) were not there.
07-11-2014 12:18 PM
LV should give you the option to either add it to the currently open Project -- which is almost always a bad idea, or open it in a new project of its own that LV creates on the fly.
Mike...
07-11-2014 01:15 PM
I get neither of those options. LabVIEW just opens VIs that I double click.
07-11-2014 01:27 PM
This sounds familliar. there was a patch released for the TSVN Toolkit because the framework had a small issue that only reared its ugly head when opeening a vi that caused a conflict.
07-11-2014 03:24 PM
07-11-2014 03:48 PM - edited 07-11-2014 03:56 PM
Mike,
The problem is related to having a project open and then trying to open a single VI that is not part of the project.
<edit>
I see that I was not clear in my statements describing how I was trying to reproduce the problem. I should have written:
I have done the same actions this morning, with the same project open and "digital input and output.vi" in the same directory as it was. I tested with the project open, then with a project VI open, then with the project VI with unsaved changes open, and finally with the project itself having unsaved changes (renamed file using project explorer). I tried these combinations with the LabVIEW help window open as it was yesterday. LabVIEW did not hang at any time when I double clicked the "digital input and output.vi" which is not included in the project.
07-15-2014 09:32 AM
The problem has reoccurred 3 times this morning (see attached image for the 3rd lockup). All with local files. I have a LabVIEW project open, when I open a VI outside of the project (using windows explorer) I sometimes get the mxLvGetFilePathBatch.vi loading message and then LabVIEW freezes. mxLvGetFilePathBatch loading message is the last apparent LV action every time before the lockup This happens when the loading window opens while another LabVIEW related popup is showing. See attached image where I was trying to examine a vi that is in my user.lib while LabVIEW was open. In this case the VI is referenced by the project (strict static vi reference) but that is not always the case. The first two lockups this morning were with nonproject VIs that use some of the same user.lib VIs as the project. My user.lib is at the default location in the LabVIEW program directory.
The attached txt file is in html format, it is a table listing my installed packages. An export from JKI package manager, massaged with excel for readability.
I would appreciate any ideas on how to proceed with debugging this problem.
07-15-2014 09:59 AM - edited 07-15-2014 10:01 AM
The error you see is from opening a project. In addition to the project add-on for TSVN it looks like there is perhaps another?. Can you remove them and see if the problems persists? This is beginning to fit together. It is beginning to look like there is a problem with the way the project is working.
Mike...