Jump to content

Recommended Posts

Hello everyone,

 

I recently installed LabVIEW 2013 on my development machine to get rid of some issues in my current project.

However the project is originally build in LabVIEW 2011, so I had to save all VIs for the new version (no issues :worshippy: )

I'm still able to build the application executable with no problems too!

 

Now I want to provide an installer for the customer to upgrade the Runtime engine and some additional stuff
that has been changed for LabVIEW 2013. And there lies my problem, as I'm currently unable to build an
installer. The configuration dialog shows 'error generating preview' for any executable in the project:

 

post-17453-0-47899200-1379675124_thumb.p

 

Naturally I tried to generate the preview in the executable, but there seems to be no issue:

 

post-17453-0-88982200-1379675165_thumb.p

 

Creating new specifications did not solve the problem and even creating a whole new project file and including
the startup VI to it + creating new specifications did not solve the problem...

 

I made a new project with a single VI for testing if the application builder is not working in general, but thats
not the case, as I was able to create an application + installer with no issues.

 

So I'm quite sure there is something wrong in my project that causes this behaviour, but I've currently no clue what that
could possibly be. I read somewhere (in the NI forums I guess) that there could be issues if you have files in your project
that are build in an older version (as one of the dll files), so I upgraded it... with no success...

 

Now does anybody had an issue like that in the past / currently and is there anything I could do or check to regain the ability to provide a proper installer?

What could possibly cause the installer dialog to fail generate a preview where the application dialog is successfull?

 

Any ideas are welcome :)

Link to post
Share on other sites

How much work would it be to recreate your project in 2013?  I ask because I have seen instances where a project file get corrupted or something, where it breaks and there is no explanation for it.  So I tried making a new project, then adding my code to it, making the Build Specification the same way the other was and it works.  Possibly something went wrong in the upgrade process from 2011.  I'm not saying this will fix it but if the project file it self is the problem this should help.

 

I just reread your post and it sounds like you may have tried this, you said "so I upgraded it... with no success..." what did you upgrade?

 

Also I never use the Generate Preview.  The last time I used it, it took just as long to generate a preview as it did to build the application.  Has it improved over the years?

Link to post
Share on other sites

How much work would it be to recreate your project in 2013?  I ask because I have seen instances where a project file get corrupted or something, where it breaks and there is no explanation for it.  So I tried making a new project, then adding my code to it, making the Build Specification the same way the other was and it works.  Possibly something went wrong in the upgrade process from 2011.  I'm not saying this will fix it but if the project file it self is the problem this should help.

 

I just reread your post and it sounds like you may have tried this, you said "so I upgraded it... with no success..." what did you upgrade?

 

Also I never use the Generate Preview.  The last time I used it, it took just as long to generate a preview as it did to build the application.  Has it improved over the years?

 

Hi hooovahh,

 

Well I use a DLL file in my project that has been created in LabVIEW 2011. This should be no issue, but would have made my application to load both runtimes (2011 for DLL & 2013 for EXE) so I managed to recompile the DLL in 2013. This is what I mean by upgrading "it".

As for the preview: If you create an installer, you want to tell it where to store the application files. For that the installer dialog will automatically generate the preview in order to provide the files list... I also want to provide a menu shortcut to the executable which I cannot create if there is no preview that includes the actual executable (it is basically as if it doesn't exist at all!).

 

The preview generator (in the application specification) is very quick for large applications. :star:

 

Hi LogMan,

 

I had exactly the same symptoms when upgrading a project from 2012 to 2013.

 

After a lot of cursing and stripping my code back to the bare minimum I was left with a stupidly simple main VI that would build fine, and could create an installer. Adding a single VI to this would cause the installer to not generate the preview as you noticed, and also fail to build.

 

The VI that broke the camels back was a harmless utility from one of my re-use libraries (.lvlib). This library has a whole bunch of functions in it, and some of the VIs called some other libraries (obtained via VIPM) which I had not bother to install in my 2013 dev environment. Even though I was not actually calling these VIs from my main app (i.e. the main app was perfectly legit) the library was probably being loaded into memory when you do the file preview in the installer, and as there were dependencies missing it got confused.

 

So, to fix the problem I just needed to have all my dependencies installed, and the problem went away.

 

Edit: try a mass compile on your source directory, it will very quickly show you if you have missing dependencies.

 

Hi neil,

 

It seems I'm not the only one who had problems lately. Lucky me, as I now have an experienced bug tracker :P

 

I did as you suggested: I mass compiled all the project folder and cleaned up the orphan & bad VIs unless there was no error left, but still no improvement.

 

Here is what I did:

1. Mass compile project folder (returned some warnings about Bad-VIs & Missing VIs) -> Due to orphan VIs in my folder structure :rolleyes: (removed!)

2. Mass compile project folder (still returned a bad VI) -> Removed it from my project library

3. Mass compile project folder (no error) -> Still can't see my preview in the installer dialog

4. Mass compile shared company libraries (no error) -> Still preview error

5. Clear compiled object cache (I use SVN, FYI)

6. Mass compile project folder (no error) -> Still preview error

7. Create a new project; add all necessary files; create an application specification; create the installer specification -> Does not work (preview error)

8. Mass compile vi.lib (did only take about an hour or so :book:  & returned a bunch of errors -> masscompile.txt)

 

I did stuff like:

- Restart LabVIEW

- Reload Project

- Recreate Project

every now and then, but in the end there was still this <Error generating preview> text. :(

 

Well I'm ready for my weekend but if there are any more suggestions I would be happy to try them out!

Nice weekend to everybody! :beer_mug:

Edited by LogMAN
Link to post
Share on other sites
Well, you could try what I did (as painful as it is), start pruning large chunks of your Main VI until you do get to a point where the installer preview works. Note you do not actually have to build the exe to check the installer preview. This may shed some light on what is the offending code that the installer builder does not like.

 

Also, try adding:

 

 NI_Appbuilder_logging=TRUE

to your LabVIEW.ini file. This will cause a text log file to be generated for all your builds, including the installer. Try actually build the installer even if the preview is nerfed, you should get some info from the logfile. The log file appears in the same directory level as your .lvproj file.

 

Good luck, this is such a frustrating thing to debug!

 

Thanks for the advice neil!

Where can I find the log file btw? (my build does abort instantaneously, so I'm just curious)

 

I found the VI in which the problem occurs (using your method). One of my VIs is very, very badly broken, but still executable :blink:

I can see the preview now, if I completely remove that specific VI from the dependency!

 

Maybe I'm halucinating here, but I'll now contact NI for further investigation and may update once I got answers.

Thanks for the support! :D

Link to post
Share on other sites
Thanks for the advice neil!

Where can I find the log file btw? (my build does abort instantaneously, so I'm just curious)

When I've used that INI key it makes the log file in the same directory as the project file with a .TXT file extension.

  • Like 1
Link to post
Share on other sites
I found the VI in which the problem occurs (using your method). One of my VIs is very, very badly broken, but still executable :blink:

I can see the preview now, if I completely remove that specific VI from the dependency!

 

Would you elaborate on what was broken? I'm intrigued.

 

(One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

Link to post
Share on other sites
Would you elaborate on what was broken? I'm intrigued.

 

(One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

 

Well the project is still broken. I know the part/VI in my project that causes the issue but I'm not sure why, so I'm currently in contact with NI to find a fix. I will surely post the solution once I know what is going on...

Link to post
Share on other sites
Would you elaborate on what was broken? I'm intrigued.

 

(One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

Not just the disabled diagram structure.  I found one time where my code used the conditional diagram structure to do different things if it was in the runtime engine or not.  Both cases were executable and worked fine.  Then I changed the VI to be inlined.  The VI ran just fine in the development environment, but in the runtime engine case I used a property node which isn't allowed in a inlined VI.

Link to post
Share on other sites

Hello again!

I'm back to report the problem / solution.

 

The <Error generating preview> in the installer dialog is caused by a bad VI from one of NIs Toolkits! The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem.

 

Thanks to neil :worshippy:  who made the suggestion to add an INI key to the LabVIEW.ini

NI_Appbuilder_logging=TRUE

The build log is created next to the *.lvproj file and directly shows the problem.

 

 

Where the IDE dialog just showed me an error: -1!

 

:frusty:  !!! error -1 !!! :throwpc:

 

 

Here is the important line:

 

The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'.

 

This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project )

As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP.

 

I hope this prevents anybody else to run into the same problem.

 

Thanks for the support and the helpfull suggestions, my project is now OCD conform :wub:

  • Like 1
Link to post
Share on other sites
Thanks to neil :worshippy:  who made the suggestion to add an INI key to the LabVIEW.ini
NI_Appbuilder_logging=TRUE

The build log is created next to the *.lvproj file and directly shows the problem.

That is fantastic.  I wanted the INI key for a more detailed file list of what has been made in an installer.  I had no idea that it would give more detailed failure information.  I may do some testing on build time, and if it isn't much more I'm going to use this on all builds I do.

Link to post
Share on other sites

Here is the important line:

 

The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'.

 

This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project )

As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP.

 

I hope this prevents anybody else to run into the same problem.

 

I recently ran into the exact same thing except my offending VIs weren't password protected so this thread definitely helped.

 

Does anyone know what mechanism causes VIs to lose their linking to their lvlib files?  I only noticed that it was happening when I came across this error.

Link to post
Share on other sites
I recently ran into the exact same thing except my offending VIs weren't password protected so this thread definitely helped.

 

Does anyone know what mechanism causes VIs to lose their linking to their lvlib files?  I only noticed that it was happening when I came across this error.

 

Unless you remove a VI from its library, it will stick to it, even if you try to load it without the library. However if you load a VI that is part of a library, you can disconnect it (File -> Disconnect From Library). I think there is also a possibility, to break the library, if you replace a VI of the library with one that is not linked to it (I have not tested this though). This is why I avoid to edit VIs while the library is not loaded.

Link to post
Share on other sites
This is why I avoid to edit VIs while the library is not loaded.

This is the best practice for sure.  I always start with a project, or a library.  Often times I forget about some kind of linkage that editing just a VI will cause issues with.  I like to bring up text based languages and say that if we were writing VB code would we take notepad and open some random file to edit?  No we would open the project first.

Link to post
Share on other sites

Hello all,

 

I just wanted to let you know that we are aware of the issue described in the first post (the problem with builder an installer with certain VIs). In this case it is a VI from the automotive diagnostic command set library (CAR 429636). This is caused by a change in LabVIEW 2013 to the installer builder. There are two parts to this issue - 

 

1) If your project contains VIs in certain libraries, you are not able to build an installer that contains these VIs. There is no workaround for this and we intend to issue a LabVIEW 2013 f2 patch which will address this. (CAR 429282)

 

2) If your project contains VIs in certain libraries, you are not able to build a source distribution of those VIs. This is related to 1) but there is a workaround for this. If you go into your build specification Additional Exclusions and check the box for Remove unused members of project libraries you will be able to build fine. This issue will not be addressed by the patch.

 

I find that the appbuilderlogging INI token is extremely helpful for debugging build problems, the additional exclusions are often another good place to look at if you are running into strange build errors.

 

Thanks

Link to post
Share on other sites
Hello all,

 

I just wanted to let you know that we are aware of the issue described in the first post (the problem with builder an installer with certain VIs). In this case it is a VI from the automotive diagnostic command set library (CAR 429636). This is caused by a change in LabVIEW 2013 to the installer builder. There are two parts to this issue - 

 

1) If your project contains VIs in certain libraries, you are not able to build an installer that contains these VIs. There is no workaround for this and we intend to issue a LabVIEW 2013 f2 patch which will address this. (CAR 429282)

 

2) If your project contains VIs in certain libraries, you are not able to build a source distribution of those VIs. This is related to 1) but there is a workaround for this. If you go into your build specification Additional Exclusions and check the box for Remove unused members of project libraries you will be able to build fine. This issue will not be addressed by the patch.

 

I find that the appbuilderlogging INI token is extremely helpful for debugging build problems, the additional exclusions are often another good place to look at if you are running into strange build errors.

 

Thanks

 

Thanks for the update JeffP

I recently opened a new topic in the 'LabVIEW Bugs' forum to track the issue in the future (forget to post it here though :oops: )

http://lavag.org/topic/17166-error-generation-preview-in-installer-properties-caused-by-automotive-diagnostic-command-set-120/?hl=429636

 

The INI token is indeed very helpful, but unfortunately very difficult to discover (If it wasn't for Neil I would still be stuck...).

Link to post
Share on other sites
  • 2 weeks later...

Hi,

 

To close the loop on this, the LabVIEW 2013 f2 Patch is released on the web and will be going out through NI Update Service in the near future. One of the fixes it includes is for this specific installer builder CAR 429282. The details for the patch are located here and the 32-bit download is located here

 

Thanks

  • Like 2
Link to post
Share on other sites
  • 2 weeks later...
Hi LogMAN,

 

I looked into this more and found a case where the patch did not fix the issue. I have tested with your specific case against our new fix, and I believe it should now be fixed. If you take the attached VI and replace the file at LabVIEW 2013vi.libAppBuilderEngineAB_Engine_Update_Source_from_Linker.vi with it, you should be able to build.

 

Please let me know if that doesn't work.

 

Thanks

 

Great, thanks!

 

I'll try as soon as I'm back in the office the week after next week. You'll get an update then.

Link to post
Share on other sites
  • 2 weeks later...

Great to hear! The fix in that file will be included in the next f patch for 2013 (when/if that occurs), it will also be included in LabVIEW 2013 SP1 when that gets released. After that time, it will no longer be necessary to manually replace that file.

 

Thanks

Link to post
Share on other sites
  • 3 months later...

Just ran into this one personally.  Not sure what the offending VI is but replacing the one in the vi.lib with the one you posted fixed it.  Can't wait until SP1.

  • Like 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By David_L
      Hey all,
      (Cross-post from ni.com forums)
      We have a LabVIEW application, which has a LabVIEW-based Installer.  This LabVIEW installer is called from within another Inno installer (since our main Inno installer pulls together multiple components, most of them not LabVIEW).  Whenever this Inno installer ends, it always asks the user to restart their PC, even if the LabVIEW installer was cancelled.
      I narrowed it down, and it's reproducible with only the LabVIEW installer, so it's definitely LabVIEW installer's fault.  According to Inno's help documentation, "if a program executed in the [Run] section queues files to be replaced on the next reboot (by calling MoveFileEx or by modifying wininit.ini), Setup will detect this and prompt the user to restart the computer at the end of installation."  However, as stated above, this dialog is triggered even if the LabVIEW installer was cancelled and wrote no files.
      Now, the above linked documentation refers to a flag I can put in my installer script to ignore this restart dialog, but it's a global flag, and I would like my other installers to still make use of this handy restart dialog if necessary. Unfortunately it seems LabVIEW installers trigger this even if not actually necessary.
      Has anyone seen this before? Any ideas how to make my LabVIEW installer NOT muck around with the MoveFileEx or wininit.ini stuff if/when it's not actually needed?  Attached is a LabVIEW project and Inno Installer script which easily reproduces the problem.  To reproduce:
      Extract the attached .zip Open test.iss in Inno Setup and click the "Run" button Alternately, just run the built installer under "\Output\test_inno_installer_9.99.0.0.exe" Click Next on 'Select Components' dialog Click Install on 'Ready to Install' dialog When LabVIEW installer pops up click Cancel, then yes (you're sure) See the Restart dialog Thanks!
      David_L
      InnoLabVIEWBug.zip
    • By Gan Uesli Starling
      We have a gage supplied by a company that shipped it with a *.exe application targeted for LVRTE 2009. I need to retarget it for 2017, but don't have the source code. The supplier had said they'd gladly supply me with a copy of the *.LV source, but they have looked and cannot find their own copy in-house.
      History of Need: Our global corporate mother ship's IT department, in their infinite wisdom, is mandating an upgrade from Win7 to Win10. That with yet even further constraints. They enforce a list of "approved versions" of "approved applications". And for LVRTE, they are insisting upon 2017, with 2009 being a red light.
      So, then, my query. Is converting an app without the source for a higher LVRTE doable at all? File is attached.
      If it is doable, instructions on how?
      Concentricity-Gage.exe
    • By Dawid
      I'm trying to execute LPR.exe command to print some labels on a printer. However as its normal, problems occur. I could not find answer on any topic conneced with "sytem exec". I already tried all described methods (I think so). That's why I'm asking very kindly for any help.
      When trying to execute or call the LPR.exe from System exec VI, I'm receiving error:
      "'C:\Windows\System32\lpr.exe' is not recognized as an internal or external command, operable program or batch file."
      Generally I would like to call function: "lpr -S 192.168.1.5 -P lp C:\test\do_druku.txt" which works from command window without any problem.
       

      print.vi

    • By mcsean
      I'm setting up some customer error codes, I haven't done it in a while and want to do it properly.In the error code editor dialog box help, I see the following
      It's a bit pedantic but I just want to make sure I'm not off track.  The name of the error codes, this would just be project X for me.  Does that sound right?
      Thanks,
      Seán
    • By Huqs
      Hello Labview Users, 
      I happen to have thousands of csv data file that I work with. The only way I recognize them is putting their characteristics in the file name. Which brings the problem of making the names too long and Microsoft doesn't like to accept long name. So I wanted to build a database for all my files. I am in the preliminary stage of building it ( I have attached the file and some of you may have seen it before). 
      What I want to do is, have all my files in the database with random names and list them based on their characteristics. I want to do that in my application in the place of 'file' box. So that I can click on the file and run it (double-click on the file in application to make them work in active file). based on the parameters listed on the database I want to filter them to find any specific file. How the interface of database should look like is shown blow (Image) . 
      It doesn't have to be a real database, just a directory application. I am trying to make it without the database toolkit.  If anyone can help me out and guide me out or guide me in the right direction then that would be great. Thanks. 

      Multicolumn list box v1.5.vi
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.