Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hi Ben. Thanks for your help trailblazing with VIPM on the Mac! I don't have any experience with High Sierra -- I'm still on Sierra (10.12.x). Are you using VIPM Pro or Community Edition? That might be the issue. I just did a test and I can successfully build a package on Sierra using an internal test build of VIPM 2017f1 for Mac (yes, we're working on it). The package does have VIs in it and they get installed into the correct location. However, for some reason the installed package doesn't show the VIs in the palette correctly. It looks like it's a problem with the MNU files that get created.
  2. Hi All, There have been reports of issues downloading OpenG packages using VIPM, due to an outage at SourceForge.net (get status updates here). In the meantime, you can install all the latest OpenG Toolkit packages using this VI Package Configuration file: OpenG Toolkit - 2018-02-28.vipc
  3. You're welcome @Ben Stern. I think this is an interesting technical area and it would be nice if we were able to get the VIPM API working on Mac. I've created a case in our issue tracker for this: #17827. As always, we can't commit to a timeline for a fix, but wanted to let you know that it's in our tracking system.
  4. OK, I was able to call a built *.app on Mac from the command line with arguments (you actually have to execute the *.app/Contents/MacOS/Application file inside the bundle). So, it would seem that it should in theory be possible for the VIPM API to work on Mac. However, this would take some development effort on the VIPM side of things (not just on the VIPM API library).
  5. Hi @Ben Stern. That's an interesting question, and I can see how it would be very useful to have the VIPM API working on Mac. It's not currently possible (meaning, the VIPM API won't work on Mac). I don't have much experience calling built LabVIEW apps on the Mac from the command line with arguments. Do you know if it's even possible? On Mac, Applications that run in Finder are a little bit different than command-line executables (but, keep in mind that I'm not a Mac expert). I'm thinking there's probably a way to make this all work, since it's only software...
  6. I’ve created an issue in github for tracking the fix for this: https://github.com/JKISoftware/JKI-VI-Tester/issues/12
  7. Hi Norm (@Viper). Great question and you're not the first one to want this feature -- I'd like it, too. No, right now that's the only way to do it -- by unbundling and building a cluster of data yourself. EasyXML doesn't look at the data inside of classes, unfortunately.
  8. That's great that you can see the packages, now. Can you describe what you mean by a "MacOS JKI VI Tester" package? I'm assuming this might be the special Mac-compatible package I shared with you yesterday. We didn't actually make that available to the public inside VIPM -- my guess is that it says "unreleased" in the repository information.
  9. Hey @trobertson79, we found and fixed an issue on the VIPM package server that was affecting Mac users (that I was able to reproduce on Mac). I just tested the fix and it's working now for me (tested on my Mac). Please let me know if it's working for you.
  10. That's great! If you mass compile (Save All) the code, does it continue to ask about registry.dll? You may need to Ctrl+. to stop the VI Tester UI and then do a Save All. Or, you can mass compile the installation directory. Thanks for letting me know.
  11. OK, I just checked and the VI Tester package claims that it only works on Windows. I'm not sure why that's the case, or if it's true -- my thought is that this should work just fine on Mac and Linux. I've repackaged VI Tester such that it should install on Mac. Can you try this package (link below)? jki_labs_tool_vi_tester- Please let me know how this works for you.
  12. Hmmm, I'll look into it -- I've VIPM for Mac on my computer. It might be a network issue. Stay tuned...
  13. Hi Thomas. I'll do my best to get you going. First off, which version of LabVIEW are you using? The issue could be related to the fact that the latest version of VIPM for Mac is an older version of VIPM. And, yes, the vipm:// weblinks don't work on MacOS, unfortunately.
  14. Hey Grant & Joseph, The issue is that in a built application, if there's no Window (Front Panel) open, then Windows will force the application to stop -- it just pulls the plug on it. I guess that makes sense, since it is "Windows" after all. For JKI State Machine's running as the Top Level UI of a built EXE, you'll want to make sure that they don't close the front panel until after all execution is complete. One way you can "close" the front panel without it being killed by Windows, is to set the FP State to "hidden".
  15. Hey Brian. I just asked about this, and the primary thinking is this: even though it's a no-op, it serves to document how to user the "Data: Cleanup" frame. Also, in the case where someone might change the VI Reference constant to an Open VI Reference, it's helpful that we're actually closing it. Why would someone call Open VI Reference? I'm not sure, but one thing I thought of is when a VI wants to hold a reference to itself open, so that if it's Front Panel isn't visible and it's running because someone else opened it by reference to it, then it won't be "garbage collected" (aborted and destroyed) when the reference count goes to zero (since it won't go to zero if it opens an explicit reference to itself). Does that make sense? Do you have any thoughts about that?
  16. Hi Jim, Thanks for your patience in waiting for a response. That's great that you're helping your colleague's learn LabVIEW and how to use the JKI State Machine. We're actually working on some presentation/training material for new users. For now, I would recommend: Watch Video Tutorials Learn Best Practices Use the JKI State Machine Editor
  17. The JKI State Machine for LabVIEW is an easy-to-use yet powerful state machine template. It is the very same template that is used by the JKI team, nearly every day, and is the result of years of refinement by our team of LabVIEW™ experts. JKI State Machine Project Homepage Get JKI State Machine Watch Video Tutorials Learn Best Practices JKI State Machine Editor
  18. Hi Fabiola. That's fair. I guess I'm trying to figure out the volume of support calls. The solution for users is to upgrade VIPM (assuming they can), so the presumed support impact is low. Of course, that's unknown to you (or do you have information/data about it actually being a support problem)? Hi Chris. We haven't officially abandoned Mac and Linux. We may decide to release a new version for Linux and Mac, if there is enough customer need.
  19. Hey Fab, Users of older versions of LabVIEW are able to easily upgrade to newer versions of VIPM -- right now, the error dialog users see when they try to open a package that's an older format could be more helpful in suggesting an upgrade (via check for updates, right in that workflow). Is upgrading to newer versions of VIPM a problem for your users? Do you have data on how many of your users can't upgrade to the latest version of VIPM (for one reason or another)? Do you know what's preventing your users from upgrading? I'm sure you can appreciate that investing development resources in features that disincentive upgrading, in most cases, probably doesn't make good business sense. It probably makes more sense to invest those resources into features that make it attractive for users to upgrade. Of course, it's all a balance. -Jim
  20. Sorry for the delay in response, James. I think this could (in part) be because VI Tester has not been mass compiled. If you mass compile it, does it launch faster? Or, do you think it's a function of the number of tests in your project? -Jim
  21. JKI REST Client is a HTTP client library for connecting LabVIEW applications with RESTful web services. JKI REST Client provides a client implementation of HTTP protocol that is specifically designed for integrating LabVIEW applications with web services. JKI REST Client augments the LabVIEW native implementation of HTTP by adding several features that make it better fit for connecting with RESTful web services than LabVIEW native HTTP client. HTTP REST Client Homepage Get HTTP REST Client
  22. I just fixed the Knowledge Base link, thanks. Yes, that's the work-around we're proposing. For what it's worth, the bug traced back to a cluster constant on the block diagram that had the wrong cluster order for Client ID and Server ID. It was very hard to track down, since it looked like everything was working -- the swapping of values actually happened right at a dynamic Call by Reference of a VI that has its FP controls hidden (so can't debug) and BD password protected
  23. Hi Steen, David. Big apologies for the long delay in resolving this issue -- I wish I had a good excuse for that, but I don't, other than it was tricky to track down the root cause and it wasn't prioritized. Fortunately, there is a simple work-around for VIPM 2014 - VIPM 2018 (see Knowledge Base: Deactivation Fails for Licensed Add-ons built with VIPM) and a fix coming in VIPM 2018f1.
  24. VI Package Manager (VIPM), JKI's flagship toolkit ships with LabVIEW and allows you to discover, create, and share LabVIEW add-ons. VIPM gives you instant access to the add-ons on the LabVIEW Tools Network. Get VIPM, Learn More Release Notes, Knowledge Base, Idea Exchange
  25. This issue has been resolved in VIPM 2018. Stay tuned and let us know if you need early access.
  • Create New...

Important Information

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