Recent Learnings

[paul_cardinale]

Some things I’ve learned recently:

1. Two different Express VIs can share a common wizard (configuration VI).
2. An Express VI cannot be malleable.  The two are mutually exclusive.
3. In malleable VIs, data types will not propagate down more than one level.  If you have a malleable VI called by a malleable, the data types received by the lower one will be what they are in the original source of the upper one, not the data types of the instance.

[Dataflow_G]

Regarding multi-level malleable VIs, data types are definitely propagated down each layer (it's just not obvious when looking at the code, and LabVIEW doesn't always get it right).

I've previously written a (rough) malleable VI to polymorphic VI converter, which performs a depth first search of malleable VIs, then converts the instances into polymorphic VIs. I've attached a simplified version which recurses through each layer of malleable VIs and opens their front panels so you can view the types. Run Open Instance VIs.vi with the path control pointed to the included Top Level.vi. It will then open up the instances of Level1.vim and Level2.vim showing that the top level data type has been propagated down:

[paul_cardinale]

I stand corrected.  I had experimented with having a malleable call a malleable; and it didn't work out.  Not sure what I did wrong.

[Dataflow_G]

You probably didn't do anything wrong - malleable VIs are somewhat temperamental, and the feedback LabVIEW provides isn't very useful. One persistent issue I've found when using malleable VIs is broken wires, either actually broken, or visually broken (but the VI itself can still be run). Holding Ctrl while clicking the run arrow forces a VI recompile and usually fixes things.

[wiebe@CARYA]

Malleable VIs result in all sorts of fun...

Broken wires on runnable VIs

Normal wires that break the VI (Failed to Compile)

Broken wires that don't break when rewired.

Often saving the host fixes the compile (the Vi can run) even though wires are still broken.

However, saving the .vim might ruin all, none or some of it's callers...

Definitely room for improvement (not even considering recursive malleable VIs).

[Kyle97330]

My personal finding is that the more "nested" the VIM, the more problems you have.

Also if you try to use class wires with them you will also encounter more problems.

I've limited my current VIMs to either 2 layers of nesting max, or 1 layer max if they have a class wire in them, and that seems to make them mostly behave.

For anything where it seems that the VIM needs more nesting, then I just take one of the internal VIMs and use the right-click "Replace with subVI contents" option to flatten it into one less layer.  In most cases this loses nothing, as the internal VIMs are usually things like the assorted "Assert XXXX type" VIMs.  The only time you do lose something by doing this is if you've embedded a complex VIM that might get separate updates from the VIM you put it in that you would have wanted to propagate down (not common).

[paul_cardinale]

---

@Kyle97330 wrote:

My personal finding is that the more "nested" the VIM, the more problems you have.

Also if you try to use class wires with them you will also encounter more problems.

I've limited my current VIMs to either 2 layers of nesting max, or 1 layer max if they have a class wire in them, and that seems to make them mostly behave.

For anything where it seems that the VIM needs more nesting, then I just take one of the internal VIMs and use the right-click "Replace with subVI contents" option to flatten it into one less layer.  In most cases this loses nothing, as the internal VIMs are usually things like the assorted "Assert XXXX type" VIMs.  The only time you do lose something by doing this is if you've embedded a complex VIM that might get separate updates from the VIM you put it in that you would have wanted to propagate down (not common).

---

In my case, within the .vim, I needed the same code t run on several different inputs.  Instead of replicating the code, I wanted to put it in a sub VIM (which I eventually accomplished).

[wiebe@CARYA]

---

@Kyle97330 wrote:

My personal finding is that the more "nested" the VIM, the more problems you have.

Also if you try to use class wires with them you will also encounter more problems.

I've limited my current VIMs to either 2 layers of nesting max, or 1 layer max if they have a class wire in them, and that seems to make them mostly behave.

---

I concur.

What also makes a different is not having a 'final' type specialization structure case that breaks everything:

That seemed like a good idea, so the last case would always break, by simply putting an unwired increment in it. But that seems to also break all the wires in a way they don't get unbroken when a good case is selected.

---

@Kyle97330 wrote:

For anything where it seems that the VIM needs more nesting, then I just take one of the internal VIMs and use the right-click "Replace with subVI contents" option to flatten it into one less layer.  In most cases this loses nothing, as the internal VIMs are usually things like the assorted "Assert XXXX type" VIMs.  The only time you do lose something by doing this is if you've embedded a complex VIM that might get separate updates from the VIM you put it in that you would have wanted to propagate down (not common).

---

I might give that a try...