Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. 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
  3. I reported this a couple of months ago via Twitter. At that time Jim responded that the reason packages built using VIPM 2017 do not work with earlier versions of VIPM is due to adding support to malleable VIs. Would it be possible for VIPM to have a way to package the packages the old way when they do not include a single malleable VI in them? Our main toolkit, DQMH, is available via the LabVIEW Tools Network, and we don't want to impose a VIPM version requirement for our users. We are having to stay with VIPM 2014 or 2016 in order to build DQMH packages if we want to ensure that everyone is able to install them. This is the main reason why we will not renew our service plan with JKI. It does not make sense to pay for a renewal when we are forced to use an earlier version of the product. Thanks, Fab
  4. Yesterday
  5. VI Tester Very Slow To Initialize

    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
  6. 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
  7. 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
  8. Perfect Jim, thanks. I'll try the workaround and keep an eye out for the fix. I'm not permitted to follow that link, is the workaround the same as Jens Gräwe suggests here?: https://support.jki.net/hc/en-us/community/posts/360000027103-Error-in-Deactivation-Infos-in-VIPM-Pro Cheers, Steen
  9. Last week
  10. 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.
  11. 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
  12. This issue has been resolved in VIPM 2018. Stay tuned and let us know if you need early access.
  13. Caraya is an assertion and unit test framework for LabVIEW that is simple and fast. It takes a whole new approach to unit testing; your VI is your test. Caraya allows you to convert your manual test VIs you use to debug your code into unit test cases with nearly no effort. This significantly lowers the barrier to systematicaly write unit tests for your project leading into improved overall code quality for real-world projects where developers don't always have the luxury to write unit test cases first. Caraya Project Homepage Get Caraya
  14. Package Build Fail if VIM Dependency

    Confirmed this error on LabVIEW 2017 (no SP1 yet), and VIPM 2017.0.0f1. I'll try it on LabVIEW 2017 SP1 in a few days.
  15. Earlier
  16. I have a colleague that is interested in learning LabVIEW and I want to get him started on the JKI SM (and SMOs) right out of the gate. Are there any ready-made presentations that demonstrate the common pitfalls facing a new developer, and how the JKI SM handles them? Thank you, Jim
  17. I think you're misunderstanding what I'm saying. The problem here is that Mac and Linux cannot be used to install packages built with VIPM 2017. I'm not talking about earlier versions. You mention that having the source and build spec would allow someone to use a package on Mac or Linux, but that doesn't help at all in the most common case where only the .vip file is made available. As far as I know, all the packages on LabVIEW Tools Network, JKI Package Network, etc do not have source files and build spec available for download. This means that future builds of released packages made with VIPM 2017 will not be available on Mac or Linux.
  18. PS: Not entirely true. VIPM 2014-linux is able to install for me a lot of packages built with earlier versions of VIPM, on LV-linux 2015, 16 and 17.
  19. Yes but - having the sources and the package build specification, known to work VIPM 2017, as well as several LV versions installed, can a package be built with 2014-linux? Specifically I'm thinking at this package. I don't think it contains any code which needs the very latest LV features, in fact it is provided for LV2015. If I try to load its .vipb in VIPM 2014-linux, I just get "VI Package Builder was unable to open the build spec due to an error". Perhaps something offending in this .vipm which could be patched at hand? ref: https://lavag.org/topic/20262-cr-lv-muparser/?do=findComment&comment=123699
  20. Try reinstalling VIPM. If that doesn't help try upgrading VIPM to VIPM 2017
  21. I am using the 2016 free edition.
  22. Well I was just able to uninstall and reinstall that package with 2016 32-bit Windows 7 x64. What version of VIPM are you using? I'd expect every version to be compatible with OpenG. Do other packages install alright in 2016?
  23. Please see the error screenshot. My LabVIEW version is 2016 32bit English.
  24. Update from JKI: This issue is planned to been fixed in VIPM 2018. So I can successfully build packages with VIMs in them. But I found that if I need to make a package, that depends on a package, which contains a VIM, the build will fail. First install the hooovahh_array_vims-1.0.0.6 package. Then try to build the File IO package, which at the moment only contains one VI. If it is like my setup the build will fail with this error. If I remove the VIM dependency by replacing it with the OpenG one the build is successful. Build Fail VIM Dependency.zip
  25. Great! It was indeed one of the fixes implemented in VIPM 2017 SP1. Thanks for confirmation and glad to know that you were able to build the package successfully.
  26. So on VIPM 2017.0.0f1 I'm having a build that fails if I have some specific VIM, and the Renaming Convention is set. If I don't have renaming, or if I don't include this one VIM then things seem to work properly. Here is the error And attached is the source and build spec. If the Filter 1D Array-VIM.vim is removed from the source, then the build works (renaming all the other files to have _Hooovahh as a suffix). Or if the Filter VIM is left but renaming is disabled the build is successful. Array.zip
  27. The recently posted update VIPM 2017 F1 fixes this issue for me. Finally I can build all the VIM packages I've been wanting to.
  28. VIPM IDNet import tool failing...

    Ricardo, Sorry for such a late response. How did you manage to solve the issue? It appears that the toolkit provider should be able to help you.
  29. Apologies for extremely late response. I think this problem is solved for VIPM 2017 We tried with the code provided by you: https://www.screencast.com/t/Rq61BsNRG
  1. Load more activity
×

Important Information

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