Search the Community

Hi, Over night something changed on my windows 10 build server and I can now no longer open VIPM. It just shows the splash screen and then closes again. Here's the log file: =========== START of VIPM 2018.0.0 (build 2025) Error Message =========== An internal VIPM 2018.0.0 (build 2025) Error has occured on: Tuesday August 20, 2019 at 03:19:48 PM = Automated Message Start = Error 8 occurred at Open/Create/Replace File in NI_LVConfig.lvlib:Parse Config to Queue.vi->NI_LVConfig.lvlib:Load.vi->NI_LVConfig.lvlib:Open Config Data (compatibility).vi->DDEFA056211BA4DA4D215C322E067D90->621BFCD461979D3C7127139A69154E03->762BBE85A007 171D5A65B48289D23361->46803A2448FAC5F85BFF8F5C199E9C6F->OGPM Class.lvlib:7D7C5CD8C5D361C01081DF5613237E15->OGPM Class.lvlib:D69AB3997B80ACD75689430E3922612C->OGPM Class.lvlib:OGPM Init.vi->VIPM Splash.vi Possible reason(s): LabVIEW: File permission error. You do not have the correct permissions for the file. ========================= DMA hardware error detected. C:\ProgramData\JKI\VIPM\cache\ngene_lib_deepltk_fpga_addon-1.0.0.45.spec = Automated Message End = = User Defined Message Start = Error(s) Generated in Splash Window = User Defined Message End = = Error Handler Call Chain Start = VIPM Splash.vi = Error Handler Call Chain End = =========== END of VIPM 2018.0.0 (build 2025) Error Message =========== Any idea where the files are that it doesn't have the right permissions for?

(message first posted on jki forum, but traffic there seems very low...) I get this error when building my package with VIPM, previously the package was building fine. It always took a long time (~15 to 20 minutes) to build this package because it's quite large (~78 classes, 1200+ VIs). Since the last successful build I've only added some methods in the classes. Mass compiling the folder containing the source code doesn't report any issue. Error 66 is descibed in LabVIEW as 'The network connection was closed by the peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools>>Options>>VI Server on the server side.' I've check this and other (smaller) package still build fine. Sources are in LV 2019 32 bit I'm using the latest version of VIPM 2021.1 b2754 Any suggestions?

I’m a big fan of JKI VIPM, and I’ve been usen Source code control with labview for some years (First with mercurial and now with GIT). Following the good practices with SCC and LabVIEW I always check the separate compiled code from vi to avoid unwanted changes on Vis. In the other hand I’ve read that the performance of labview is better with the compiled code in the VI. Besides that the labview IDE does not allow you clear compiled cache of some of your vis, you have to delete all the compiled cache…When I have some compilation errors and I delete the compiled cache It takes a lot of time to open again the project… My question is… VIPM allows you to execute some code after the package installation (post-installation-action). Could it be a good idea to unmark the separate compiled code programmatically on each installed file (vi, ctl, class, lvlib… )?. Maybe I have to make this question in VIPM forums also, to check when is executed that post-installation-action, if it is executed before or after the masscompiling Thanks!!

Hello everybody! Wondering how many people have tried the new vipm.io site. We have added a ton of features to make it easy to Discover LabVIEW Tools and there are some cool ones coming soon. Check it out and let me know what you think 😀 Javier

VIPM.io now allows you to post LabVIEW Resources, Ideas, and Tools. For example, you could post a link to a video tutorial or blog article about a package. You can also post ideas, like feature requests or new tools. Best of all, package developers are notified when you post your ideas and resources, and you can comment and discuss posts with the community. Take a look at this video to learn more: https://www.vipm.io/posts/664960df-f111-4e13-989a-24be8207182d/

I am using the newest version (2020.1) of VIPM, but I had this same issue with the release of 2020. For two of the packages that I have created for internal repos, VIPM has decided that I need a System Package. The posts I have seem from JKI indicate that this is a sub-package that is used internally to the main package, and should be automatically included. However, after I am seeing issues on any PC other than the PC where the package was built. Is there a setting I am missing? Showing the (System) package as a dependency: Package Configuration in the VI Package Configuration Editor Package installed, on the PC where the package was initially created (no issues, no exclamation mark) Package when installed on another PC (NOTICE: the System Package name has changed and there is a red exclamation mark, but there are no errors shown on install of the package).

This is an offshoot of https://lavag.org/topic/19414-can-i-save-as-a-vipb-file-in-vipm-and-keep-the-old-palette-if-i-change-the-source-directory/. That thread discusses hand-modifying the XML data in a *.vipb file, which Jim Kring himself seems to accept as a viable solution in some cases. However, when I try that, VIPM says, "VI Package Builder was unable to open the build spec due to an error." I initially thought this was new behaviour introduced in VIPM 2016, but downgrading to VIPM 2014 SP2 didn't change anything. I'm now unable to downgrade any further, as my PC is convinced that 2014 SP2 is still installed (even though it's not...) Could someone kindly try the attached *.vipb file and see if it opens? It's a bare minimum default file, with only a description summary added. I've hand-modified the summary from "Lorem ipsum" to "Larem ipsum" and now VIPM refuses to open it. Thanks! Dummy.vipb

This maybe has been ask/answered/discuss before but here it is. Is there any VIPM alternative out there? If not, It will be very interesting to start a discussion whether an open source version is feasible and how many members in the community are willing to work on it. I know JKI has a great product already but seems like development has come to halt wrt VIPM. Any comments?

Hi all, I have been trying to use VIPM to distribute drivers that rely on a .NET framework that is unsigned (i.e not in the global assembly cache). My issue is that after the package is installed, none of the VIs will work because LabVIEW cannot locate the .net assembly. However, if I launch labview by opening the library VIPM installed, all of the VIs will work, and LabVIEW is able to locate the the .Net framework and it appears in the main application instance. I need to be able to use the installed vis all the time, not just when LabVIEW is launched in this particular way. Here is a link to all the all the files I used: https://www.dropbox.com/sh/yjt2a0t8msxhgfn/AAC4VVW-hPawwXtGMrZ6wuIra?dl=0 Here are the steps I went through: 1) We put all the .NET dlls and the LabVIEW.exe.config file in the Labview directory. 2) We installed the package on our computer. 3)We closed everything and relaunched Labview from the start menu. Then accessed the BioRobotics/Vicon palette. 4)We placed the Get Ref subVI on the block diagram, opened it up, and ran it it. 5) We got the following error: We also get a similar error for any VI that uses a method associated with the .NET dll. 6) However, if we again start with everything closed and launch Labview by clicking on the VICON.lvlib located in the vi.lib 7) Then repeat steps 3 and 4. We do not get any errors in the VIs on the palette, and the .Net assembly loads fine. We can even close the library and everything still works. Somehow opening the library first makes LabVIEW know to load the ViconDataStreamSDK_DotNet assembly when using functions on the Vicon palette. If anyone does attempt to build a new package, it is worth noting that I included the dlls in the source files, and in the same folder as the vipb: Thanks! Callan

Let me start with some context We have to differentiate from a Production environment (to produce data) and Development environment (to develop test and debugging). Our code (very simplified) is organized in this way - Tests (Actual vi that will produce results) - System files (support vi, drivers, common functions etc.) Both are under source control We have decided to make VIPM's (residing in vi.lib) for all System files and leave the Tests files where they are (random folder under source control). This means the all the vi's inside Tests will have links to the System Files (inside vi.lib now) and that works pretty well for the Production Environment, but when we want to use the Tests in the development environment (Tests and System Files in a random folder) we need to re-link all the Tests to point to the local files and not the System Files inside vi.lib. The question is: Is there any way to manually update the references of the Tests so we can choose from where we want to get the System Files?

Does anyone have any ideas as to why I would be getting the following message while trying to install the OpenG Toolkit through VIPM? I'm using LabVIEW 2014 SP1 (32-bit) and Windows 7 Enterprise SP1 (64-bit)

I tried to install one of my packages using VI Package Manager 2013 and was surprised to see the error message "This package is not compatible with any LabVIEW version on this computer." The package is supposed to be compatible with any LabVIEW version >= 8.6 and I have 2013 installed. After some Googling, I found this: http://digital.ni.com/public.nsf/allkb/9A84C532AB9268BD86257CEF00794E70 It turns out that I had compiled the package using VIPM 2014 and thus it is not compatible with VIPM 2013. I suppose that this makes sense but the error message shown in VI package manager is very misleading. So in conclusion... Keep VIPM up to date otherwise you might get misleading error messages when trying to install new packages.

We develop a number of test systems for use in China at our production facility and when we ship it for whichever engineer is on site at the time to debug. Now because the PXI racks that are used may well have been bought in China we can not guarantee that the PXI rack will all the required software and drivers so we make sure that any software or drivers are included in the package we send as as access to the internet can be tricky or just so slow as to be unusable. The question is that we a number of components that we install from the VIPM but that is not allays possible via the internet in China, is there a way to download the installer files and then use them locally on the PXI rack on site. My thanks in advance.