Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Ed, Thanks for the feedback. We are aware of this issue. I'll post an issue tracking number, shortly. Thank you, -Jim
  2. Ton, Stay tuned. Today, we will be releasing RC1 (Release Candidate 1). Regards, -Jim
  3. I'm glad it's working for you. It seems that there was some kind of glitch during the installation of that package.
  4. This is caused by installing the "ogpatch_template_bugfix" package. This package does the following: Renames NewDlg InitTree.vi as NewDlg InitTree__buggy.vi Installs a new version of NewDlg InitTree.vi which calls NewDlg InitTree__buggy.vi as a subVI. If you are not able to fix this problem by uninstalling the "ogpatch_template_bugfix" package, you can restore the original file, which is included in the attached zip file: NewDlg_InitTree_LV80.zip \resource\plugins\templatebrowser.llb\NewDlg InitTree.vi
  5. Ed, The package files that are stored in the cache folder are similar to a user's library of packages. This is analagous to how one's MP3 (and other) files are stored in an iTunes music library folder. In order to uninstall a package, we must have a copy of the original package file (so that we can access the install/uninstall script VI), regardless of whether the user has removed the package file from the cache -- this is why we store the original package file in the db folder. Is this redundancy a real issue for you or are you just curious? Regards, -Jim
  6. Joe, Version 2.3 of the oglib_lvzip (zip tools) package was just released. See here, for more info. Regards, -Jim
  7. Chris, The problem was caused by one of the files inside the package having a read-only attribute, which was preventing it from being installed correctly -- this is a bug, and an internal report has been created (Case 2548). As a work-around, you should remove all read-only attributes from files, before they are packaged. Thank you, -Jim
  8. Chris, Yes, please open a support ticket, here, and then we can look into the specifics of your problem. Thank you, -Jim
  9. Mark, As Chris mentioned, you can simply copy the cache folder contents (from a Commander or VIPM installation) to another VIPM installation's cache folder. Another option is to use the Package >> Add Package(s) to Package List, menu option to add a folder of packages into VIPM's package list. Please note, that we are actively working on features to make it easier to import package configurations onto non-networked VIPM installations. Thank you, -Jim
  10. Mark, I'm glad that your using VIPM and that you've been able to quickly resolve your issue Here's a tip, you might find useful... We recommend putting each version of LabVIEW on a unique TCP-IP port. This will allow VIPM to communicate with different versions of LabVIEW, even when multiple versions of LabVIEW are running at the same time. When all versions of LabVIEW are configured for the same TCP-IP port, the first version of LabVIEW will grab the port and other versions of LabVIEW that are subsequently launched will not be able to start the TCP-IP listener. The easiest way to adjust your TCP-IP settings is to let VIPM automatically adjust LabVIEW's VI Server settings while testing the connection (see screenshot, below). Thanks,
  11. Luca, Thanks for testing and for confirming the fix. -Jim
  12. Great. Thanks for testing and getting back to us with a confirmation. -Jim
  13. Chris, Thank you for reporting this problem. Hopefully we can get to the bottom of it. Error 8 is a file permission error. Also, I need some more insight into what you mean when you say "installing a package that I recently added file to"? Did you add new VIs/files to the package (.ogp) file or that you added VIs/files into the installed location (such as the palette-sync'ed folders beneath user.lib)? Also please take a look inside "C:\Program Files\JKI\VI Package Manager\error\" for more error details. Thank you, -Jim
  14. Please see the announcement, VI Package Manager 1.0 Beta 2 Released. This release has a fix for this issue. Thank you, -Jim
  15. Ton, Please see the announcement, VI Package Manager 1.0 Beta 2 Released. This release has a fix for your issue. Thank you, -Jim
  16. Luca, Please see the announcement, VI Package Manager 1.0 Beta 2 Released. This release has a fix for your issue. Thank you, -Jim
  17. Please see the announcement, VI Package Manager 1.0 Beta 2 Released. This release has a fix for your issue. Thank you, -Jim
  18. Luca, Please see the announcement, VI Package Manager 1.0 Beta 2 Released. This release has a fix for your issue. Thank you, -Jim
  19. Luca, Thank you for trying VIPM and for the valuable feedback. The problem with the shortcut location is a known issue and the fix will appear in the next (Beta 2) release. See this discussion, for more info. Regarding the Mac installation, have you retried running the installer? Others have reported occasional errors when installing on Mac, but have had success on further attempts. Also, do you have Stuffit Expander 10, or later, installed? The VIPM installer uses this, on Mac, for unpacking some archives. Regards, -Jim
  20. There is currently a bug (in beta 1/build 390) that is preventing OpenG Commander from being uninstalled correctly. We have generated an internal case number for this issue (Case 2063) and are working on a fix. We will work to get this released ASAP. We will look into the dynamicpalette issue and get back to you. Thank you, -Jim
  21. Chris, We have the capability to support a variety of protocols, such as UNC path, local path, ftp, and http/https (with or without password authentication). I would be happy to discuss your organization's specific needs, off-line - please send us an inquiry via our contact form. Thank you, -Jim
  22. Yes, the beta will expire. When this happens users are expected to upgrade to the final release (or perhaps another beta release). The final release will not expire and will be freely available to everyone. Thank you, -Jim
  23. Fred, Make sure that you have installed the latest version of the ogrsc_dynamicpalette package. This will create an "OpenG" category in the Functions palette, where all of the OpenG libraries will appear. I hope that works for you. Thank you, -Jim
  24. Chris, Thanks for taking the time to get to know and use VIPM. We are happy that you have had a positive experience! If you are using your own VI Packages, then you will want to keep an eye out for VIPM Enterprise Edition. This will provide support for connecting to your organization's networked package repository, as well as other power features like configuration management. Stay tuned :-) Regards, -Jim Derek, Thank you for the feedback! Other's, too, have commented about the fact that the term "register", with respect to registering LabVIEW versions with VIPM, is a little confusing. We'll see if we can remedy this, in the future. Thank you, -Jim
  25. Ton, Ton wrote: > I love to have an option to set a location for these items (eg. Start\Programs\National Instrument\Tools\VIPM) Thanks for the suggestion. One quick solution would be for you to create these Start menu folders/shortcuts yourself. > The documents folder in all 3 cases were located on the D drive. Program files, LabVIEW, in the 'normal' location > I've run the same installer on a 'english' laptop, and the shortcuts were installed in the right direction. Is it possible for you to test on a Dutch installation with the documents folder located in the standard (C drive) location? This might hint as to whether the problem is related to the non-English version of Windows or, rather, the location of the documents folder. My instinct makes me think that it is probably an issue with the non-English version of Windows. Thank you, -Jim
  • Create New...

Important Information

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