Jump to content

Jim Kring

JKI Team
  • Content Count

    1,844
  • Joined

  • Last visited

  • Days Won

    51

Jim Kring last won the day on January 7

Jim Kring had the most liked content!

Community Reputation

95 Excellent

3 Followers

About Jim Kring

Recent Profile Visitors

27,155 profile views
  1. Hi James. I'm sorry this still isn't working well for you. Thanks for reaching out to let us know. This has been a wild couple of months for everyone, so thank you for your patience. Understanding and fixing these issues is important, and I'll do my best to help resolve the issues. My understanding of your goals/issues are the following: --- Goals To be able to use VIPM API in a CI context to achieve the following: A ) Create a package configuration for a project A.i) Scan a Project for Dependencies A.ii) Create a VIPC file of the found dependencies
  2. Hi Ivan. Yes, VIPM checks the package integrity. I think it must be an issue that VIPM Community is not running the post-build custom actions. I'll have our team look into this as well. I'll ping you offline about how we can get a work-around for you.
  3. 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.
  4. Also, it's worth noting that post-build custom actions require VIPM Pro or Community, too, and won't work in VIPM Free.
  5. Hi @kosist. I think I figured it out. The options on the "Advanced LabVIEW Requirements" area only supported in VIPM Pro. My guess is that this .vipb was created with VIPM Pro, but the copy of VIPM you're using is not activated as VIPM Pro. VIPM will still build the package if you have VIPM Free activated, but it resets those flags to FALSE during the build. Try toggling the checkbox for that setting to FALSE then TRUE and you'll probably see this dialog stating that it's a VIPM Pro (and Community/Non-Commercial) feature: Hope that helps. -Jim
  6. Thanks for that extra info @kosist. We're going to look into this much deeper, but I wanted to give you a quick response with a possible work-around. If you create a post-build custom action (Note: This requires VIPM Pro or VIPM Community, and won't work with VIPM Free) you can unpack the package (meaning: unzip the .vip file to a folder), modify the spec file (set the "restart labview..." key to TRUE), and then repack the package (zip it back up into a .vip file). Please let me know if this makes sense or if you need help. Here's a screenshot of how you would call this in your
  7. Hi @kosist. Thanks for reporting this. Can you explain a little more about what you're seeing in 2020.3? You said, "when I install it - project is restarted" and that part about the project confused me. Are you saying that when you install the package only the project gets restarted (but LabVIEW is not restarted)? If you can, please be sure to report: Steps to reproduce (is there a public package that reproduces this issue?) What you expected to see. What you saw/observed instead. Thanks, Also, a quick thing you could check is to see if the
  8. I’m glad to hear that this fixed the issue. Yes, ideally it would work a little bit smarter/better at refreshing itself automatically.
  9. "Types and Defaults" is the LabVIEW Data type that you want to populate with the JSON data wired in. Please take a look at the examples.
  10. Hi @RochelleS Yes, users have reported some issues with NIPM and how it tries to install VIPM. We recommend users install VIPM using JKI's installers and not NI's. A few things: 0) Can you check the "C:\ProgramData\JKI\VIPM\error" folder to see if there's an error log file with today's date on it? Can you attach that file here, so we can take a loot? 1) Regarding the connection to the NI LabVIEW Tools Network, can you try again (press the "Refresh" button) and confirm whether it's working? I just tested an it's working OK for me. 2) Which version of VIPM are you using
  11. Hi Anthony, There was an issue in older LabVIEW versions (~LV8.x) where it had to save class Dynamic Dispatch methods into separate folders. In newer LabVIEW versions, there's an option to do the same thing. Perhaps that option is set to TRUE in your build settings. Try setting it to FALSE and see if it fixes the issue.
  12. 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.
  13. 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.
  14. Hi Laurent, Can you look in your error log folder to see if there's anything helpful in there? C:\ProgramData\JKI\VIPM\error Thanks for your patience and help debugging this. -Jim
  15. Hi @kosist. I agree that it's important to know if a package is not published. Right now, I think you can tell by looking at the "Repository" column and it should say "Unpublished" (as shown in the screenshot below). Is there somewhere else you'd like to see this "Unpublished" status more prominently?
×
×
  • Create New...

Important Information

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