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.

What exactly is the fundamental difference between executable builds when debugging is enabled versus not enabled? Other than the inclusion of symbols and what not so breakpoints can be used etc.

I have an application which I've been building with debugging enabled for months and it has worked beautifully. I've now switched to release mode (not checking the "Enable debugging" box) and spent a few days trying to figure out why the executable no longer functions. I realize I'm being nebulous about this, but I really don't know what isn't working yet, so I can't really go into details. All I know is my executable spins up, shows the splash screen, grabs about 100 MB of memory then...just blocks. I'm making very slow progress mostly due to the long build times (I only run builds when I'm out to lunch, or when I leave for the night, meaning I only get two shots to fix it each day). Any tips on what might be different with respect to debug and release builds?

Last night got me thinking maybe release builds are removing front panels of my dynamically loaded VIs, so that's next on my list of things to check. More news after the (lunch) break I suppose.

I've also noticed the executable goes from 50 MB in debug mode to 24 MB in release mode. That seems like a big difference, but I have no idea what's involved with debug symbols etc, maybe that's normal?

Regards,

-m

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

I have a very similar thing happen to my customer. He use a lot of classes and he keep getting error 1502 (Cannot save a bad VI without its block diagram.) [Note: Everything run fine in the IDE, nothing broken]. He spent several days trying to fix this, without success. For now he has to enable the debugging flag to be able to build an exe.

Between this error (1502) and error 6 (file I/O=Path too long), building an executable is getting really difficult.

This really need to get fixed.

PJM

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?

Ok, that should get me past this issue. Thanks!

But I still wold like to know what this setting is for and why I need to set it.

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.

Does anyone know what the Source Control Project field in the SCC configuration dialog is for? I am using the Perforce SCM provider. I have read the help, goggled the internets and called NI support but know one seems to know.

When I setup SCC, I have to choose something for this field. The dialog that appears has a disabled OK button until I choose a sub folder of my Perforce Depot. If I select a folder, I get error -2915. If instead I continue to expand the tree until I see a file and then select that, it is happy.

I just wish I understood what was going on here.

Thanks for any help!

-John

(using LabVIEW 8.6.1 and the latest version of Perforce P4V on Windows XP)

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.

Hi gmart

What is the best way to do that (sumbit code + report for eval to NI)?

I have not done that before

Is there a specific site to upload code?

Or do I use the NI forums?

Cheers

JG

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.

I haven't tried the above, but I have noticed some strange things when building in 9.x.

With source distributions, sometimes a control that is supposed to be included in an .llb destination, appears at the top level of the source distribution - outside of the .llb!

I have to manually select that control to be in the correct destination folder, even though that virtual folder is set to go to the .llb

If you can reproduce this behavior, it would be good to report that to NI support for evaluation.

Yup. I've been reading this thread with interest from my RSS reader.

Up until just now.

I, well, used to get threads from: http://lavag.org/ind...ype=forums&id=1

All ****ing Alfa String now.

I've been Alfa bombed as well.

Once I understood the issue, I was able to solve it by dragging the toplevel to the desktop and the build compiled without errors.

Unfortuneatly, our Source Tree is already well defined, so I can't so this,

What do you mean by your source tree is well defined? What I suggested doesn't require you to change your source layout. All you'd need to do is change the destination directory in the build spec to a shorter location (ex. C:\temp). That should reduce the destination path lengths. If the output needed to be at a certain location for other build tools, you could write a VI to copy the files from the new location back to the old location.

This is great news wrt to the build.

Internally LabVIEW does not have the same restrictions as e.g. Windows OS.

So whilst the build process may become corrupted, once the EXE is build and if it gets moved LabVIEW can handle the long path names.

Cool

Are you kidding me! No more files outside the EXE, all those class methods hidden, - I am never going back...never I tell you....

But seriously, the build process failing all the time with long files names is starting to annoy me.

And thats just from evaluation. I am really worried when if comes to out Source Tree too, if it going to be quite deep already.

I can see this being a huge PITA.

The word "corruption" is scary and not really what is happening during the build. We get an error while building due to OS limitations. Nothing is corrupted. Words mean things and the last thing we need is someone googling this problem and seeing the word "corruption" .

Regarding the long path names, one thing you can do to mitigate the problem is to change your destination directory to something shorter. I know that may not be possible in all cases, but that will buy you some extra characters. Alternatively, you can quit being so descriptive with path names and go back to the DOS days of 8.3 filenames .

As always thanks for replying Gmart

What I am trying to establish is - is it just the build were long file paths may be a problem?

And if it passes the build the exe will always be fine?

Or could a situation arise that if LabVIEW tries to resolve a path in an executable (depending on where it is in a folder hierarchy) it could be corrupt due to the limitation of characters in the Windows OS?

In general Windows (and Mac and Linux I believe) have a character limitation for paths. In the past, some of that limitation was masked by the use of LLBs for the EXEs format. LLBs have special behavior (such as allowing characters in filenames that OS's don't like) that could let a name of a VI exceed the OS path limitation. Since LabVIEW knew how to deal with the path, it was ok. With the 2009 EXE, your concern about the path resolution shouldn't be an issue. Since we can't get into a path length problem due to OS limitation, LabVIEW will not have to deal with a path that's "too long".

I am wondering if this has anything to do with the new way exe's get built?

Look at the path in the error:

C:\Users\Developer2\Desktop\User Group Meeting\LabVIEW 2009 new features\code\02 intermediate\01 build specifications\build executable file paths\dist\application 9.0\my application.exe\LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb

That path is referring to a VI inside my executable!

This may be a bigger issue that I first thought

With the new format for applications, files are stored relative based on the source files' layout. Because of this, it is possible for the destination file paths to get long while building. There is information on the change in the upgrade notes.

ESST,

Thanks for the thorough response. The problem is due to the file named "CFG-I/O-Bytes.vi". It contains a slash which is not valid for the OS. This is not a problem if the VI is inside an LLB since that was allowed. During the process of building an application with the non "8.x layout", files are written to disk. Since that filename is not valid, the error results. The error was reported to R&D (# 158487).

The workaround is to check the checkbox (which is the default when loading older projects). Also, you could try to rename the VI during the build process. You will need to have the files under My Computer so you can individually rename that one file.

Hi,

I ended up whit a similar(I don’t remember the exact error text) issue during a8.6.1 to 2009 project upgrade.

The problem was under "Advanced" in the build setup, I had notselected "Use Labview 8.x file Layout". When selected, no problem, buildsgalore. Your mileage may vary.

Espen

ESST,

Did your project also use the SPT toolkit? What was your exact error? It would be helpful to know this to better understand why toggling the checkbox worked for you.

I've been seeing this same behavior in Thunderbird. I thought I was going crazy so I'm glad to see it's not just me. I'm subscribed to - http://lavag.org/rss/forums/1-lava-forums/. I never had a problem with LAVA RSS until LAVA got updated.

Just stumbled across this new feature in LV2009:

Build Application from VI

What, you didn't find it on page 46 of the Upgrade Notes?

"The Build Application from VI dialog box allows you to build an application from the VI you are currently editing."