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/
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 😀
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?
I have been getting some hard crashes in my built application and I have some strange feeling (although it's just a guess) that it is related to a combination of using the database toolkit in a pool of workers that are launched by the start async call node. Their job is to sit there and monitor a directory then parse data files and throw their contents at the database through a stored procedure call. All my hardware comms (2 instruments) are using scpi commands through VISA GPIB and TCP so I think the risk that those are causing crashes is relatively low.
Active X inside a bunch of parallel threads seems far more risky, even though as far as I can tell adodb should be thread safe, and each thread manages its own, unshared connection. These crashes are happening ~once a day on multiple test stations. I have sent the crash dumps to NI but am waiting to hear back. Right now I am grasping at straws because when I look at the dump file it's pointing me to function calls in the lvrt dll which does nothing for me.
I am mostly just looking for any debugging suggestions or direction to getting this resolved more efficiently than just disabling code one loop at a time. I'm also curious if anyone has seen something similar. For the time being, I have reduced my number of workers to 1 in case it is a thread safety issue. I have also considered getting rid of that DB toolkit and leveraging .NET, even though I think that is just a wrapper around the same calls. Looking inside the database toolkit VIs alone scares me.
FWIW I am using LabVIEW 2013 in this application.