From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
11-04-2014 01:41 PM
I'm writing a LabVIEW DLL to inspect LabVIEW project files, and I've noticed that if a project has a .lvlib reference in its Dependencies, then the Run-Time Engine contradicts itself about whether or not it can find the project file:
Here are snippets from my G and C code that exercise this behavior:
int openStatus = StatusSuccess; char* projectVersion = createStringWithLength(VersionStringLength); printf("Analyzing %s\n", pathString); OpenProject(pathString, &openStatus, projectVersion, VersionStringLength); printf(" Project written in LabVIEW %s\n", projectVersion); if (openStatus == StatusSuccess) { printf(" Opened project file.\n"); } else { printf("Error: Could not find project file, or file was not a project file (error code %i).\n", openStatus); }
However, when running in the development environment, both methods succeed.
Is this a bug, and if so, is it fixed in LabVIEW 2014?
Here is how you can reproduce it:
Prerequisites:
.lvlib reference in Dependencies breaks Project.Open in LV RTE
$ make patching file `builds/platdefines.h' gcc -std=c99 -g OpenProject.c -o OpenProject.exe -lOpenProject -Lbuilds
6. Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
$ OpenProject 'c:\xtra\temp\OpenProject.lvproj' Analyzing c:\xtra\temp\OpenProject.lvproj Project written in LabVIEW 13.0 Opened project file.
7. Notice that both invoke nodes execute correctly.
8. Type OpenProject 'c:\xtra\temp\OpenProjectWithLvlibDep.lvproj'
$ OpenProject 'c:\xtra\temp\OpenProjectWithLvlibDep.lvproj' Analyzing c:\xtra\temp\OpenProjectWithLvlibDep.lvproj Project written in LabVIEW 13.0 Error: Could not find project file, or file was not a project file (error code 7).
9. Notice that the version node succeeded while the open one failed.
10. Type diff OpenProject.lvproj OpenProjectWithLvlibDep.lvproj
$ diff -u OpenProject.lvproj OpenProjectWithLvlibDep.lvproj --- OpenProject.lvproj Tue Nov 4 11:28:28 2014 +++ OpenProjectWithLvlibDep.lvproj Tue Nov 4 11:32:37 2014 @@ -13,7 +13,11 @@ <Property Name="server.vi.propertiesEnabled" Type="Bool">true</Property> <Property Name="specify.custom.address" Type="Bool">false</Property> <Item Name="OpenProject.vi" Type="VI" URL="../OpenProject.vi"/> - <Item Name="Dependencies" Type="Dependencies"/> + <Item Name="Dependencies" Type="Dependencies"> + <Item Name="vi.lib" Type="Folder"> + <Item Name="NI_MABase.lvlib" Type="Library" URL="/<vilib>/measure/NI_MABase.lvlib"/> + </Item> + </Item> <Item Name="Build Specifications" Type="Build"> <Item Name="Open Project Library" Type="DLL"> <Property Name="App_copyErrors" Type="Bool">true</Property>
Here is another way to trigger this behavior, which also shows that LabVIEW only sometimes tidies the Dependencies item:
Solved! Go to Solution.
11-05-2014 02:59 PM
Hello MacNorth,
I can attempt to recreate this issue, although it may take some time. What operating system are you using?
11-05-2014 07:39 PM
Hi Cameron, thanks for your response 🙂
I'm using Windows XP SP3.
11-06-2014 04:52 PM
Hi MacNorth,
I was able to recreate this bug by buliding an executable from your OpenProject.vi and attempting to open a new blank LabVIEW project.
Software Used:
LabVIEW 2014
Steps Taken:
1. Build .exe from OpenProject.vi
2. Open New Project
3. Add a new vi with an "Application Directory" file path constant on the block diagram
4. File » Save All
5. Run Application
6. Input filepath of new project
7. Results = Error 7, Version 14
8. Remove "Application Directory" file path constant
9. File » Save All
10. Results = No Error, Version 14
This appears to be a bug. However, before filing a Corrective Action Report I'll need to test the phenonmon with the LabVIEW RTE
11-08-2014 12:14 PM
NInjaneer_wow wrote:
I was able to recreate this bug by buliding an executable from your OpenProject.vi and attempting to open a new blank LabVIEW project.
<snip>
This appears to be a bug. However, before filing a Corrective Action Report I'll need to test the phenonmon with the LabVIEW RTE.
Thanks for the update. I see the same behavior in LabVIEW 2013 when I build an executable from OpenProject.lvproj.
Please let me know what you learn.
11-10-2014 05:13 PM
Hi MacNorth,
The same behavior occurs in LabVIEW RTE: a new project with an Application Directory constant in a blank vi will return error 7 - file not found, but still return the correct version of LabVIEW in which the project was created.
Thank you for your patience and, additionally, for making us aware of this bug. I will go ahead and file a Corrective Action report.
11-10-2014 05:23 PM
NInjaneer_wow wrote:
The same behavior occurs in LabVIEW RTE: a new project with an Application Directory constant in a blank vi will return error 7 - file not found, but still return the correct version of LabVIEW in which the project was created.
Thank you for your patience and, additionally, for making us aware of this bug. I will go ahead and file a Corrective Action report.
Thanks for your diligence in exploring a bug in the darker corners of LabVIEW. What is the Corrective Action report ID so I can check for it in future LabVIEW releases?
11-11-2014 08:49 AM
CAR 505322
Cheers,
11-28-2014 10:39 AM
NInjaneer_wow wrote:
The same behavior occurs in LabVIEW RTE: a new project with an Application Directory constant in a blank vi will return error 7 - file not found, but still return the correct version of LabVIEW in which the project was created.
I've been experimenting with workarounds for this behavior, and I found one.
When I provide the LabVIEW path for libdir in my executable's ini file, the run-time is able to load and inspect the project file.
libdir="C:\Program Files\National Instruments\LabVIEW 2013"
While it's expected that a stand-alone executable may be placed on a system that doesn't have the LabVIEW IDE, it's still surprising to me that the Run-Time Engine cannot find LabVIEW's standard library without some explicit guidance. What other considerations contribute to that behavior?
References:
10-04-2016 05:06 PM
I have had the exact same problem with LabView 2014 and adding the libdir helped. I was not using the RTE, however. I was trying to compile an exe for the AppBuilder, which does refer to several lvlib files in the vi.lib.
Thank you for the solution, it really helped me! I was banging my head against it for a day.