Leaderboard

Some advanced users are asking for support to install VIPM for Windows onto a Docker container. This would allow creating fully automated build processes that spin up virtual machines that have LabVIEW and VIPM installed on them, so that VI Packages can be created automatically.

Found a solution : https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Ru8SAE&l=fr-FR Luckily, my colleague has the same laptop with similar NI softs installed so he sent me his tdtable.tdr file and then it all works fine again.

As an update, I have been applying the file directly to the unicodeStringtoASCIIJKI_Simple_Localization.vi. Arabic gets translated to ASCII correctly as shown in the screenshots. Maybe a kernel32.dll function needs to be updated. Hopefully I find something and I will post it on this thread.

With VIPM 2020.3 (build 2540) and VIPM API 2020.0.2.73, it's not possible to supply a major number of 0 via the API, the API returns an error 42: Seeing as we also build projects that are in a pre-v1.0 state, I don't see a reason to not allow the major build number to be 0. I was actually tempted to file a bug report... 😉

Release notes are written in the build specification. When, for example, developer realizes that some note should be added - package has to be rebuilt. But sometimes build of the package could take a lot of time (for example, build of our DBT toolkit takes approx. 1 hour with licensing, password protecting and further build). It would be great if there will be option to update just release notes, or another information which should not be compiled (authors list, etc.). That would help to save some time... But on the other side, developer should pay some more attention to build configuration before actually building the toolkit...

I think I see what you're saying -- if an older version of the package is published in a repository, but the installed/latest (i.e. displayed) version is not published, it would be helpful to know that it's a development version that's not yet "officially" published to the repo. This is different, perhaps, than a package where no versions are published. Idea: Maybe VIPM should display "Local" as the Repository name if no versions of the package are published. This deserves some more thought, for sure. I'm glad you have a workable solution, for now. Thanks for sharing these ideas. P.S. Yes, there have been some dragon signings lately

Currently at our company we are building internal toolkits which we use for projects, but do not put it to LVTN. Toolkits are published via OneDrive, everyone has mapped same local folder as repository in VI Package Manager. Different toolkits are handled by different developers. And sometimes there is a situation, when new version of toolkit is built, installed locally and tested, but it is not published to our local repository. It would be nice (I understand that on the other hand it is not such a common case) to have it in such a way, that: - developer installs new version of the toolkit; - VIPM detects that actually such a toolkit (based on name and version) has been previously installed from a locally configured (custom) repository; - if so, VIPM checks that this toolkit has not yet been published to that local repository; - it will display some icon similar to those which are in "VIPM Legend" list. In that case, developer would see that he has some toolkit which is not published - so either he will publish it, or leave it as it is. Also there could be warning similar to the one which is shown when VIPM is opened, and there are updates for the toolkit. And, when toolkit is published - icon is set as usually.

Just the idea - not sure whether it is possible to implement. There are some packages, which are used as dependencies in other packages. And, we can find dependencies of the packages by sending package to configuration; but we can not find packages which are dependent on some particular packages. If we could do something like right click on the package in the list -> Find dependent packages, and it would show us list of packages (ideally even not installed) which use that package as dependency, that could be sometimes useful. Now, for example, we use some package as dependency, and I was wondering whether there are some other toolkits which use it as dependency. But, there is no way to find it out - unless to check information for each of the package or trying to install them. Thank you very much, Sincerely, Ivan.

Hi, I would like to ask for a help with the following issue: I am trying to distribute VIP file with some dependencies, which are not published on VIPM. Hence, I added them to VIPC and would like to distribute this VIPC with VIP file. Is this somehow possible?

Howdy V, I have not previously done exactly what you are asking, but have done some similar tasks. We use VIPM Pro and a local repository to distribute packages not found in the public repositories; not only our internally developed packages. First, using VI Package Builder's Destinations and Source File Settings pages you can easily include the file and specify where it is installed. Second, using the Custom Actions you can specify a VI to run Before or After the package install. Use the Generate VI button to create a template VI and save into your package project; I create a Custom Actions folder when needed. Edit this template VI to launch your package configuration file; I typically rename so I know its purpose without viewing. You can use the System Exec.vi and create a constant for the command line that will include the exact install path to the .vipc file location. And, if you're not comfortable with command lines, using Open a Document on Disk.vi is another option. I'm uncertain of whether VIPM will have any issues launching a package configuration before or after a package install. However, testing this will be simple and you can include instructions for the end-users if the automation is unsuccessful. NOTE: My suggestions are based upon a Windows OS install and will need modifications for MAC or Linux Best wishes with finding a solution. James

Currently you have two options for Package Dependency version constraints: >= or == I propose VIPM should use or allow Semantic versioning. That way, if a dependency package has a breaking change, the dependent package can know that it is not compatible with the updated version. This is a big missing piece to VIPM's dependency management, since it currently assumes that a package will forever be able to support future versions of all dependencies, which simply is not the case in real life, as breaking changes do happen from time to time. Allowing for semantic versioning will help identify and prevent breaking code.

One more thing... Be sure to set up Basic Auth (username/password) protection (or limit access via VPN as you mentioned) if you’re going to let other people know your repository URL.

Hi there. This should be fixed in build 2746 -- I just tried to build the LabVIEW-Composition library and it seems to work. You can get this latest build via check for updates in VIPM or here: resources.jki.net/en/vipm-2021-beta-download

I'm getting an error "This package is not compatible with any LabVIEW version on this computer" but I'm fairly confident it should work. Is there a way to force it to install or edit the package?

Hi Ivan, This should be fixed in VIPM 2021 beta. -Jim

We're excited to announce the VIPM 2021 beta! You can Download VIPM 2021 Beta Software Here. Note: If you are a JKI Dragon Beta Tester, installing VIPM 2021 beta will remove JKI Dragon. Please do not install VIPM 2021 beta on the same machine on which you wish to continue testing JKI Dragon. What's New: Supports LabVIEW 2021 beta Main UI layout and usability improvements [build 2732] Fix - Installing packages with deep recursion (e.g. A>B>C>A) was getting stuck and hanging VIPM (e.g. SQLite toolkit). This has been fixed. [build 2732] Fix - Detection of project LabVIEW version was not working well if there were no VIs in project. This has been fixed and the LabVIEW version will be read from the .lvproj file. [build 2732] Fix - Missing Friend Classes No Longer Cause Package Build Errors - The package builder was raising a dependency missing error if a friend class could not be found. However, friends are not actually required. Now they don't cause a missing dependencies error. [build 2732] Fix - Improved "Please Wait" Dialog - Fixed text cut off in the Please Wait Dialog [build 2732] Fix - Community Edition was not setting the "Restart LabVIEW After Install" flag in built packages (and other Pro features that are available to Community Edition such as pre- and post-build custom actions) And more...

User Stories: As a user of VI Package Manager on a system that is not connected to the internet, I want to output a list of dependencies for a package so I can go download them. As a developer I would like to get a list of packages and dependencies to add to my software's documentation.

Hello, Although I already have LabVIEW runtime 2015 and 2018 on Ubuntu 20.04, the VIPM is always unable to find it. I tried multiple solutions but failed to make it work. Is there any tutorial to illustrate how to install on Ubuntu 20.04 ? LabVIEW 2018 is already installed but VIPM is the issue I hope someone could help me with. I followed this tutorial to allow installation of LabVIEW 2015 runtime.

Great question! They have to have a VIPM.io user account and have their gitlab/github usernames added in their VIPM.io profile.

This is a separate issue. The file passing as "UTF-8 without signature" gets recognized as ASCII but still works for Chinese and Russian, not for Arabic.

Hello, Updating VIPM recently, I noticed strange caracters in update descripton (french OS). See below : I don't know if I'm the only one to get this, it's a minor concern, but I wanted to let you know (may it have other impact, perhaps on functionnalities ?) Regards,

Hello, I am wondering if I could get an offline downloader for a few packages. The DCAF CVT, NI CVT, and the DCAF Tag Editor. Thanks, Zachary Heilman

Hey JKI team, is it possible to programmatically update an existing .vipc (or, alternatively, create a new one) with a given .vip file? Our use is case is the following: After building a .vip automatically, we'd like to install it to the very system it was built on automatically. Seeing as we already have a tool to apply .vipc files through the VIPM API, and as we could use it "as-is" for this, we'd prefer to install the .vip this way. Thanks for the great tool, Jörg

Jim, as always, your elaboration is spot on. Here's a screenshot of what our tools do: So other than the fact that we write all the build numbers in one go (the whole cluster), it's what you described above. Thanks for taking the suggestion into consideration.

For keeping track of used packages for our projects we'd like to put a list of used packages to our measuring data. That way we could later on see if a specific problem we encounter with our measurements might be due to the used packages. Is there an easy way for this? The best way I can think of right now is saving the names of installed packages out of VIPMs program data folder.

How to use VI Package Configurations (VIPC) – VIPM

Cross posting here for visibility: Building a basic plugin-based application with HAL using JKI SMO, MGI Solution Explorer, and LabVIEW 2020 interfaces - NI Community Happy to answer any questions about the design process or application. Thanks for checking it out! -Nate

I was able to reproduce the issue with the help of a colleague who has an RT Target. I've written up some info about this issue here: https://lavag.org/topic/21753-1d-array-to-string-not-compiling-correctly/ OpenG String v4.1.1.16 should fix this issue (although it's simply working around the LabVIEW compilation bug, which could potentially be causing other issues) I'm going to work to report this to NI, since we can reproduce the issue.

Hi @Jim Kring That worked😃. I had already gotten around the issue by uninstalling VIPM from Programs and Featuresafter having uninstalled it from NIPM.But then as soon as VIPM was reinstalled and updated again from its automatic update feature the issue in NIPM was back. As I suspected...The folder you sent was accepted as a source though so with that it is possible to do a repair without everything halting on the VIPM error. PS. NIPM is really terrible (compared to VIPM e.g.); From NIPM you cannot even repair VIPM without having to repair almost every component there is of LabVIEW ☹️

This was on a machine with only one version of LabVIEW/RIO ever installed on it - 2020.

Hello @Jim Kring, sorry for the confusion, have no idea why I've written like that... What I meant - is that LabVIEW is not restarted after toolkit is installed. I'll update original post, sorry for that. I've checked spec file as you've suggested, and really there is set "FALSE" flag for LV restarting. Let me show the screenshot of toolkit's configuration, and resulting flags in spec file. Let me also attach dummy package which reproduces the issue. Thank you very much for your help! Restart Issue Toolkit.zip

What is the format for the "Types and Defaults" input?

Thank you @Jim Kring, now it is clear.

If user has claimed toolkits on vipm.io, there is visible button "Release New Version" at the toolkit's home page. What does it actually do? Does it allow to immediately publish the updated version of the toolkit, or it sends it for the review to NI? Because now in order to do update of the toolkit we could also send it via special form to NI, they do some brief review, and then publish updates. Does "Release New Version" do the same thing? Or, it depends on the type of repository where the toolkit is hosted - like, if it is hosted at LabVIEW Tools Network repository then we need to send it to NI, if it is some open source toolkit then we could publish it directly? Thanks a lot in advance!

That button/form is for publishing open source packages to the VIPM community repository. Some of the packages on VIPM.io are hosted on the NI tools network repository. You’re right that those buttons should probably be disabled for commercial packages hosted on the NI tools network.

I'm not sure whether this place is proper for this idea, but as vipm.io directly relates to VIPM itself, let me write it here. The point is that now toolkit could contain some links in the description. It would be nice to open them in new tab, and not in the current. This is small detail, but it actually makes users leave vipm.io while browsing some toolkit's homepage, or something. Of course, there are many ways of how to open link in new tab, but I guess it would be nicer that this would be the default action on simple left-click.

Hi Jim, Trying Help >> Check for VIPM Updates didn't work but I was able to get the new build from the link you provided. Thanks again for helping me out, Greg

With the latest VIPM update, VIPM opens whenever I start LabVIEW 2019. Is this really necessary? How do I stop this annoyance?

I understand and I don't mind helping improve great products like yours. When I started the day yesterday, I opened LV2020 to work on one project. Upon completion, I closed LV2020. A few hours later, I had to work on another project that used LV2019. That's when VIPM opened and I closed immediately closed it. Finished my work in LV2019 and closed it. Later I had to open it again and VIPM opened along with it again. This morning during our initial messages. I opened LV2019 to make sure I was correct in my replies. I then close it and opened LV2020. That's when I noticed no VIPM. Closed LV2020, opened LV2019, and ... TA-DA ... VIPM. Hope this helps.

It appears that in the localizer tool kit the boolean tags are reversed. That is when setting Label.False text it changes the true text for the boolean. { "Key": "Front Disengaged.False", "Phrases": [ "FRONT DISENGAGED", "frente desenganchado", "" ] }, give this result:

hi @Jim Kring, I've updated to the latest version, and my manager purchased a Professional License for me yesterday evening... but this is still not working. I see that the update has locked out the BD of the VIs - so I guess that was an oversight in your last package release. I can't see anything useful now for debugging now, all I'm getting is a hang. What is wrong with my attempt please? (I'm trying to use the API to populate (and create) a VIPC file based on a project name and I looks like it should be easy.) Unless it's something to do with the service keep crashing? so I can't restart every time I close it. I have to go to taskmanager and kill all VIPM things in order to be able to launch the packager manager from the shortcut again? Cheers James VIPM test - Questions.vi

Hi again, Ivan. I went ahead and created a new Knowledge Base entry for this issue, since many others have experienced this error message: Error 1357 during a package build (File Already Exists) Let me know if that makes sense and/or if I missed anything (other possible workarounds or made any misstatements in the recommended workarounds).

Hi Ivan, You're right: Error 1357 during a package build generally occurs when two VIs of the same filename (but in different lvclass'es or lvlib's) are targeted into the same folder during the build. Fortunately, if the classes/libs (with the same-named method VIs) are stored underneath your VI Package's source folder then you can create a custom destination folder for each of them (and target each lvclass/lvlib with it's own specific destination folder). So, maybe you could move the Tree API into your project source folder. Then, you can have more subtle control over choosing specific destinations for each of its classes. I see that the Tree API is distributed as both a VIP and a ZIP file. Maybe you could just extract the zip into your project folder. Also, you might want to rename the root level Tree API.lvlib to something like "TREE API__MYPROJECT.lvlib" so that there will not be a name collision if the packaged version of the Tree API is also installed. Also, I see that there's a newer Tree Map library which *is* published in VIPM. I'm not sure what it would take (or whether it's possible) to upgrade from the Tree API to the Tree Map -- I haven't used either of those libraries yet. Yet, maybe that's another option. Note: this approach with custom destinations will not work for internalized package dependencies, since package dependencies are installed underneath the LabVIEW folder and only files saved under the project source folder are shown in the source file settings view in the VI package builder. Said differently: files located under the <LabVIEW> folder cannot be targeted to a custom destination -- it only works for files stored under the VI Package's source folder. The solution then, is to move those dependencies into the project source folder, as described above. Hope one of those possibilities works for you and thanks for the feedback. You're right that it would be great if there was VI name collision detection in the package builder and it could save the colliding files into different folders automatically.

How can I download a package off of VIPM.io so that I can transfer it to a non networked computer for install? I can’t find a way to download it. It just wants to invoke the VIPM application to do the install. I’m downloading on a computer that doesn’t and can’t have the VIPM application installed.

You're welcome and I'm glad we were able to find and fix a bug in VIPM. BTW, I had a typo in my response to you. I meant to say "I think they changed it so that you can no longer serve static sites/files over HTTP." Yes, some users have found success in having DropBox/Google Drive/Box.com/OneDrive replicate the repository locally as a network hard drive or folder, and then have each VIPM client reference it as a local repository. Let me know how that works for you.

Hi @kosist Thanks for sharing this question and feedback. At one point this worked with Dropbox, but I think they changed it so that you can no longer serve static sites/files over HTTP. I'm not sure about OneDrive. Basically, you'll need something that can host all the repository files as a static website. Regarding the issue where VIPM changes URL to lower case letters: There's actually a work-around for this. You can add the URL and then fix it in the VIPM settings INI file, as described here: [18866] Package Repository URL is coerced to lowercase when adding (should preserve case when adding) Please let me know if you have any other questions about this or other ideas. Thanks, -Jim

@Sam Taggart, @StefanLemmens. We just published a new build of the VIPM API which should address this issue. https://www.vipm.io/package/jki_lib_vipm_api/#2020.0.0.65 2020.0.0.65 (Nov 17, 2020) This release adds support for VIPM 2020 (including Community Edition) and LabVIEW 2020, and also adds a few new features, changes and fixes: - [NEW] VIPM 2020 and Community Edition support (Community Edition can use API calls, just like Pro) - [NEW] LabVIEW 2020 support (fixes an issue where passing version 20.0 was failing a version check) - [CHANGE] Now compatible with LabVIEW 2013 and greater on Windows (was 2009 previously). - [NEW] API VI "Check is VIPM Running" will check if VIPM app (process) is running - [NEW] API VI "Open VIPM" will open the VIPM Main UI (and launch VIPM if needed) - [CHANGE] "Exit VIPM.vi" to run synchronously. It has a new "Timeout in seconds (0: no timeout)" input and waits on VIPM process to be fully exited. Also, has a "synchronous? (T)" input which can be set to FALSE if asynchronous behavior is desired. - [CHANGE] Separated compiled code from source code (All VIs) - [FIX] API will now return an error if VIPM process terminates (crashes) before a timeout occurs when calling a synchronous command.

Great question. Short answer: no, you don't have to pay anything to use them in your projects. Long answer: Please see the license info here: https://resources.jki.net/jki-flat-ui-controls-toolkit

Hello LV Gurus, I have used JSM since release 1.0 (circa LV 2011). I understand the sub-diagram label feature was not yet implemented. Is there a reason why the JSM 2018 still not using sub-diagram labels (like below) since that has been standard in LV for many many years. Thanks guys! Sub-Diagram Labels enabled (lots of manual editing just to clean up those comments) Sub-Diagram Labels not enabled (current 2018 version):

It would be useful for quickly building palettes if the file dialog that appears after selecting the Add Control or VI option allowed multiple files to be selected. This would be especially useful if a folder contains a mix of CTLs and VIs, or a mix of items that are wanted on the palette and ones that are not.