Library with a lot of typedefs

[jb1592]

I am trying to figure out if there is a way to easily add a folder full of typedefs to the function palette more easily than adding them one at a time.

I've taken to the habit of organizing my library into folders that mirror the palette structure I want. This makes palette building using the Insert>Folder of VIs... function very easy. Unfortunately, that function doesn't seem to include CTL files.

Any tips?

[Jim Kring]

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.

 

[jb1592]

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.

[Jim Kring]

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.

 

[jb1592]

On 2/11/2020 at 1:49 PM, Jim Kring said:

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. 🤷‍♂️

Maybe... weird that nothing else seemed to be affected at all though. Not a major concern, just thought it was curious.

 

On 2/11/2020 at 1:49 PM, Jim Kring said:

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.

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.

Edited February 14, 2020 by jb1592

[Jim Kring]

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.

[jb1592]

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

[Jim Kring]

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.