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).
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
Class.lvlib:D69AB3997B80ACD75689430E3922612C->OGPM Class.lvlib:OGPM Init.vi->VIPM Splash.vi
LabVIEW: File permission error. You do not have the correct permissions for the file.
DMA hardware error detected.
= Automated Message End =
= User Defined Message Start =
Error(s) Generated in Splash Window
= User Defined Message End =
= Error Handler Call Chain Start =
= 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?
Since stumbling across the G Package Manager (GPM) while looking through this discussion on package managing I can't shake the idea that is is precisely the system that I would like to implement throughout the rest of the developers in my team for working on LabVIEW projects across multiple sites and with parallel upgrades to code to handle ongoing facility updates.
However as I am sure is the case with many companies, we need to maintain our data locally for corporate reasons. There was a reference to being able to have a local repository in the initial NI Week presentation by Derek but since then I have not seen any other reference to it and there is limited information available about the processes. Has anyone got any experience with the operation of GPM for internal use, or even any use with GPM in general? From looking through the Lava and NI forums, doesn't seem like many people have picked it up or at least haven't posted anything about their experiences with it.
Manufacturing a satellite or a simple pen require to test the quality of the product before delivery to the customer.
LabVIEW is widely used for that purpose. Since 20 years of LabVIEW development I saw numerous test framework. I was wondering if people where interested to work in a collective and open source test framework.
Per example the following feature can be included:
HAL (hardware abstraction layer)
Database to record test results with the data viewer (PostgreSQL)
Image analysis (open CV) + bar code reader
User access level
Jig identification to prevent user error (testing the wrong product with the wrong jig/test sequence)
and so on....
By Rolf Kalbermatter
It's nothing to fancy. I added a few things to the UI to support more features and in preparation of adding the VI renamining/relinking step that was done seperately in the OpenG DEAB tool before calling the OpenG package builder. But I never got around to really add the deab part into the package builder. It's kind of extra difficult as the DEAB compononent doesn't currently support newer features like lvclass and lvlib at all and of course no mallable VIs etc.
I can post what I have somewhere, but don't get to excited.