Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hey Ken, I'm really eager to hear more about how VI Tester plays a role in your continuous integration process. We're happy to help answer any questions and brainstorm on ideas, so don't hesitate to ask... Regarding calling VI Tester from Python, there are certainly a lot of ways to do this. If you're on Windows, the easiest way might be to use ActiveX. Here's an example of how to run some a Test Case from Python using ActiveX: # initialize the path to your test: this is just an example test case myTest = r"C:\Program Files\National Instruments\LabVIEW 8.2\examples\JKI\VI Tester\Queue TestCase\Queue TestCase.lvclass" # connect to LabVIEW import win32com.client labview = win32com.client.Dispatch("LabVIEW.Application") # get VI reference to 'Run Tests (Path).vi' VI = labview.GetVIReference(r'C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\addons\_JKI Toolkits\VI Tester\VI Tester API.llb\Run Tests (Path).vi') # run the unit test by calling the Run Tests VI returnVals = VI.Call(["Test Path", "successful?", "test details"],[myTest,"",""]) # get pass/fail Boolean (pass = TRUE) passAllTests = returnVals[1][1] # get test details string testDetails = returnVals[1][2] # disconnect from LabVIEW labview.Quit()
  2. Hi Marc, We've gotten this request from others, too. I agree with you that there needs to be more options for namespacing VI, including no namespacing. Also, adding to an LVLIB is a great way of namespacing. There are a variety of considerations that make implementing these non-trivial (mostly related to building dependencies into the package). Rest assured that these are features that are on our radar/roadmap. Thanks, -Jim
  3. Hi Marc, Yes, adding support for packaging up non-LabVIEW file types is a needed feature and is one that's on our radar. Thanks, -Jim
  4. Hi Marc, You're right that VI Package builder doesn't support the custom probes use case -- it was designed specifically for packaging up reusable VIs. However, I think that we might be able to help you. I think that you could create a post-build hook VI (download template here) that removes the underscore from the LLB file name. Take a look at the docs and let me know if you have any questions. I'd be happy to try to help you out, as I've got some experience with creating build hooks. Thanks, -Jim
  5. Hi Marc, Yes, this would be a useful feature. For the first release of package building, we took the approach of trying to make a system where the user does not care where VI Package contents get installed. For example, they select a folder of VIs, edit the palette, build the package, install it, and then the VIs automagically appear in the User Libraries palette. That works great for 90% of the use cases, but I can see how some users would want more visibility into the process (and especially in cases where it's not working perfectly). Thanks, -Jim
  6. Hi Marc, First, thanks for all your recent posts and great feedback! Regarding the ability to install packages into the project folder, this is use-case that is on our radar and we're thinking about how best to achieve this. Regarding your specific use case of wanting to better way to instantiate VI and CTL templates in your projects, this is actually a separate use case and something that is also on our radar. So, rest assured that you're right on the money and trying to do things that make sense. Hopefully, we'll have a good solution for you, in the (hopefully not too far off) future. Thanks, -Jim
  7. Yes, this issue is known to JKI and there isn't any workaround, except to close the offending LabVIEW version. Usually, this is only a minor inconvenience, since we usually don't really need two different versions of LabVIEW open concurrently.
  8. Hi Bob, I hope after all this work, that this resolves your issue. Good luck and let me know. Thanks, Jim
  9. Hi Bob, It seems that we've exhausted most of the easy possible solutions. Please contact us and we can discuss other options. Thanks, -Jim
  10. Hi Marc, Currently, VIPM has some trouble building classes that use dynamic dispatch. This is due to the fact that LabVIEW requires that each class's implementation have the same VI name as the parent's VI. When VIPM builds the package, it cannot put both VIs into the same LLB, since LLB's are flat. We're looking into ways to resolve this issue. Thanks, -Jim
  11. Hi Greg, Version 2.0.1 has been released and resolves Case 7602 (working copies that use _svn do not work). Thanks for your patience. We're looking forward to your feedback. Thanks, -Jim
  12. What's New in JKI TortoiseSVN Tool 2.0.1 JKI TortoiseSVN Tool 2.0.1 is a maintenance release that builds upon version 2.0.0 and fixes a minor issue for those using non-default names for the .svn metadata folders. Affected uses should upgrade. New and Changed Features None Resolved Issues 7602: Some SVN folder types were not detected properly. TortoiseSVN allows you to use "_svn" or "SVN" meta folders, rather than the default ".svn" setting. The non-default settings were not being handled properly in the JKI TortoiseSVN Tool. Release Date: June 22, 2009 To download and install the demo version, purchase the toolkit, or for more information visit http://jkisoft.com/tortoisesvn-tool/
  13. What's New in JKI TortoiseSVN Tool 2.0 This is the first public release of the JKI TortoiseSVN Tool for LabVIEW. It supports LabVIEW 8.2 or later running on Windows XP or Vista and requires TortoiseSVN 1.6.1 or later. Release Date: June 5, 2009 To download and install the demo version, purchase the toolkit, or for more information visit http://jkisoft.com/tortoisesvn-tool/
  14. Hi Bob, Can you check to see if this helps? http://forums.jkisoft.com/index.php?showtopic=1028 Thanks, -Jim
  15. Hi Marc, I can help you out. I'll email you some information. Thanks, -Jim
  16. Sorry about that. Did you try any of the suggested solutions?
  17. It deals with them very well Here are some excerpts from the documentation: Rename... - Performs an SVN Rename and synchronizes the target VI(s) in memory with disk. Delete... - Performs an SVN Delete, followed by an SVN Commit. This item is only allowed for VIs that have no VI Callers in memory. In both cases, the JKI TortoiseSVN Tool keeps the LabVIEW VIs in sync with the VI files on disk.
  18. Hi Greg, Thanks for the feedback. Please feel free to let us know how you might expect atomic operations to work inside the project environment. We'd love to hear your ideas. Yes, revert is a very useful feature, but try these out, too, because I think they are very useful: Show Log: see all the changes made to a single VI Rename: rename a VI in svn and in LabVIEW, with a single operation (try doing this yourself, to see how hard it is) Delete: delete a VI from disk and svn, after it is no longer being used in LabVIEW Thanks,
  19. Can you ping jkisoft.com from the command line? ping jkisoft.com Can you telnet in to port 80 from the command line? telnet jkisoft.com 80 (after you connect, type a few characters and then press and you should see a bunch of HTML output) Can you open a TCP connection to jkisoft.com on port 80 from within LabVIEW, using the TCP open connection function (see the example VI below)? Test_TCP_Connect_to_JKI.vi
  20. Hi Greg, Yes, a lot of people use _svn. It's not a requirement to use .svn with the JKI TSVN Tool -- it's a bug that you can't use _svn. This bug will be fixed in the next release (which will be available very soon) and you'll be up and running. Thanks,
  21. Hi Bob, Thanks for taking the time to test-drive the JKI TortoiseSVN Tool. We hope that you find it useful. Right now, the tool operates on individual VIs/CTLs/etc or on the selected VIs/CTLs/etc. in the project. We don't have a feature, right now, that allows you to operate on all VIs in your project, but we're thinking about how we might do this. Note: You're not alone -- someone else asked a similar question, this morning. Thanks,
  22. It seems (from your error log file) that you're having some TCP issues. Do you have a proxy server configured? Thanks,
  23. Hi Greg, I believe that you might be experiencing the following known issue: Case 7602: working copies that use _svn do not work Are you using the .svn or _svn folder convension in your working copy? Thanks,
  24. Hi Greg, We don't have such a feature, right now, but we're thinking about how we might do this. I agree that it would be a very useful. Thanks,
  • Create New...

Important Information

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