Jump to content

Jim Kring

JKI Team
  • Content Count

    1,592
  • Joined

  • Last visited

  • Days Won

    33

Posts posted by Jim Kring


  1. 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.


  2. @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).

    image.png 

    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

    image.png

    image.png

     

     

    • Like 1

  3. This looks like a bug.

    (Note: I've filed a bug report in our issue tracker here: https://github.com/JKISoftware/JKI-JSON-Serialization/issues/34)

    I see the same thing as you. The "bridge_data" is missing, here, when it's the only element in the cluster.

    image.png

     

    However, if I add another element next to the variant (so it's not the only element in the cluster) then I see "bridge_data" in the JSON string.

    image.png

     

    JSON Test ignoring single variant in a cluster.vi.zip


  4. Thanks for posting to the idea exchange and letting me know more about your packaging use case.

    > Side question: Any idea why Chrome freezes will VIPM is processing a (very) large package?

    I'm not sure, but Chrome can use a LOT of memory with lots of tabs open. It could also be related to disk usage. I'm not sure. 🤷‍♂️

    > over 1200 defined messages. Since LabVIEW does not support sparse enums

    Hmmm...

    Maybe you could create your own non-sparse enum that you pass into your VIs and then use a conversion VI with a look-up table to convert these non-sparse enum values to the sparse integer values used by your low-level library.  This is discussed a little bit here on lava.

     


  5. I see what you're saying.

    Ya, this isn't an extremely common operation -- typically, controls are added to the Controls Palette and VI's are added to the Functions Palette.

    So, there is an Add Folder of Controls menu option on the Controls Palette editor and an Add Folder of VIs on the Functions palette editor.

    I'm trying to think of a simple solution to make this easier for you, and I can't think of one.

    A couple possibilities:

    - The Add Control or VI option could show a file dialog that allows selecting multiple files.

    - We show both the Add Folder of Controls and Add Folder of VIs right-click options on both the Controls and Functions palette.

    Maybe you could put in a feature request, here on the VIPM Idea Exchange.

     


  6. Hi Guys,

    That's a bit tricky and depends...

    The point of adding a name suffix is because LabVIEW has historically done a poor job of preventing cross-linking of files -- there was a global namespace for all VI's in memory. Since then (and recall that VIPM has been around for over a decade) LabVIEW added lvlib (and lvclass) files to help with namespacing.

    I'd say that the #1 use-case for adding the suffix/renaming is that when you're the developer of a tool, the installed version of that tool can mess up the development version of the tool.  Of course, with the suffix/renaming you can get into situations where the source version of the tool accidentally links to the installed version, if you're not careful (since the installed versions will be in the palettes).

    As @HB65093 mentioned, when you're creating a Quick Drop, Project Provider or other LabVIEW plug-in, sometimes the renaming gets in the way of things working properly.  And, as @hooovahh mentioned, the renaming messes up dynamic dispatch calls, since the VI name is critical for LabVIEW to identify the override methods.

    For me personally, there are many cases I do not add a suffix/prefix during the build process, but I usually leave this setting ON by default unless I want it OFF.

    @hooovahh - have you had any problems *not*  adding the suffixes? If not, then it's probably not a problem.

    I'm really enjoying hearing from you all about what works well (or not) and why!

×
×
  • Create New...

Important Information

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