Jump to content

Jim Kring

JKI Team
  • Content Count

    1,744
  • Joined

  • Last visited

  • Days Won

    43

Jim Kring last won the day on July 20

Jim Kring had the most liked content!

Community Reputation

80 Excellent

6 Followers

About Jim Kring

Recent Profile Visitors

26,615 profile views
  1. We have an official bug ID for this 18825 - VIPM API doesn't handle LabVIEW 2020 We're working on a fix.
  2. VIPM 2020 is available for Mac. https://support.vipm.io/hc/en-us/articles/360045837651-VIPM-2020-1-Release-Notes-Windows-and-Mac-
  3. Hi @kosist. Thanks for reporting this. We've logged a bug [18812] for this issue and will have our team look into it. Regards, Jim
  4. Sometimes there are weird permissions issues in Windows with files on a network drive. I've noticed odd behaviors occasionally, too. I'm glad it's working for you now, and thanks for reporting these issues.
  5. Hi @elmachin. Are you able to choose the option to continue without sign-in? There are some corporate IT environments where the sign in does not work. Also, can you check the C:\ProgramData\JKI\VIPM\error folder for a file with the most recent date in the name and share it? That may help us understand the issue.
  6. Hi there. Hmmm, there are several possibilities. 1) Remove the external package dependency (in VI Package Builder >> Dependencies setting) You can make a package an *internal* dependency in the VI Package Builder (go to the dependencies page and remove it from the list of dependencies, and then VIPM will transparently build those VIs into your distributed package) 2) If the VIs in that library are kept beneath your VI Package Source Folder, then VI Package Builder should build them into your package. You'll want to be sure they get "namespaced" differently (by renaming the lvlib or putting the lvlib inside another lvlib for your tool) so that the library's VIs don't collide with an installed version of that library on the end user's development machine. 3) Also, I see there are newer versions of this tool available and one is available in VIPM. - Tree-API << this is a VI Package, but I don't think it's hosted on vipm.io - Tree Map << this is the newest and *is* available on vipm.io for installation with VIPM Would upgrading to use the Tree Map work for you? Then you could just make this a dependency that your end users will be able to install.
  7. Hi @felipefoz. You can use the VIPM API to query this.
  8. Hi There. I think you may need to also (separately) publish the system package to the repository, too, in order for it to be correctly downloaded/found by repository clients. Please try that, and let me know if that resolves the issues for the clients.
  9. Hi @Rami_Saaidi, We've had another user report a similar issue recently. Have you tried re-running the installer after the error, to see if it works the second time? Also, I think one user said they resolved the issue by installing .NET 4.0 before running the VIPM installer. -Jim
  10. @Ruslan. Thanks for reporting this. Do you know if this also happens in newer versions of LabVIEW, too (e.g. LV 2020)?
  11. I see. Could you change your individual packages (that require none of their VIs are in memory) to require that LabVIEW be closed before installing?
  12. Hi @ranjgith. No, there's no such feature for VI Package Configuration files. Packages, themselves, have such features but not VIPC files. Can you explain a little bit about what you need to accomplish? What's your use case? -Jim
  13. Hi @wolfkil. Thanks for letting us know it worked for you. We're trying hard to keep things working well. Please let us know if you have any more issues.
  14. Hi @Olivier Jourdan. I have no idea why this setting wouldn't work. Can you try it on a super simple project to see if it's reproducible? If you can reproduce it and zip up the sample project, we can take a look.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.