LabVIEW Project Providers

cancel
Showing results for 
Search instead for 
Did you mean: 

Feedback request - Packaging and distributing your project provider with VIPM

Eric,

In LabVIEW 2012 we created a pseudopath for the Resource directory.  This allows VIs to link to other files in this directory using <resource>\myfile.vi instead of relative paths as it did prior to 2011.  The end result of this is that you can develop your provider code outside of the LabVIEW directory without linking problems, and therefore build them into a packge with VIPM.

Unfortunately since this was only added in 2012, your source code has to be built in 2012 or later for it to work.

David

0 Kudos
Message 11 of 23
(1,709 Views)

David,

Thanks, that helps explain what is going on. For right now, I am trying to support back to 8.6, so I need a way to make that work.

I did get it working this morning by creating a post-install script to open all the Providers VIs that I call from API, Common, and SCC before performing my own mass compile on our provider VIs. The VIPM mass compile is then redundant, but this does work and does not take prohibitively long. I will need to replicate this mass compile pre-build on the source code, but I had done that manually for now to prove out the post-install script method.

I would also be interested in hearing from those who were successful building a provider installer with VIPM what specifically you did in pre-/post-install to make the install work.

I did find a bug in the VIPM builder that was holding me up for a while (listening VIPM guys?). I would get a librarian error towards the end of the build because my post-install VI path included the characters “\05” which showed up as an unprintable character (ENQ I assume) in the error window. Are you passing the path somewhere as a \ code string? Once I figured this out, I just changed my source code path and it fixed the problem.

Thanks for your help everyone. I am very pleased that this community has been so responsive.

Eric

0 Kudos
Message 12 of 23
(1,709 Views)

So i'm not sure what the problem is as you describe. Was the problem specific to the mass compile during install in VIPM?

0 Kudos
Message 13 of 23
(1,709 Views)

Michael_Aivaliotis wrote:

So i'm not sure what the problem is as you describe. Was the problem specific to the mass compile during install in VIPM?

No, this happened at the end of the build. It looked like the build completed because the package was created and I think I saw "Cleaning up" flash in the status bar, but I get the following error:

There was a problem building Product Name.

Error Details:

Code: 1

Source: Librarian Path Location.vi. File Path: "C:\Temp \Post-Install Custom Action.vi".

What you don't see is that the path is actually "C:\Temp \05\Post-Install Custom Action.vi". You can recreate this error by building a package with a post-install custom action and a folder starting with 05. I assume that starting a folder name with the hex value of any unprintable character would also reproduce the error.

Below is the snippet from the VIPM error log pertaining to that error. Hope this helps.

Eric

=========== START of VIPM Error Message ===========

An internal VIPM Error has occured on: Monday October 22, 2012 at 12:59:53 PM

= Automated Message Start =

Error 1 occurred at Librarian Path Location.vi. File Path: "C:\Temp[ENQ] \Post-Install Custom

Action.vi".

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain

a character not allowed by the OS such as ? or @.

=========================

NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

= Automated Message End =

= User Defined Message Start =

    VI Package Builder Error

= User Defined Message End =

= Error Handler Call Chain Start =

    VIPB_API.BuildAndPackageLibraryFromSpec[Private].vi

= Error Handler Call Chain End =

=========== END of VIPM Error Message ===========

0 Kudos
Message 14 of 23
(1,709 Views)

TCPlomp wrote:

I have an extension to the SCC provider that I install with VIPM.

However there is an issue if the provider is calling a DLL. Since the DLL is locked it cannot be overwritten by VIPM (even if the DLL is of the same version)..

After a failed install I have to restart LabVIEW, then reinstall the provider and then re-enable the SCC provider.

Ton

I have a similar problem as Ton -- the installation of a new package fails with Error 8 when the user attempts to upgrade.

There is a workaround, since the DLL is lazy-loaded (which makes my solution a little less involved than Ton's) -- a fresh restart of LabVIEW allows installation. However this means that the user must restart LabVIEW both before and after installing the package (restart afterward required, since the Project Provider is only reloaded when LV starts).

0 Kudos
Message 15 of 23
(1,709 Views)

Looking at this DLL locking problem: Would it be helpfull if there was an option during the package build step to specify if a LV restart is required (before or after the install)? Then VIPM would honor this during the package install process.

Message 16 of 23
(1,709 Views)

The workaround that would work for ME is the following order:

-VIPM:Select Package to install

-VIPM:Shutdown LabVIEW

-VIPM:Copy files to target location

-VIPM:Restart LabVIEW

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 17 of 23
(1,709 Views)

If your package has a pre-install custom action, then VIPM needs to run LabVIEW to execute that custom action. So the timing of the LV shutdown nees to be just before the copy operation, but after the custom actions. So it would be more like:

-VIPM:Select Package to install

-VIPM:Start the install

-VIPM:Auto-Start LabVIEW

-VIPM:Execute pre-install Custom Actions

-VIPM:Shutdown LabVIEW

-VIPM:Copy files to target location

-VIPM:Start LabVIEW

-VIPM:Execute post-install Custom Actions

0 Kudos
Message 18 of 23
(1,709 Views)

Michael_Aivaliotis wrote:

Looking at this DLL locking problem: Would it be helpfull if there was an option during the package build step to specify if a LV restart is required (before or after the install)? Then VIPM would honor this during the package install process.

<singing> Yes! <\singing>

0 Kudos
Message 19 of 23
(1,709 Views)

Would it be helpfull if there was an option during the package build step to specify if a LV restart is required (before or after the install)?

Yes, I totaly agree that a restart LabVIEW option for package installation is needed.

http://ideas.jki.net/topic/80683-restart-labview-after-installing-packages-with-tools-or-help-menu-e...

This idea refers to the menu entries, but also would benefit provider installation.

0 Kudos
Message 20 of 23
(1,709 Views)