Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 02/14/2020 in Posts

  1. 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. 😅
  2. 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
  3. 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.
  4. 1 point
    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.
  5. 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.
×
×
  • Create New...

Important Information

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