Jump to content

Jim Kring

JKI Team
  • Posts

    2,199
  • Joined

  • Last visited

  • Days Won

    105

Everything posted by Jim Kring

  1. That's strange. I wonder if there's some kind of permission issue. Does "Everyone" have Full Control on the "C:\ProgramData\JKI\VIPM" folder?
  2. Hi Peter, Can you try exiting VIPM, deleting the cache folder, and then restarting? C:\ProgramData\JKI\VIPM\cache
  3. Hi @kosist Thanks for that information. Can you tell me more about the exact steps you might have used when the error showed up? First you said "Install ESF toolkit globally" then "Try to install ESF toolkit from Dragon window, by right-click on the toolkit in the list". What did you right-click on to try install it into the virtual environment? Did you add it to a VI Package Configuration, uninstall globally, then try to install it locally? Any specific steps would be very helpful. Thanks!
  4. yes, that's right -- the .dragon file can be placed in the very top level folder of the project source code and the .lvproj, .vipc, and .vipb files can be kept in subdirectories. There's a new feature in the latest build that helps with this, too. When you're opening a new project for the first time, Dragon will search in subfolders (up to two levels deep) for these .lvproj, .vipc, and .vipb files when it auto-populates the dragon project configuration for the first time.
  5. Good catch! I agree that a missing .vipc file should not cause Resources package lists to be empty. We'll fix that...
  6. That's a really good point -- a user probably doesn't feel 100% comfortable agreeing to installing all the packages until they know what packages will be installed.
  7. Hmmm... which "list" are you referring to? The main VIPM package list or the Dragon project's Resources tree/list of packages? Also, can you look in the "C:\ProgramData\JKI\VIPM\error" folder to see if there's any error messages logged?
  8. Hi @kosist. Thanks for sharing your observations about this. Here's what's going on. Currently, there is not much validation of the LabVIEW Version requirement. Eventually, there will be more validation and user feedback. A.) For projects that use a virtual environment, the LabVIEW version in the virtual environment is used for determining which LabVIEW version to use for editing the project. B.) For projects without a virtual environment, the LabVIEW Version of the dragon project configuration is used for determining which LabVIEW version to use for editing the project. C.) Also, when creating a new virtual environment, the LabVIEW Version of the dragon project configuration is used for determining which LabVIEW version to use for creating the virtual environment (goto "A"). As such, if a project has a virtual environment, then the LabVIEW Version in the configuration is somewhat ignored, currently. In the future, we'll add more enforcement and checking of this, when it is changed by the user or if it ever differs from the virtual environment.
  9. There's a new build of dragon that fixes this issue with the Please Wait dialog text cut off. Download it here.
  10. There's a new build of dragon that fixes this issue and allows packages with Friend Classes to build correctly. Download it here.
  11. There's a new build of dragon with Multi-Select in the tree. Download it here.
  12. There's a new build of dragon that now correctly shows palettes for Instrument Drivers, User Libraries, and Add-ons correctly. Download it here.
  13. There's a new build of Dragon and VIPM 2021 Beta: Download it here Here's what's new: Improved Palettes for Virtual Environments - Virtual Environment Palette now show Instrument Drivers, User Libraries, and Add-ons correctly (reported here) Multi-select - Select and operate on multiple items/packages in the Resources tree-view to allow install/uninstall multiple packages at once (reported here) Improved New Project Configuration Detection - new project dialog will now search in subfolders (2 levels deep) for the .lvproj, .vipc, and .vipb file -- this is helpful if the root folder of the project does not contain these project files, and they are located in subfolder. 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 (reported here) Improved "Please Wait" Dialog - Fixed text cut off in the Please Wait Dialog (reported here) Here are more details for a few of the new improvements: Improved Palettes for Virtual Environments Virtual Environment Palette now show Instrument Drivers, User Libraries, and Add-ons correctly. Multi-Select You can Ctrl+Click or Shift-Click to select multiple items in the tree. Right-click actions apply to all selected items, as you can see in the animated screetshot below. Improved New Project Configuration Detection The new project dialog will now search in subfolders (2 levels deep) for the .lvproj, .vipc, and .vipb file -- this is helpful if the root folder of the project does not contain these project files, and they are located in subfolder.
  14. Hi Steven, LabVIEW plug-ins launched via quickdrop, right-click, project providers, tools menu, etc, typically get run in a different application instance and thus have their own VI namespace — each application instance can have VIs in memory with the same name, but loaded from different locations on disk. I hope that helps.
  15. Great idea, @Steven Dusing! We're working on this and it should be available in the next build.
  16. This is really great feedback @Ryan Good. First, I agree that the Package Properties window gets in the way when trying to use it to manage dependencies, due to its modal nature. Also, I agree with you that there are use cases for installing some packages globally -- in fact, some packages really need to be installed globally to fully work (right-click extensions, project providers, etc). And, it would be nice to be able to manage/visual dependencies easier. Here's a summary of what I think the use cases are: - It would be nice to be able to specify if a package should be installed globally or into the lv-venv. - It would be nice to more easily add package dependencies (and sub-dependencies) to a project configuration - It would be nice to more easily see/know a package's dependency information -- know whether a dependency is a direct/primary dependency or a dependency of a dependency (indirect/secondary/tertiary). Does that cover the use cases for this? Can you think of others or a need to further clarify any of the above?
  17. Thanks for reporting this @Joerg Hampel. Yes, there is currently a problem with this feature -- we're working on it.
  18. Hi @Yann. Thank you for sharing how IT resolved the issue for you. That's really helpful to know.
  19. Yes, that could be the issue. This issue often appears when you get to the package properties dialog by double-clicking a package in Windows Explorer and it's not yet in the package cache.
  20. Thanks for reporting this @Benjamin Rouffet -- it should be fixed in the next beta build.
  21. Hi @Joerg Hampel. Ouch! That's not good. I'd be happy to try a screenshare to see if I can assist or learn more about what's going on -- please let me know. Can you see if the main VIPM process can run? Try launching "C:\Program Files (x86)\JKI\VI Package Manager\VI Package Manager.exe" You can look in the error logs folder here for error information: "C:\ProgramData\JKI\VIPM\error" Also, with LV2019 (note VIPM 2020+ uses the LV2019 Runtime Engine) NI announced LV2019 it will not work in Windows 7 without service packs, however, I see that you're running Win7 SP1, so that might not be the problem. It could perhaps be an issue with VIPM needing a newer version of .NET installed.
  22. Hi @Sam Grayson and @Yann -- I'm also curious to learn more about how to configure Cybereason so that VIPM will work OK for you. Please let me know if your IT departments are willing to share more information.
  23. Hi @Mario. Great question. As @James@Work point to, VI Package Configurations are a great solution for keeping track of the packages in your project. Additionally, JKI has announced the beta for Dragon, which sits above LabVIEW and VIPM to provide high-level management of LabVIEW projects and configurations of packages used by your project.
  24. That sounds like a good plan and I’m glad the VIPM approach to packaging instrument drivers seems like it’ll work for you. Please do provide some updates on how this goes for you and if you run into any questions or issues along the way. This will help to expand our best practices in this area.
×
×
  • Create New...

Important Information

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