Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 01/20/2020 in all areas

  1. It would also be nice to have the shell menu option "Add to VIPM Library." on *.vip files and not only on *.vipc files. This way *.vip files can be added to the VIPM library from the windows explorer without having to install them.
    4 points
  2. Some advanced users are asking for support to install VIPM for Windows onto a Docker container. This would allow creating fully automated build processes that spin up virtual machines that have LabVIEW and VIPM installed on them, so that VI Packages can be created automatically.
    4 points
  3. I'd love to see these three License-related improvements to VIPM: 1) First, a main window column showing the package license, so it becomes very easy to see whether a package is open source, freeware, proprietary/custom, or something else. It'd be nice if the column title could be clicked to sort sort packages by license type: 2) To complement this, a change to the filter box with options to filter by license type, or maybe a second filtering box for this specific purpose. This would further help those searching for packages to focus on finding one they can afford and actually u
    3 points
  4. I think I see what you're saying -- if an older version of the package is published in a repository, but the installed/latest (i.e. displayed) version is not published, it would be helpful to know that it's a development version that's not yet "officially" published to the repo. This is different, perhaps, than a package where no versions are published. Idea: Maybe VIPM should display "Local" as the Repository name if no versions of the package are published. This deserves some more thought, for sure. I'm glad you have a workable solution, for now. Thanks for sharing these ideas.
    2 points
  5. Hi, I would like to ask for a help with the following issue: I am trying to distribute VIP file with some dependencies, which are not published on VIPM. Hence, I added them to VIPC and would like to distribute this VIPC with VIP file. Is this somehow possible?
    2 points
  6. Howdy V, I have not previously done exactly what you are asking, but have done some similar tasks. We use VIPM Pro and a local repository to distribute packages not found in the public repositories; not only our internally developed packages. First, using VI Package Builder's Destinations and Source File Settings pages you can easily include the file and specify where it is installed. Second, using the Custom Actions you can specify a VI to run Before or After the package install. Use the Generate VI button to create a template VI and save into your package project; I create a C
    2 points
  7. I do not know what I am doing wrong: I have an account on https://www.vipm.io/ where I can log in. I have VIPM installed and it was just recently automatically updated. I am able to install i2 JSON for 2018-64 I am not able to log in for "community" or "free" status. When I choose in the new window "Use existing JKI account" I get an error message, when using the account data for www.vipm.io. I also get an error when choosing "Sing up for a new JKI account". When pressing "Forgot your password?" an new tab in the browser opens where I can write my mail address and it tells
    2 points
  8. Hi, I am having an issue with functions palette I generate in VIPM. The palette is generated and behaves correctly in LabVIEW, however, when I click "show in palettes" in VIPM after installing toolkit, instead of my functions palette, Agilent 34401 palette is displayed. Any idea what might be wrong?
    2 points
  9. John, check out "Test Runner Pre-build action.vi" in the 1.0 release. I'm not sure what the current version is on LVTN, but you can find 1.0 on GitHub: https://github.com/JKISoftware/Caraya/tree/release/1.0.0/src The first snippet below is the Pre-Build action itself, the second is the actual guts of where the test gets invoked. Let me know if that doesn't get you started in the right direction or you have more questions.
    2 points
  10. Some packages (specifically if using NI License Manager API) require VIPM and LabVIEW to be started as administrator. It'd be great if there would be a "requires admin rights" flag for the package.
    1 point
  11. Hi Ivan. Yes, VIPM checks the package integrity. I think it must be an issue that VIPM Community is not running the post-build custom actions. I'll have our team look into this as well. I'll ping you offline about how we can get a work-around for you.
    1 point
  12. Hello @Jim Kring, thank you for the provided files for unpack/repack the package. I've tried to implement post-build action, but seems that there are 2 issues. 1. Seems, that post-build action is not executed. I've put breakpoint to post-build action VI - and nothing happened during the build, VI was not executed. Also, spec file was not modified. Could it be the bug, and post-build action is disabled for Community edition (the same situation as with flags?). 2. I've prepared VI in order to modify package manually (as post-build action was not called). When I
    1 point
  13. Hello @Jim Kring, sorry for the confusion, have no idea why I've written like that... What I meant - is that LabVIEW is not restarted after toolkit is installed. I'll update original post, sorry for that. I've checked spec file as you've suggested, and really there is set "FALSE" flag for LV restarting. Let me show the screenshot of toolkit's configuration, and resulting flags in spec file. Let me also attach dummy package which reproduces the issue. Thank you very much for your help! Restart Issue Toolkit.zip
    1 point
  14. Hello @Jim Kring, thank you, actually yes, it is already displayed as "Unpublished" in the "Repository" list. Just, this status is displayed also for toolkits which have never been published - for example, toolkit's development is in progress, and it is just installed locally in order to check how it works. The same happens when it is installed via VIPM which does not have license to publish packages. Or, when there are installed toolkits (like ESF, Dictionary, etc.) downloaded from somewhere, and which have not been published also. But nevermind, and thank you for the idea - it is p
    1 point
  15. Hi Jim, Trying Help >> Check for VIPM Updates didn't work but I was able to get the new build from the link you provided. Thanks again for helping me out, Greg
    1 point
  16. Good to know that Caraya is improving fast.
    1 point
  17. Recently I found this VI. But it is on the library private scope. Not so useful then.
    1 point
  18. I understand and I don't mind helping improve great products like yours. When I started the day yesterday, I opened LV2020 to work on one project. Upon completion, I closed LV2020. A few hours later, I had to work on another project that used LV2019. That's when VIPM opened and I closed immediately closed it. Finished my work in LV2019 and closed it. Later I had to open it again and VIPM opened along with it again. This morning during our initial messages. I opened LV2019 to make sure I was correct in my replies. I then close it and opened LV2020. That's when I noticed no VIP
    1 point
  19. I just edited the settings.ini with "Start VIPM when LabVIEW starts?="FALSE"". Thanks.
    1 point
  20. Hi Jim, IT WORKED! I can now use the current value table VIs. Thanks so much, Greg
    1 point
  21. Hi Ivan, You're right: Error 1357 during a package build generally occurs when two VIs of the same filename (but in different lvclass'es or lvlib's) are targeted into the same folder during the build. Fortunately, if the classes/libs (with the same-named method VIs) are stored underneath your VI Package's source folder then you can create a custom destination folder for each of them (and target each lvclass/lvlib with it's own specific destination folder). So, maybe you could move the Tree API into your project source folder. Then, you can have more subtle control over choosing
    1 point
  22. Hi @kosist Thanks for sharing this question and feedback. At one point this worked with Dropbox, but I think they changed it so that you can no longer serve static sites/files over HTTP. I'm not sure about OneDrive. Basically, you'll need something that can host all the repository files as a static website. Regarding the issue where VIPM changes URL to lower case letters: There's actually a work-around for this. You can add the URL and then fix it in the VIPM settings INI file, as described here: [18866] Package Repository URL is coerced to lowercase when adding (should
    1 point
  23. Great question. Short answer: no, you don't have to pay anything to use them in your projects. Long answer: Please see the license info here: https://resources.jki.net/jki-flat-ui-controls-toolkit
    1 point
  24. In case when new (custom) destination's name starts the same as already existing one, then both destinations are treated as the same (not possible to edit name of custom destination, and when path is changed in one of them - it is reflected in another one). As the example, there is standard destination "Help Menu", then I've added "Help Menu Test" - both of them were treated as the same destinations. And then 3rd destination "Menu Test Help" was fine.
    1 point
  25. Hi everyone, I'd like to change the description of the VIs contained in my package during the build process (to add BSD licence text). I created a pre build action and used the path array to add description to VI. It seems that the action vi is not called. What am I doing wrong ? Thank in advance for any help. Note: I'm using VIMP 2020 community edition
    1 point
  26. This is not the case in LV19
    1 point
  27. I found a method that works by using Darren's quick drop shortcut method. https://forums.ni.com/t5/Quick-Drop-Enthusiasts/Quick-Drop-Keyboard-Shortcut-Create-Place-VI-Contents-VI/gpm-p/3520372?profile.language=en I just put the JKI down in a new VI and edited it as I would normally for every new SM and then saved it as a quick drop.
    1 point
  28. Yes this 2020.1 version seems to circumvent the problem. With this experience I will try to stay at this version as long as I can...
    1 point
  29. Similar issue, im not able to activate this via email. I send out the email request and never receive an Activation code. Is there an alternate method of activation available? Fixed now, looks like my account was not setup to receive emails from JKI
    1 point
  30. Alin, Thanks for the detailed description of the bug. It helped me to reproduce it. I have recorded this issue as Case 18752 for consideration. I can't promise when this will be fixed but we will inform you when that happens. Since JKI State Machine Editor is open source, you can post any issues in GitHub: https://github.com/JKISoftware/JKI-State-Machine-Editor/issues Take care and stay safe.
    1 point
  31. In installing the JKI Flat UI Controls with LabVIEW 2020 on Mac OS, the package claims requirement to install JKI Design Palette. However this Package is not listed as available on the Mac. Not sure if there is something fundamentally not allowed on the Mac OS or if it was an oversight in packaging the JKI Design Palette. Furthermore, VIPM reports that there is also a missing dependency on OpenG Port IO which is a very old package that has never been compatible with the Mac OS. And is not part of most windows machines that haven't had a "Printer Port" in years. However that is a depen
    1 point
  32. I don't see the way to "ignore dependency". Still looking through help.
    1 point
  33. Hi, This is not a problem report but more a success story. Well done crew! I heard about caraya when I looked through the talks of VI Week (and I'm still watching videos) and I wanted to give it a go. I've been wanting to try unit testing for a while but the built-in stuff just wasn't doing it for me. We (work) do all our building, releasing and deployment via Azure pipelines so when I heard that caraya can generate JUnit format test results, I jumped straight in and made myself a test pipeline for a new feature we just added to one of our libraries. I downloaded the TDD templat
    1 point
  34. And it works perfectly now, thanks!
    1 point
  35. Curious if there is any plan to ad LV2020 support?
    1 point
  36. Hi Sam. VIPM 2020 works a little bit differently. It hangs around in memory for a little bit in case someone uses it again -- this way, it's much more responsive. Yet, it's changed the observed behavior around exactly when the package list refreshes. This is something we're working on and should be improved in the next release.
    1 point
  37. That did the trick. Curious - I thought that ran everytime you opened VIPM. Is that true? Does it only automatically do it on some schedule? I swear I had restarted VIPM.
    1 point
  38. There’s a new build of the JKI design palette that supports LabVIEW 2020! https://www.vipm.io/package/jki_design_palette/
    1 point
  39. Hey Ruslan, Thanks - I was able to take that dialog window out of my project pretty easily. Not sure what version of LabVIEW you're using, so I saved it back for 2013 just in case. The one dialog window is effectively two clusters stacked on top of each other. First I make the selection cluster visible, then when a user selects which option they want, I hide that cluster and the Name and Apply buttons are visible beneath it. Happy to answer any questions you've got on it. -Nate Add New Specification.vi
    1 point
  40. Hi guys, Just wondered if there's any way (using VIPM File Handler) to Refresh a VIPC to reference latest versions of listed packages (assuming they're already installed in VI package library) ?. Alternatively, any plans to add the ability to Add Packages to VIPC by package name rather than scanning a Project ? BR. Chris
    1 point
  41. Hi In the VIPM 2020 beta I tried to install the error logger from CPE. And indeed that worked except that the include ppl was not correct for LV2019 or LV2018 so not useable. I have send a request to CPE to add those versions but only this morning so somewhat early to expect a reaction. Is it possible to check for ppl versions or should we leave that to the developer.
    1 point
  42. Yes, I use the in-line execution mode on all the "constant" VIs that I generate as well. I tried out a quick POC performance test... There doesn't seem to be any real difference when using constants. I also tried the same LUT VI with the in-line execution switched off... that does make a HUGE difference. The in-line version is ~11x faster than the same VI with it turned off, and the VI that only contains a constant gets hit just as hard. Call overhead on such a tiny operation = ouch. I'm thinking the improved maintainability makes the LUT concept a winner. Thanks so much for the sugg
    1 point
  43. @Voklaif We dug into it and it turns out to be a LabVIEW bug. The solution is for the user (you) put a To Variant function before the call to Flatten to JSON String, since the bug seems to be inside the coercion dot (and the To Variant function doesn't seem to have that problem). Note: here's the bug (and fix) reduced to a very simple example (example VI also attached for anyone who wants to play with it)... Coerce to Variant Fail (LV2019).vi
    1 point
  44. Thanks, I'll do that. Option 2 would be nice, but I've wished a few times that the Add Control or VI option allowed multiple selections as well. That seems like the more versatile option if only implementing one of the two is feasible. Side question: Any idea why Chrome freezes will VIPM is processing a (very) large package? Background: This package I'm working on is actually a message dictionary for one of my company's products that has 27 different communication nodes and over 1200 defined messages. Since LabVIEW does not support sparse enums, the best strategy I've found to conver
    1 point
  45. I always defaulted to using the renaming, and only turned it off in rare cases when renaming broke things. So for me on those rare occasions where I didn't rename, things did work fine. I've been pretty mindful of cross linking and avoiding it between source and install. Given that the only major reason to use rename is to avoid cross-linking I'm going to try to undertake a change to have everything non-renamed. I want to be consistent one way or the other and it seems there are cases when renaming breaks things, but I'm unaware of any case when not renaming breaks things (other than cross
    1 point
  46. Hi all, I am using VI tester to run unit tests in my project. When I run unit tests for the VIs which are using NI XML APIs. The LabVIEW crashes/hangs randomly at the VI - "..\vi.lib\xml\XPath\Get All Matched Nodes.vi" at the DLL Node. I am not sure about the reason why I am facing this. In the below image, highlighted is the node where execution waits and makes LabVIEW hangs/crashes. Please answer the below Questions which helps me to understand the problem better: 1. In any case does VI Tester runs all the Test VIs Parallelly? 2. The DLL is set to run in UI Thread C
    1 point
  47. I've reproduced the issue and it should be fixed in VIPM 2020.
    1 point
  48. Hi, in our company we changed the Parse State Queue VI, so that we get the previous state in case we had an error. With this it was so much easier to debug the JKI-SM, because we were able to display the state, where the error occurred. Maybe this this an idea for the original Parse State Queue?? Here is an snippet based on the "old" Parse State Queue VI.
    1 point
  49. For Windows: LVRunTimeEng.exe (see here for detailed installation instructions) For Mac OS X: LabVIEW821RuntimeEngine.dmg (see here for detailed installation instructions) For Linux: labview82-rte-8.2.1-1.i386.rpm (see here for detailed installation instructions) labview-rte-aal-1.1-1.i386.rpm Linux Installation Instructions (more info here): Run (must be logged in with root access for the machine) rpm -Uvh labview-rte-aal-1.1-1.i386.rpm Run (must be logged in with root access for the machine) rpm -Uvh labview82-rte-8.2.1-1.i386.rpm If the above links do not work then
    1 point
×
×
  • Create New...

Important Information

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