Jump to content

Leaderboard


Popular Content

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

  1. 3 points
    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.
  2. 1 point
    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. 😅
  3. 1 point
    @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
  4. 1 point
    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 convert this into a LabVIEW library so far is using VI scripting to convert all the #DEFINES into individual VIs that are simply numeric constants wired to an indicator. Essentially, these are "constant" VIs. The end result is the library ends up having ~1450 files in it by the time all is said and done. LabVIEW has generally handled this library fine as a local library I've copied into my projects, but I wanted to package it to make it more easily distributed and easier to keep up to date when our R&D engineers release new product software. Understandably, it takes a while for VIPM to process all these files and build a package, and after installing it takes a while to update the package list. I suppose all of that is to be expected, but what's interesting is that Chrome freezes while a few of these steps are occurring. Every other application on my computer is responsive.
  5. 1 point
    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 linking which can be avoided). My major development woes with this is going to be having a VI that used to call something like: <user.lib>\_Hooovahh\<Package>\Name_hooovahh.vi is now going to have to be updated to point to the Name.vi instead. I have some scripting code to help with this which can return the expected missing VI path, but this doesn't seem to work for VIMs. I already posted over on NI's forums here. Until I get a solution it will be lots of manually fixing VIs and rebuilding...then fixing all the active projects.
  6. 1 point
    Glad you got this working and sorry for the delay in response.
  7. 1 point
    It would be interesting and useful for developers as well as users to see some statistics on downloads of packages. This way users can judge how actively certain packages are used. These statistics could include total downloads, downloads last month/year, etc.
  8. 1 point
    I've reproduced the issue and it should be fixed in VIPM 2020.
  9. 1 point
    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.
  10. 1 point
    I was able to fix this by setting vip files to open with VIPM File Handler.exe by default.
×
×
  • Create New...

Important Information

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