Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hi Jonas, I'm happy to hear that you're liking the package build numbering scheme used by VIPM. We don't have anything, yet, to report on the "release stage" idea. But, we're definitely listening. We do have an internal tracking number for this feature request: Case 9968: Add a "Release Stage" field to VI Package version information Thanks for reminding us and pushing us to work on ideas you need. We really appreciate your feedback. -Jim
  2. Hi Helcio, That's great news! I'm happy that EasyXML is working for you
  3. Are you using the same file path for "Ni parse XML" as for "Easy xml"? I see that the default values for these two paths are the same: If so, then you have a "race condition" since you're using the same file for testing both the NI XML and EasyXML VIs.
  4. Hi Helcio, I tried your example (after disconnecting the typedefs) and it seems to work just fine. What is not working? What do you see, as compared to what you expected to see? Thanks, -Jim
  5. No problem at all. I'm happy you got it working. It's funny how such small things can create such big problems
  6. I'm happy to hear that it's working for you now!
  7. Hi Jim, This is a great idea and we'll certainly consider it for a future release. It seems that this would be relatively straight-forward to implement (but the devil is always in the details). BTW, you could probably do this yourself with a Post-Build Custom Action VI. If you need help/pointers for trying this, let us know. Thanks, -Jim
  8. Hi Eldon: That's great news! I'm glad you're up and running.
  9. Hi Danielle, Great idea! There are a couple suggestions in the LabVIEW Idea Exchange that would make this a lot easier for us to implement. But, until LabVIEW supports adding menu shortcuts for Tools menu add-ons, there's not an easy way to do this. Thanks,
  10. A "System" package is an under-the hood feature in VIPM that is used to support installing files outside of LabVIEW. In fact, you can sort of think of the "?.?" LabVIEW version (in the drop-down list of the VIPM Main UI) as the "System" destination. When you build a package that includes files to be installed outside of the LabVIEW root folder, VIPM creates two packages: one for the files installed under LabVIEW and one for the files installed outside of LabVIEW. And, The LabVIEW Package has a dependency on the System Package. If a System Package is installed, it will show as installed in every LabVIEW version (when you switch LabVIEW versions in the VIPM Main package list UI). This is critical, because you don't want to install a System Package more than once (in different LabVIEW versions). It's OK to install LabVIEW Packages into multiple LabVIEW versions (\MyFiles), but it's not OK to install a System Package mutliple times ("C:\MyFolder"), because the files would get overwritten. The end result is that if you build a package that includes VIs that get installed in LabVIEW and a DLL that gets installed into the Windows System folder, VIPM will build a LabVIEW package for the VIs and a system package for the DLL. So, you can have the VIs installed into multiple independent LabVIEW versions, but the DLL will only get installed once into the system folder. One other behind-the-scenes feature is that VIPM includes the system package inside the LabVIEW package (as sort of an internal package). This means that you only have to distribute a single package file to your users/customers. Now, there are a few things we could do to improve the user experience in VIPM to make it more clear what's happening with the System Packages. For the first release of this feature, we simply show the the System package to the user as a first-class package, but we've considered the possibility of hiding these or perhaps showing them as more closely related/coupled to their LabVIEW package counterparts. -Jim
  11. This is a nice idea. We're looking at ways to more closely tie the VI Package Builder to the LabVIEW Project Environment. For now, if you exclude the broken VI (that is missing it's subVIs) from the build, this should resolve the build issue. Thanks,
  12. Thanks for reporting the issue with the SF mirrors not all being up-to-date. As you can imagine, it's a bit of a cat and mouse game trying to keep up with any changes. Of course, it would be ideal if JKI could figure out a way to automate keeping the list up to date... There really isn't a single mirror that's best (except for maybe SF's main download server that all the mirrors replicate from, but I don't recall the exact details about that this "mirror" name is). All mirrors should contain all the VIPM packages (that are hosted by SF, such as OpenG). So, if you find one that works and has reasonably good download speed to your corporate network (which can vary depending on your network location on the Internet), then that's what I would go with. Another option, altogether, would be for you to set up your own VIPM Enterprise Package Repository and, on your VIPM Clients located on your corporate network, disable (in the VIPM Options dialog) the connection to the VI Package Network. Then, have each of your VIPM Clients connect to your corporate package repository where you would make all the OpenG and other packages available to your corporate users.
  13. The best work-around that I can suggest would be for you to pick a few of your most favorite sourceforge mirrors and add them as firewall exceptions. Then, configure VIPM to use those as the preferred mirrors. Thanks,
  14. OK, then it seems this little bug is going to be a tricky one to track down. Let us know if you're able to see a pattern and we'll keep our eye out for it on our end. Thanks!
  15. OK, we'll make a note of this and take a look at your error log file, once you post it. Thanks!
  16. Interesting... BTW, I think you're the first person to report this issue. Can you please post your VIPM error log file (C:\ProgramData\JKI\VIPM\error) Are you able to easily reproduce the bug? Does this happen to any/all VIs or does it only happen to a particular VI? Can you identify any patterns to the behavior? Thanks for your help, -Jim
  17. Thank you for the link. Yes, we plan to release an update in the future and we consider this issue to be an important one to fix. Thanks, -Jim
  18. Can you attach / post a copy of this package? I can't seem to find it. Thanks, -Jim
  19. Which version of this package are you trying to install? I took a look inside lava_lib_rcf_insert_typeconversion- and I don't see any read-only files.
  20. I think I know what is the problem. I suspect that your package has one or more read-only files in it (another user had a very similar problem here). This is causing problems when VIPM tries to clean-up the files it has extracted to the temp folder. I'll take a look at the RCF Insert Type Conversion package and see if this is indeed the issue. Thanks, -Jim
  21. Hi, Thanks for reporting this. First, you can install VIPM Professional on more than one computer. The licensing is on a per user basis and you can install it on as many computers as you need to do your work. Can you try activating VIPM Pro on the computer with the problem and see if that helps? Also, does the computer with the problem have access to the Internet? Are you able to do a Check Network for Available Packages? Do you see all the VI Package Network and NI LabVIEW Tools Network packages in VIPM's package list? Finally, it would be helpful if you could send us any error logs you might have. See here for instructions. Thanks, -Jim
  22. Hi Jim, That's a feature that is definitely on our radar. I agree that the current way to create bin3 files is pretty rough around the edges. The way that we will often do it is to create the VI Package and install it -- this places all the examples in their final installed locations. Then, run the Prepare Example VIs for NI Example Finder tool and create the bin3 file. Copy the bin3 file along with all the modified example VIs (the Prepare Example VIs for NI Example Finder tool will modify your example VIs) back into your VI Package source folder. In VIPM's package builder, ensure that the bin3 is included in the built package (usually just putting this in your Examples folder, if you have one, will do the trick if you've already targeted it to the "Example VIs" destination). I hope that helps. Also, I'll check with NI to see if there is any official documentation on how to create bin3 files for your VI Packages -- there are some doc's here in the LabVIEW Add-on Dev Center that talk about how to create bin3 files, in general. -Jim
  23. Hi Jim, I am able to reproduce the problem. Thanks for taking the time to help us reproduce the problem by posting your VI Package source folder and a detailed description of the problem -- that sure makes our job easier I've filed an internal bug on this so it should be fixed in a future release: Case 9738: Can't build package with XControl instance on example VI Thanks, -Jim
  24. Great! I'm glad your running again. I'll take a look at the attached VIs when I can find the time.
  • Create New...

Important Information

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