Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Yesterday
  3. Hello, I have a system with LabVIEW 2015, 2016 installed. I am trying to install 2019, however, when I try to install VIPM 2019, I get this message: I've also tried uninstalling from the windows uninstaller and get this: I don't have 'vipm-setup.msi' for 2016. Any ideas how to resolve? -Chris
  4. Last week
  5. Hi Chris. I don't think there's a way to do either of these, currently, via the API. They are both great ideas and I support them Would you be willing to post these ideas to the VIPM Idea Exchange?
  6. 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
  7. Earlier
  8. Hello JKI Team, In order to install a package in labview 2018, jki_lib_flat_controls >= is required as a dependency . I tried to install JKI Flat UI Controls instead but it doesn't work. Could you give me an advise in this case ? 1, Is it correct that JKI Flat UI Controls is an upgrate of jki_lib_flat_controls ? 2, In the case not, where could i download jki_lib_flat_controls (This package exists no more in VIPM) ? Thank you in advance. Regards,
  9. Same issue here as well, I've tried a couple times during the past 3 months to use the new JKI Icon Set 2.0 but I get to the Design Palette Activation screen, enter my email, and I never receive an Activation Code. I made sure I was opt-in for JKI emails and it looks like I am. Would really like to use this new icon set especially since your 1.0 version was so good. Thanks JKI Team!
  10. Is there any performance advantage to EasyXML over the built in LabVIEW functions? I wrote a TestStand XML reporter parser in LV to import the data into a SQL database which works but can't seem to keep up with how many reports we generate. Reports can take 10 - 45 sec to parse and import and there are thousands of them. Also, there seems to be memory leaks that I can't find the built in parser that slows the importer as it is running 24/7. I usually reset the system every week or so if I remember. An example of a large report here would have 300 tests to import.
  11. Here are some links: https://blog.jki.net/jki/introduction-to-jki-json https://github.com/JKISoftware/JKI-JSON-Serialization There's not much documentation, since it's a very simple serializer.
  12. Dear JKI Tream : I want to learn the JKI JSON toolkit but I can't find the help file online. Send me a help file? Thanks!
  13. 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 use for new open source projects, which is particularly relevant now that LabVIEW Community Edition is going to bring in lots of new users who definitely aren't going to purchase proprietary add-ons: 3) Finally, it be interesting for the VIPM Community Edition, specifically, to only allow the creation of open source packages, what would create a clear barrier to those who might be thinking of using VIPM Community Edition for proprietary package creation. This could be done by changing the "License Agreement Name" (in VIMP Community Edition only) from a free form text field to a combo box listing only OSI-Approved licenses' SPDX codes, therefore making the intended purpose extremely clear. The default option could be BSD, with other popular OSI-Approved licenses listed below it, and less common ones (if requested) on a submenu: What do you think? 😊 PS: Re-posted with changes from the original in the VIPM 2020 Beta board.
  14. Hi Albert, Thanks for reporting this. Yes, you should certainly contact CPE regarding this issue. It would be great if VIPM could detect this, yet I think that it might be tricky to try to guess the developer's intentions. Maybe VIPM could warn the package developer of potential problems. -Jim
  15. 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.
  16. I like to give my users a "starter pack" when beginning a new project. Part of this includes setting up a directory structure with a vipt file waiting for them. However, when packages are built vipt files are ignored. I have gotten around this by renaming them before build and then restoring the old name after installation, but this seems like a fragile and inelegant solution.
  17. Drag *.vip files into Repository Manager window. Useful if you one has many packages to publish simultaneously. For example, if the catalog gets corrupted one could drag the entire "packages" directory into the Repository Manager to reconstruct the repository.
  18. Hi @maristu. We have a fix for this issue in the VIPM 2020 Beta. Thanks again for reporting it. If you'd like to help test, please sign up for the beta.
  19. Son of a gun!  After posting "I can't install VIPM 2019", I tried once more, got the same error, clicked something (maybe "ignore"?, and the installation started up, despite the error.  It finished, and now it looks like it is working.  Weird.

    Bob "I believe in Miracles" Schor

  20. Hi I had a package named "cfgCampaña xdas" but due to the special character ñ I had some troubles to publish. I can not remember exactly the problem. Finally I renamed the package, it it published in my repository but the old package "cfgCampaña xdas" continues in the vipc file, but it is impossible to remove, and once I try to remove with the right click menu I can not close the window dependencias xdas.vipc vipmsupport_02-19-20_11-45-01.bin
  21. That's great that this LUT approach with in-line execution mode will work for you. Yes, it should be a lot less maintenance in the future. I'm glad it's looking like a good path forward. Thanks for letting us know how it goes. I've learned a bit from this discussion, too.
  22. 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 suggestion... now to rework my code conversion scripts and delete a lot of VIs I don't need anymore. 😅
  23. This works. Thanks for the quick reply and fix.
  24. Yes, I’m pretty sure that if you use an array constant for your sparse values and you use a constant enum to index into that array, then labVIEW will constant fold the array indexing and look up. if you do this in a subVI, to use that look up in several locations, then you’ll probably need to set this up VI execution mode to in-line into the caller, in order for the constant folding to work I’m the calling VI. That being said, if the enum integer values are used as the indices into your look up array, then the operation should be lightning fast.
  25. Maybe... weird that nothing else seemed to be affected at all though. Not a major concern, just thought it was curious. That's a pretty good idea... Certainly easier to maintain, although I wonder how well Labview optimizes code like that. I'm thinking it would be less efficient since there would be the external VI call to index the look-up table, but in most cases it would be a constant enum indexing an constant array... I wonder if the compiler is smart enough to just evaluate that to constant value when I build the application for deployment. One again, mostly just a point of curiosity. It's not like that anything I'm doing is that performance sensitive anyway. Thanks for the suggestion. I may do that. 😄 Edit: I read the link after commenting on the suggestion; I assumed pushing every value into an array constant and indexing, but that example is using a case structure. I wonder if there's any significant difference/benefit to one way over the other. I guess the array based LUT could have a share of space allocated to undefined values, but it shouldn't really be that much.
  26. @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. Load more activity
  • Create New...

Important Information

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