Application Builder 2015SP1 "f1,f2" very problematic !?

[nottilie]

Dear Community

We are using Labview since Version 7 and are always building applications using the application builder and then build installers.

We often have had problems with the application builder but these where all possible to solve up to know.

As you can imagine  our projects has also been grown so now it is relatively big with a lot of netwok shared variables (approx 100) and corresponding typedefs.

So currently the status is even not describeable as it is so wide spread.

On one hand it is not  possoble to build the application because every time the error 1502 is coming up.

I already did the recommendations of the knowledge base article.

http://digital.ni.com/public.nsf/allkb/8683D4C66F5CA50E86257341007CF34D

So this is one problem.

The other one is especially on windows 32 bit and LV2015 32bit where the build application says it could not open a control because it was made with LV2014 , so a newer LV version namely 2015SP1 is in the runtime not able to open a vi or ctl which is 100% LV2015sp1 and says it is 2014 and could not be opened.

This is only the case in 32bit runtime engine.

This is also in a support loop of NI but it seems either they know something is fundamentally wrong on the 2015SP1 "f1 and f2" or they don't want to solve the problem of their up to know NI happy customer.

I know this is a confusing thread. If we use the code where the runtime engine says it could not be opened and press canel everything is working fine. The  problem is in this buld application there are about 20 vi's or controls to be canceled during startup till the application is working.NOT ANY SOFTWARE USER LIKES THIS WAY TO START HIS APPLICATION.

Finally I attach some error messages which came up till these problems are here.

I also want to mention that these problems are not limited to a single Computer so it is not the typical (Windows is corrupt driver is wrong and so aon story)

Thank you for some comments

Best regards

Gernot

[billko]

Have you tried recompiling the problem code in LV 2015?

[Jacobson-ni]

Recompiling would be good like Bill mentioned but I would first try mass compiling your project for 2015 SP1 may give more information about some of the versioning errors that you are running into.

http://digital.ni.com/public.nsf/allkb/654877E62A97B72986256C95006F9B24

I would be interested to see if the mass compile fails on the same objects which throw build errors. If it does run into errors on particular items, are you able to manually open them in 2015 SP1?

[nottilie]

Thank you for your help up to now.

I have no LV2015 without SP1 available in the moment, and moving the whole project to an other computer to test this would be a later option because it is very time consuming.

I did the masscompile for a few times till it ended up without any error messages.

The when I do a build without the "enable debugging" option it ends up with the typical error message.

In this case I have attached the vi which seems to cause this problem. (I know that there may be some typedef missing)

A VI broke during the build process from being saved without a block diagram. Either open the build specification to include the block diagram of that VI or enable debugging to include the block diagrams of all VIs in the build. Report this error to National Instruments technical support.

D:\Labview Work\libs\MeasureSettings\iTOF\iTOF Measure Setting Editor.vi

When I "clear compiled object cache" the following error message comes up:

Cannot complete build because following VI loaded broken:

D:\Labview Work\IoniTof\Application\IoniTOF20.vi

Open the VI in LabVIEW and fix the listed errors. If the VI loads as expected but errors are still detected during the build, contact National Instruments technical support for assistance.

Broken VIs:
- IONI_TDC_Server.vi:
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 SubVI is not executable
- IoniTOF20.vi:
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 SubVI is not executable
- iTOF Measure Setting Editor.vi:
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
- ITofSupply2_0.vi:
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
- write Itof Last View settings.vi:
 Unresolved linkage to network-published variable

When I open one of theses "corrupted" vi's then they are fine and runable in the development evironment so they are not really corrupted.

After clear compiled opbject cache and not reopening the main.vi again there is an error message during build

Cannot complete build because following VI loaded broken:

D:\Labview Work\IoniTof\Application\IoniTOF20.vi

Open the VI in LabVIEW and fix the listed errors. If the VI loads as expected but errors are still detected during the build, contact National Instruments technical support for assistance.

Broken VIs:
- IoniTOF20.vi:
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 SubVI is not executable
- ITofSupply2_0.vi:
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
 Unresolved linkage to network-published variable
- write Itof Last View settings.vi:
 Unresolved linkage to network-published variable

The Last stage is to open the main vi and the compile with the debug option enabled. 

Now everything works and the resultion executable is operationg as expected.

I don't like to enable the debubug option because there is no reason to do so.

At least it is an option but if somebody has a very good idea to solve it completely please tell us.

Thank you (and sorry for all the errror code)

[Jacobson-ni]

Are the VIs that are broken using any statically called shared variables (using the nodes you drag from the project)? The unresolved linkage error has a help document about it that says "The control is bound to a network-published variable, but the variable could not be found in the current project". If you have a statically called SV and remove it from the project it does cause the VI to break. There are a lot of unresolved linkages but not a lot of broken VIs, perhaps it can be linked to a library with variables only used in those certain VIs.

It's a shot in the dark but all I can really think of.

Edit: can you clarify how you get this to work. Do you enable debugging on the VI properties of the main VI and force recompile that VI and its dependencies or just run the build again?

[nottilie]

Thank you for all your suggestions.

I just want to explain that I followed some of your suggestions and it is getting better and better. Still not 100% solved but I am on the way.

Main problems are font panel bound network shared variables "especially" when they contain typdefs "structures"

The disconnect typedef button in the build descriptions leads to an application which says that you need the full developement system so solve the problem.

So I changed the code and do not use these front panel build network shared variables any longer.

So this was propably the major step. In addition I also changed some other things during this nighmare which I am no longer 100% aware of if they have anything to do with the improvement of the problem.

Thank you again

Gernot