Jump to content

Jim Kring

JKI Team
  • Posts

    2,199
  • Joined

  • Last visited

  • Days Won

    105

Everything posted by Jim Kring

  1. Hi @Albert Geven. Glad it seems to work better. Yes, you may need to recompile/mass-compile the instrument driver after moving it into the lv-venv. The mass compile operation should fix any VI linking issues, however, it will probably not fix linkages in the .MNU palette files. We're looking into how best to fix the .MNU palette file linkages. Also, it's worth noting that the current recommendation is to NOT put the lv-venv folder under source code control, however, if you are manually copying instrument drivers into this folder, then you may want to put the "lv-venv\lv.lib\instr.lib\SOME_INSTRUMENT" folder into source code control -- we're still considering the best approach to this. Here are some thoughts about that... A. ) Does the instrument driver have a VI Package available? Note: VIPM supports importing an instrument driver .zip file and building a VI Package from it. See here: How-to-Import-a-LabVIEW-IDNet-Driver-into-VI-Package-Builder-Video If you create a VI Package and then have VIPM install it into the virtual environment, then all the VI and palette linkage issues should be transparently resolved by Dragon. B. ) Might it make sense to put the instrument driver into the project source folder instead of lv-venv\lv.lib\instr.lib? Note that if you do this, then they won't show up in the Instrument Drivers palette of the virtual environment.
  2. Hi Ryan, Thanks for reporting this. I may need a little more info in order to be able to figure this one out, yet I get the gist of it -- it gets into some kind of loop where it needs LabVIEW closed, but it keeps getting re-opened. If you're able to whittle this down to specific steps to reproduce, or want to get onto a zoom meeting to demonstrate the issue, let me know and we'll dive into it. -Jim
  3. Hi Ryan, Thanks for this post. If I understand correctly, (as part of the process of migrating a project to use Dragon) you're trying to collect all of the package dependencies for your project into a VI Package Configuration. In doing this, it would be helpful if there were an easier way to have all the dependencies of packages automatically added to the configuration. One possible way to do this (assuming you have the packages already installed and your project VIs are correctly linked to the installed package VIs) is to Scan Project for Package Dependencies. Another option is to choose "Open VIPC File" to open the Package Configuration Editor. You can then drag & drop packages from the VIPM Main package list into the VI Package Configuration editor and it will automatically suggest adding the dependency packages. Note: We're considering ways to simplify this process from within the Dragon project environment, so you don't need to use the VIPC Editor.
  4. @Ryan Good. I agree with @Albert Geven's assessment -- right now, the hardware drivers like DAQ, GPIB, etc are all global across the whole system. I am hopeful that there are solutions that will open up in the future, yet I think that virtual machines will continue to be the answer in the short term.
  5. @Albert Geven FYI, I split this discussion of "How to Install Instrument Drivers (in virtual environment folder)" into its own discussion topic/thread.
  6. Hi Albert, Can you please try installing this new VIPM Extensions package into your global LabVIEW environment? vipm_extensions_for_labview-2021.0.6.31.vip This will add "User Libraries" and "Instrument Drivers" palettes to your virtual environment. Note: You may need to manually fix the palettes of instrument drivers, since most of them use links that are relative to the installed <instr.lib> folder instead of relative links to the files. We will work on having a way to "repair" the links of these MNU files automatically, but we don't have it done quite yet. Hope that helps.
  7. Hi Albert, Thanks for trailblazing here. We'll work to make this easier for you as you move forward. The short answer is: yes, you can put stuff into "lv-venv\lv.lib\instr.lib" The longer answer is: it's not going to show up in the palettes on it's own right now, and I'm going to look into what that will take.
  8. Hi Albert. Great question! And, I’m glad to hear that the installation process went smoothly for you. Please give it a try and let me know how it goes. If it doesn’t work we’ll figure out what’s going on. Can you let me know which instrument driver you’re hoping to install there? I’d like to give it a try on my end.
  9. Fantastic! Glad to hear you're up and running.
  10. I've seen that before -- sometimes VIPM's local package database doesn't get fully sync'ed Please try this: Open the VIPM Main window by clicking on the orange "VI" Then, refresh the package list in VIPM by clicking the refresh button on the toolbar You should then be able to find OpenG Toolkit by clicking on the link again or searching for it in the VIPM Main window.
  11. Ah, I see what you're saying: Yes, I think the issue could be related to the handling of the case where the .dragon file still has 2014 defined and that can't be found on the machine. This is a known issue and should be handled better at a high-level. Glad you figured out a good solution with Notepad++. Additionally, I think you should be able to open such a project in Dragon, edit the LabVIEW version in the Configuration page, and then switch the the Project tab to open it in the new version of LabVIEW.
  12. Thanks for reporting this one! Yes, it should never open off screen.
  13. The operation that requires the LabVIEW CLI package is the Mass Compile feature (shown below and also after adding an lv-venv to a project for the first time). Note: the LabVIEW CLI package is available here and as an option when installing LabVIEW.
  14. Hi Joerg, Thanks for submitting this observation. The package icons currently indicate the following: - An installed package that is not "required" (i.e. not in the VIPC) - A required package (i.e. in the VIPC) that is installed/OK - A required package that is missing (not installed) Based on that, I think the icons in your screenshot are correct -- those packages are all required but not installed (because you opted to not install them when opening the project). Note: We're not really loving these icons and I think we could come up with better visual metaphors to indicate the two main package states: Installed/Not-Installed and Required/Not-Required.
  15. That's a great question and totally valid use case. I think Dragon definitely needs to make installing different versions of packages easier (and I'm glad you figured out a work-around to this limitation). Here are the current ways to install different versions (than the latest version) of packages (that I can think of), which may be subject to change -- I hope they are helpful in your use of Dragon, while we work out a more ideal workflows. A ) Use VIPM Main UI (as you described) - Use the VIPM Main dialog to install the package. Note that you must ensuring that the virtual environment is first activated in VIPM so that the package is installing into the virtual environment and not the global LabVIEW environment. B ) Use the Package Properties dialog of VIPM - Click on the little icon of the package search dialog. This will open the Package Properties window of VIPM that then allows you to select a different version C ) Use the VI Package Configuration Editor -- Assuming that the package has been added to the VIPC, you can open the VIPC, change to a different version, and then apply the VIPC. Hope that's helpful.
  16. I just checked the code and, indeed, it was this change (to included Edit Time Dependencies) that caused the friend class to get identified as a dependency. I think there's a possible solution -- when reading the linker info one can pass an Exclude Edit Time Dependencies. When this is set to TRUE, then Friend classes are not included in the linker info. I think this will work, since I just confirmed that Parent classes are returned in the linker info, regardless of whether one sets Exclude Edit Time Dependencies to TRUE or FALSE, so I think one can effectively determine a Friend relationship by getting the linker info twice (once with the flag set to TRUE and once with it set to FALSE) to determine if the Edit Time Dependency lvclass is a friend or a parent. I can't think, off hand, of any other types of lvclass relationships that would show up in the linker info of an lvclass other than Parent and Friend. Can you? PS - The example you submitted didn't have a .dragon file in it
  17. Thanks for taking time to post a good example. We did tighten some things up in 2021 that now results in VIPM finding some dependencies that it were not previously found — specifically, 2020 and earlier would not find dependencies inside of broken VI‘s, disable structures, or code that gets compiled out. However, it appears that we are now pulling in these edit-time Friend classes that aren’t really dependencies. Will take a look and see how we can address is. Thanks.
  18. That’s a great idea to show the build output, Joerg. I assume by “feed back the progress” you mean that you would like to see some progress text output to the standard output, which the CI is showing in the console?
  19. Hi Joerg, Great question! I'm also curious what you think and what works well for you in practice. What is starting to feel right to me is to put both .dragon and lv-venv in the root folder for the "module". This is the convention for other languages, such as python. Side Note 1: Regarding placing the .dragon file in the root folder, it's worth noting (as you may have discovered) that the "Open Dragon Project" dialog of the Dragon Welcome window allows you to select a folder (via the "Current Folder" button) and it will place the .dragon file in that selected folder. Dragon then searches in the same folder for .lvproj, .vipc, and .vipb files when it initially populate the configuration. It won't find your .lvproj if it's in the source subfolder, so you'll need to browse for that. No big deal, but this workflow for adding a new project with the .dragon file at the root level might not be obvious. Side Note 2: In the example project/screenshot you posted, the "module" is hse-libraries and contains "source", "tests", "documentation" etc. I see that the hse-libraries are further grouped into submodules, yet they all appear to share the same .vipc. In the future (as dragon makes dependency management easier), I might wonder if the requirements for these submodules would be further split up. Reducing the number/complexity of dependencies is one reason for grouping all these into a single module, and another reason is reducing the pain of applying/installing the dependencies (i.e. installing/uninstalling packages into LabVIEW). Since Dragon will make the latter much easier, it may give good incentive to make each of the hse submodules into its own module with its own .dragon, .vipc, tests, etc. I'm looking forward to hearing how this works for you and others, and what best practices we evolve.
  20. Yes, exactly. Dragon knows, by looking at the virtual environment (since it contains a package installation database), which packages are installed. I'm glad this looks promising to you, for use in production. Thanks for keeping the great questions coming.
  21. The current behavior is: Dragon won't prompt you, if you have packages installed that are not in the .vipc. Consider the .vipc as the "requirements" and if all the requirements are satisfied, then things are "OK." Can you think of situations and use-cases where you need a different behavior?
  22. Great question @Mariano Aristu. Short answer: Dragon will show you this dialog, asking if you want to install the packages defined in your .vipc file, when you open the project. Longer answer: When you open the project in Dragon, for example by double-clicking the .dragon file in Windows Explorer or opening it from the recent project's list in the Dragon Welcome screen, then Dragon will check to make sure that your project's virtual environment has all the packages installed that are defined in the .vipc file. If Dragon detects that there are packages that need to be installed, then it will prompt you to install them, before it loads the .lvproj file into memory. Or, if your project is configured to not use a virtual environment, then Dragon will check to make sure all the packages in the .vipc file are installed in the global LabVIEW environment. Let me know if that makes sense or if you have any more questions. This is a great question, I'm sure others will have, too.
  23. That would probably work (we could do some tests), but it would be better to have the virtual environment under the project when it's built on the CI server. When working on a project with a virtual environment, the project files will link to the installed package VIs in the virtual environment using relative paths. So, if the package VIs are installed under LabVIEW, then there will be a process at the project's load time where LabVIEW searches for the package VIs -- it should be able to find them, given the package VIs are installed under the LabVIEW search path, yet these will not be the "expected" locations, given the linker info stored in the project VIs that call the package VIs. Let's give it a try and see how it works. We'll also work with you to make sure you can activate the virtual environment for the project at build time.
  24. Great question @Joerg Hampel. It's basically the same thing, but requires the extra step of telling VIPM that you want to apply the .vipc (install the packages) into the virtual environment. We're working on extending the VIPM API to allow for specifying an "lv-venv" when performing package installation/uninstallation actions. That isn't quite there yet, since we've been focusing on the User Interface side of things, up to this point. Is your team at a point where you'd like to try this? Keep me posted...
×
×
  • Create New...

Important Information

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