Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Also, I should mention that there is another helpful tip: "Pin" packages that are manually added. “Pinning” prevents VIPM from removing the package after a Scan Project, if the package is not found as a dependency.
  2. Hi James, I've just updated the How to use VI Package Configurations (VIPC) help document to include some info about how to manually add new packages to a VI Package Configuration file. Basically, there's two ways: You can manually add packages to a VIPC file by dragging & dropping them from the VIPM Main package list into the VI Package Configuration window, as shown below: Or, you can right-click on the package from the VIPM Main package list and choose Send to Configuration, as shown below: I hope that helps!
  3. Have you tried turning off your firewall? Also, you might take a look at this document: Resolving issues with VIPM connecting to LabVIEW (and the section on "Configure the Windows Firewall")
  4. Hi Jonas, I'm sorry for all the troubles. Regarding the password-protected source libraries, thanks for the description and ideas for ways we could implement support. You're right that the build occurs in a difference context than the pre-build. I'll think a little more on this issue and ways we might be able to work around it. Regarding the path separator issues, which version of VIPM was used to create your older .vipb files? I'll see if we can reproduce it. -Jim
  5. Hi Carmine, No, EasyXML requires that a data structure be passed in. However, there are some ways to make EasyXML and your data structures more flexible. If you change one of your clusters (or other any other LabVIEW types) to a string data type and add the "#xml" hashtag to the end (e.g. "TestResult #xml"), then EasyXML will return the data as a string. This is sometimes helpful if your structures have types that can vary. -Jim
  6. My guess is that you are installing the VI files under instr.lib and they are being found there and automatically LabVIEW is creating a default palette set for them. When you specify the installation location for the VIs, try adding an underscore in front of the main folder name, which will cause LabVIEW to ignore that folder (and LabVIEW will only look at the MNU files created by VIPM and not try to automatically add the default palettes for all the subfolders, too).
  7. Hello Carmine, I'm glad you figured out the solution -- yes, this is the approach. You're right that it would be nice to provide a more direct way to extract the data of interest, in some cases. Thanks!
  8. Can you send a screenshot of the contents of this folder: C:\ProgramData\JKI\VIPM\databases\LV 14.0\ni_lib_keyed_array\ Also, can you try exiting VIPM, deleting this file (below), and then restarting VIPM: C:\ProgramData\JKI\VIPM\databases\LV 14.0\package database info.pdi2 Note: Please replace "LV 14.0" above with the LabVIEW version your trying to install into. For example, maybe you're installing into "LV 13.0" (2013).
  9. Hi Scott, I can't seem to reproduce the issue. I'm running 1955 on Mac and click refresh mirrors and it tells me the list is up to date. I press "OK" and everything seems to work just fine. -Jim
  10. Great, I'm glad it's working for you now, Tim. Yes, VIPM does make this distinction (accessing vs managing a repository) a little tricky to grasp. Have a great weekend!
  11. With the release of VIPM 2014, package build specs are now named, e.g. "MyPackage.vipb" instead of simply a ".vipb" file in the package source folder. This introduced an issue (ID# 16100) with the VIPM API for programmatic package builds and build spec reading/writing. This issue was resolved in the new release of the VIPM API version 2014.0.0.38. You can install the new version using VIPM here: http://vipm.jki.net/...ki_lib_vipm_api
  12. There's a new build of the VIPM API (that includes a fix for this issue) available for download, here: http://vipm.jki.net/#!/package/jki_lib_vipm_api Please let us know how it works for you: -Jim
  13. Hi Tim, > There seems to be no way to edit this "Location" from this dialog; nor can I find ANY place to edit this value. SUGGESTIONS? You're right. You can't edit the location once it's been added to VIPM list of repositories under management. You'll need to go into the options to remove it and then re-add it: Go into the Tools>>Options (menu) >> Repository Manager (tab), select the repository, click the red X to remove it, then click the plus to add the new one.
  14. This is a package on the LabVIEW Tools Network. I would contact NI's support, here: www.ni.com/labview-tools-network/support/
  15. This is a package on the LabVIEW Tools Network. I would contact NI's support, here: www.ni.com/labview-tools-network/support/
  16. VIPM occasionally opens an Untitled VI during package installations when custom action VIs are executed. This is done to work around an issue where LabVIEW would hang during execution of the custom action VIs if the LabVIEW Getting Started Windows was open. VIPM does not currently close this untitled VI afterward. [update: There is a knowledge base entry for this, here: http://support.jki.net/entries/63014465-An-untitled-VI-opens-when-installing-a-VI-Package-with-a-Custom-Action-VI]
  17. Hi Bob, In this case, it seems the connection timeout was not a fatal error, since it only needed to connect to LabVIEW to refresh the palettes. I would focus on figuring out how to get VIPM to successfully connect to LabVIEW. Is there a reason you're using the same TCP-IP port for VI Server on all your instances of LabVIEW? Note that there are a variety of reasons VIPM might not be able to connect to LabVIEW, including windows firewall, LabVIEW VI Server settings, etc. -Jim
  18. Hi Tim, Yes, you should be able to: 1) Move the repository folder to a new server. 2) Edit the repository URL so that it correctly reflects the new location. 2.a) Note that if you have an older version of VIPM (e.g. VIPM 2012 or earlier) then you will need an activation code for the repository. 3) Update all the clients to point to the new repository URL.
  19. Hi Nate, I agree that the feature you're describing would be nice for your use case, to avoid having to download the package file in the web browser. We're actively looking at ways to improve the package sharing user experience and will keep your suggestions and use case in mind. Thanks for taking the time to provide your feedback and input! -Jim
  20. Hi Nate, The following could work: 1) Create a VIPM repository on your local computer's hard drive. 2) Commit this local repository into SVN (e.g. http://server/svn/trunk/my_package_rep) 3) Have clients connect to the repository at it's Repo URL (e.g. http://server/svn/trunk/my_package_rep) -- note that this requires clients have VIPM Professional. Also, you might want to check out the VIPM Repository Theory of Operation document for more info. Please let me know if you have other questions or suggestions for ways to improve VIPM (you can also post these to the VIPM Idea Exchange) -Jim
  21. The spec file contains the license agreement name, whereas the "license" text file contains the actual license agreement content. Back in the days of OGP files, we only supported the license agreement name in the spec file and not including the actual agreement itself. It sounds like you've got what you need. Hopefully my addition comments are helpful, too
  22. Here is an unofficial way to read the license text that is not guaranteed not to break in the future (and, if you can't find an officially supported way to do this, feel free to suggest it in the VIPM Idea Exchange) (this uses the OpenG ZIP Library)
  23. Hi Everyone. We just released a new version ( of VI Tester with a fix for this issue! You can get this new version by checking for package updates with VIPM. Thanks for your great feedback and patience.
  24. Hi Everyone. We just released a new version ( of VI Tester with a fix for this issue! You can get this new version by checking for package updates with VIPM. Thanks for your great feedback and patience.
  25. Hi Charles! Thanks for the feedback on your getting started experience. I agree that these three things could be improved. Yes, VI Tester is still maintained, minimally at the moment, but (fairly) we'd love to be able to give it even more love than we're able to right now. Let's keep the dialog going. It's great to hear that people use/love VI Tester and it motivates all of us at JKI!
  • Create New...

Important Information

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