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.

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.

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

Thanks for posting the screenshot. What does the dialog show after you press OK? It should indicate the caller of that missing vi. it’s hard to know for sure if A mass compile of your Source folder would fix the issue. Possibly, yet sometimes the linkages can be crossed up across different projects.

Does the VIPM error dialog state which calling VI is trying to find that missing VI? The dialogue has two parts: one that shows you the missing VIs, and the second that shows you which project source VIs are calling the missing VIs also, often the culprit is a VI on disc that is not actually being used anymore, but it’s broken. The package builder is including it, even though it’s not being called by anyone

I just emailed you some instructions. I did this privately, since the steps involved are tricky and I don't want anyone trying this at home without a safety net.

Hi @Horsechilli I saw this happen recently, too, and it was also in LabVIEW 2017. I'll gather my notes on this to try to help you out. Stay tuned... -Jim

I've started this thread as a discussion point, to foster ideas and maybe come up with something unique, because I completely agree with JKI that user interface design in LabVIEW is dated, restrictive and well overdue an overhaul. Since the conception of NXG (2013) I've been campaigning for user interface design that avoids using absolute pixels, because pixels are irrelevant in this era. A user viewing a LabVIEW front panel on a 1080p 32" monitor, a 1080p 14" laptop or a 1080p 8" device will currently all be shown the exact same user interface, because your LabVIEW window will be 1920x1080 pixels in all three cases. However the actual physical size of each control and indicator varies enormously because for each display the actual pixel real world size decreases as the screen gets smaller. The term PPI is used to represent pixel density, and in this example it varies from 69ppi to 538ppi. This isn't the best example, but we've all seen how websites scale/alter their presentation as the window physical size changes. For example, shutterfly.com on my 1440p mobile in landscape, versus on my 1080p laptop: Despite having more pixels on my phone, the displayed website has less content because the renderer understands that the pixels are much smaller, so to ease my eyes I need enlarged buttons to keep things readable, and also touch friendly - which is another desirable feature. Everything is scaled appropriately based on an understanding of the real world dimensions. Examples of real-world digital pixels are points, or picas, depending on your base units (mm or inches). And this is what I really want. The ability to design a UI in relation to real-world points, with rules that define how the UI will restructure itself for different panel widths. During the NXG development feedback phases I wrote pages on potential approaches, include "controls that are special VIs", where a component of the UI is something similar to an XControl - an active piece of code embedded in a front panel chunk that acts like a LabVIEW control. Without the complexity of XControls, it would be more of a Smart Control, designed with a view to making scalable elements of a UI easy to develop, with programmed behaviours when user interactions occur, and based on points, not pixels. They could work like classes, providing the ability to create a group of similar controls that override inherited behaviours from parent smart controls. I can image creating a colour palette within the abstract parent, and child smart controls for each component of the UI. Change the colours in the parent class and all the controls redraw with the new theme. They would each be an element of a UI, such as a menu banner or hamburger menu system, or simply a button. The interactions to them would likely be through messages, or user events, rather than terminals etc. I've not seen anything yet in LabVIEW that can provide this real-world sizing behaviour, and I don't expect it would be simple to develop (if possible at all), but I wonder if others have similar interests, or have achieved anything along these lines themselves?

OK, we've found and hopefully resolved the issue. The fix will be in the next nightly beta build.

This setting marks that the package can only be installed into the global LabVIEW environment and not a virtual environment. If you want to know more, please sign up for the Dragon beta.

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...

Great idea, Joerg. This is not currently a feature, but it's worth considering, for sure. Your use case sounds valid.

@Jim Kring @Yann Report from my adventures with IT. Short term solution: We found that it was the Cybereason ActiveProbe service that caused the run error. If that service was disabled, VIPM can launched without issue. Long term solution: IT assigned a policy to my machine that disabled some Cybereason monitoring for .NET (they were vague). I was then able to use VIPM while ActiveProbe was running. That's as specific as they were willing to get. Hope this helps!

Main package list.. i noticed there is update available will see how that goes after update. Thanks..

Here was last answer from IT which solved my problem : Maybe our problem is not AV itself but something else… I just put this machine xx.xx.xx.xx under a policy that has only AV enabled.

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

Building a VI package can take quite a while. For our Release Automation Tools, it takes about 20 minutes. Even though we build our packages on the build server now, it would be great to be able to feed back the progress of the build process to the CI system. As an example, the NI Application Builder API offers "progress bar" events, which you can register for and then show the progress details as you see fit: The VI Package Builder shows at least a few pieces of progress information in its status bar. Maybe these could be "routed" back to the VIPM API?

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.

Ah, that's good to hear that IT was able to figure it out. Glad it's working for you now.

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 ☹️

OK, I think we're getting closer to figuring this out. It appears that when VIPM Community is activated the Restart LabVIEW setting is not being applied correctly to the built package settings -- this is a bug. It'll file a bug for this and have our team look into.

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

Thank you @Jim Kring, now it is clear.

Hello @Jim Kring, thank you, actually yes, it is already displayed as "Unpublished" in the "Repository" list. Just, this status is displayed also for toolkits which have never been published - for example, toolkit's development is in progress, and it is just installed locally in order to check how it works. The same happens when it is installed via VIPM which does not have license to publish packages. Or, when there are installed toolkits (like ESF, Dictionary, etc.) downloaded from somewhere, and which have not been published also. But nevermind, and thank you for the idea - it is possible just to sort list by Repository, so Unpublished toolkits will be on top, and thus immediately visible that something is not updated. That is enough in order not to forget to publish the package. P.S. Interesting to see Dragon icon already directly in VIPM

Thank you @Jim Kring, happy to hear that ))

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?

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:

Thank you Jim Kring

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.

Jim, Thank you. Your first answer wouldn't work in my use case as we don't have permission to install VIPM on the internet enabled computer. However, your second answer is exactly what I needed. I need to be able to download the package, burn it to disk, and sneaker-net it to the development (not internet connected) network. I'm off for Thanksgiving but I'll give it a test when I'm back at work. It lets me download a package at home so it looks like it will work for me. Thank you for the quick turn around! --Q

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.

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

Turns out (it seems obvious now...!) I was missing the tdtable from my runtime engine (2019). Fixed as per this knowledge base: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Ru8SAE&l=en-GB Copied over the missing file from a colleague's machine.

You forgot one important thing: an asterisk "*" in the Machine Access List. Also, very important, verify your TCP port address in the VIPM (Options >> LabVIEW tab). If you have multiple LabVIEW installations make sure each VI Server have unique ports. Good Luck! Relativity1

I'd love to see these three License-related improvements to VIPM: 1) First, a main window column showing the package license, so it becomes very easy to see whether a package is open source, freeware, proprietary/custom, or something else. It'd be nice if the column title could be clicked to sort sort packages by license type: 2) To complement this, a change to the filter box with options to filter by license type, or maybe a second filtering box for this specific purpose. This would further help those searching for packages to focus on finding one they can afford and actually use for new open source projects, which is particularly relevant now that LabVIEW Community Edition is going to bring in lots of new users who definitely aren't going to purchase proprietary add-ons: 3) Finally, it be interesting for the VIPM Community Edition, specifically, to only allow the creation of open source packages, what would create a clear barrier to those who might be thinking of using VIPM Community Edition for proprietary package creation. This could be done by changing the "License Agreement Name" (in VIMP Community Edition only) from a free form text field to a combo box listing only OSI-Approved licenses' SPDX codes, therefore making the intended purpose extremely clear. The default option could be BSD, with other popular OSI-Approved licenses listed below it, and less common ones (if requested) on a submenu: What do you think? 😊 PS: Re-posted with changes from the original in the VIPM 2020 Beta board.