Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. 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.
  2. This is a package on the LabVIEW Tools Network. I would contact NI's support, here: www.ni.com/labview-tools-network/support/
  3. This is a package on the LabVIEW Tools Network. I would contact NI's support, here: www.ni.com/labview-tools-network/support/
  4. 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]
  5. 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
  6. 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.
  7. 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
  8. 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
  9. 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
  10. 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)
  11. 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.
  12. 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.
  13. 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!
  14. Hi Bob, I'm still using 1.7 myself and am not sure about the problems you're describing. Can you post a link to your post in the NI forums, so we can follow along there? Thanks, -Jim
  15. Hi Jeff, I think that build 1893 (pre)released in the VIPM Labs addresses this issue: Case 14456 - "Remove Dependency" button doesn't work. In the VI Package Builder window, clicking the "Remove Dependency" button does nothing. It should remove the selected external dependency (and make it internal). - This has now been fixed. http://support.jki.net/entries/24071293-VIPM-Labs -Jim
  16. That's a good idea. You're right that this new template is really just an example associated with a presentation that's designed to help inspire and get you started in creating your own template. I agree that it would be nice if there were an official template :-)
  17. No, but that's a fantastic idea! We use and love this framework (obviously) and have a lot more we could talk about. When did you evolve the template at all for your application? Did you hit any limitations? There are (hopefully) some cool features coming in LabVIEW 2013 that will make this design pattern even better, so stay tuned.
  18. Thanks for the response. I'm glad this looks like a good solution. Let us know how it goes!
  19. Hi Martijn, Yes, I think you could add a post-install custom action VI that compiles your shared lib via the command line at install time. But, would configuring the Call Library Function node with a .* (instead of ".DLL") file extension maybe solve your issue? What I mean is that, if you have the platform-independent shared libraries in the same folder and use the ".*" convention in the CLF node, then LabVIEW will load the right one for the target platform? For example, you could put "mylib.dll" (Windows) and "mylib.so" (Linus) side-by-side. See this doc for more info: http://zone.ni.com/reference/en-XX/help/371361J-01/lvexcodeconcepts/configuring_the_clf_node/ I hope this helps, -Jim
  20. Hi Peter, I think that our support team can provide you with a fix for the period/comma issue. Can you please contact them, here: http://jki.net/contact Thanks, -Jim
  21. You can use VIPM Pro to create a VI Package Configuration file -- it does exactly what I think you're trying to do. Here's some good information about how to use this VIPM feature: http://support.jki.net/entries/20646062-how-to-use-vi-package-configurations-vipc -Jim
  22. Hey Jason, Take a look at the VIPM API. It should have everything you need to programmatically check which packages and versions are installed on your system. -Jim
  23. I don't think that this is supported in VIPM or in LabVIEW (a quick test of the palette editor shows that you can't add an LVClass). However, if you create a "dummy" VI that has the LVClass control on the front panel, you can add it to your palette and configure it to Place VI Contents (so that the contents of the VI [the LVClass control] are dropped rather than the VI itself). Set the "dummy" VI's icon to look like your LVClass control and you're all set. Does what I've described make sense?
  • Create New...

Important Information

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