gmart

@Stobber. Direct modifications of the tags is not recommended and not supported. There is no documentation for those tags.

Ideally, I would like to place the build in a folder that incorporates the version in the name. Check the LabVIEW 2013 Upgrade Notes: Creating Directory Versions in Build Specifications In LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination path so LabVIEW automatically includes the build version in the directory path. You can include the [VersionNumber] tag in the Destination path field on the Destinations page or the Destination directory field on the Information page of the build specification properties dialog box. Installer builder has the same functionality but uses the tag [ProductVersion].

I did not see a File->Locate in Project. There is a View->This VI in Project (CTRL+SHIFT+E) which is present in 2010 and 2011 that does what mention. Perhaps the menu item you referenced was a tool added to 2010?

Starting with LabVIEW 2010, build specifications will copy any errors codes to the run-time engine location by default. This setting is located in the Advanced page. If you do not need to copy the error code files, you can uncheck this option.

Building a "release" executable remove front panels and block diagrams of all dependencies. Block diagrams (but not front panels) are removed of all Startup and Always Included VIs. For a debug executable, all front panels and block diagrams are kept and debugging is enabled for all VIs. There are no concept of "symbols" for LabVIEW built applications so that is not part of a build. So the larger size of your application is due to the inclusion of front panels and block diagrams.

The internal format of executables changed in LabVIEW 2009. By default, though, older projects load using the older format. You can toggle this setting on the Advanced page. Look for the option - "Use 8.x file layout". Uncheck this (if it's checked) and the files will no longer be placed outside the EXE.

I think the behavior you are seeing is due to the creation of a new build specification (which you did coincidentally in 2009 SP1). I created a new EXE build specification for a caller VI that has a subVI configured as you specified. Going all the way back to LabVIEW 8.2, when a new EXE is built, the resulting app returns the error you referenced. This actually makes sense since the application builder does not know that the VI needs to have its front panel included because of that setting. Adding the VI as Always Included forces the front panel to be kept and thus the application works. It's possible that in the "working" situation, the building specification in that project has the setting such that the front panel is kept on that particular VI.

Apps built in 32-bit LV will be 32-bit. Apps built in 64-bit LV will be 64-bit. If a VI was saved by 32-bit LabVIEW it will recompile in 64-bit LabVIEW and vice versa. Built apps are saved in the version of LabVIEW used to build so even if source VIs were saved as 32-bit, when built by 64-bit LabVIEW, the output will be 64-bit (and again vice versa with 64-bit source and 32-bit LabVIEW). So in theory, you could use the same source with 32 and 64-bit LabVIEW and your output will be as expected.

Have you seen this? - Darren's Weekly Nugget 11/09/2009

It's usually difficult to reproduce 1502 errors since their root cause is typically unique to the setup that has a problem. In order to track down the root issue, I would say try to get a set of code that reproduces the problem and submit that to NI support for evaluation. Regarding the error 6. What were the circumstances where the error occurred? Was the user's destination path for his built very long? What OS? What modules/toolkits were involved? Again, reporting this information also helps with tracking down the problem.

Just to be clear. The only thing that changed between the build working and not working was the installation of SP1? You made no other changes to the code? What is the make up of your top-level VI? Does it use classes, variables, drivers, Mathscript etc?

Each SCC provider implements functionality for operations such as Check Out, etc. For Clearcase, for example, getting a project means defining where the local working path will be. So Perforce's implementation displays this dialog. Typically, other IDEs pass in the path of the working project (in the Visual Studio case) and so you don't usually see this dialog. LabVIEW does not require projects but Perforce requires this parameter, so the dialog is required. I would check with Perforce for more information on the dialog.

The Perforce dialog displays the depot structure of the selected clientspec. All you should have to do is select a folder or file in the depot list. There is a known issue with version 2009.1 of Perforce which behaves as you have described. Previous versions have allowed you to select either files or folders. For now, I would select a file under the depot location.

You can post your issue in the NI Forums. Those forums are regularly checked by applications engineers. Also you can open a service request via this - link. While NI developers do frequent the LAVA forums and occasionally provide support, the above are the "official" channels.

There is a VI in the File I/O>>File Constants palette - Application Directory - that will return the path to the directory containing the application. This will work in the development environment as well as an application. You can use this VI to build the appropriate path to your ini file. Also, there is an option in the Advanced page "Use 8.x file layout" that will keep the layout of the application flat. It is mainly there for compatibility since the hierarchy layout is the standard.