Wiring Errors in MALLEABLE VIs

[CoastalMaineBird]

LV2018.

I'm using a MALLEABLE vi to adapt a VARIANT (from a settings file) to a specific data type (given by DEFAULT VALUE here).

For the normal case, I just wire the DEFAULT VALUE into the TYPE input of a VARIANT TO DATA function and it's good.  If default value = boolean, it converts the variant to boolean, etc., etc.

I have a couple of special cases: for example ARRAY of booleans. That is stored in the file as TFFTFTFTT or something.  I can't use that directly (TDMS file won't store it that way).

So I use a MALLEABLE vi to detect the type of DEFAULT VALUE.  If it's [BOOL], then I read the variant as STR, then apply my own decoding to it, or use the default if it wasn't found.

That works fine.

EXCEPT

In moving things around, I accidentally broke some wires.  But THE VI IS NOT BROKEN, and NEITHER IS ITS CALLER.

Here you can see the malleable VI with the declined case showing, and the parent VI which calls it.  Neither is broken.

Again, I understand how to remove broken wires, but HOW DO I KNOW THEY'RE THERE?

The parent VI runs, but fails, because the wrong malleable case is accepted.

I could change the DEFAULT VALUE to be [BOOL] and that shows that the case I want is broken for other reasons.  So I fix the wires and then change it to [DBL] because that's another special case.

Is there a better way?  Do I have to test every case any time I make a change?

I'd like for the case to be broken ONLY because I put an ASSERT TYPE into it.

[Kyle97330]

"Do I have to test every case any time I make a change?"

I'm pretty sure the answer to this is "yes", because of the nature of the Type Specialization Structure.

The TSS has a pretty simple function: Find the first case that isn't broken.  It doesn't care why.

A VIM is actually pretty simple too:  Run as if it was an inline VI, but change all wired input terminals to exactly match the incoming wire's data type, and then propagate any changes that causes through the VIM and see if it works afterwards.

In order for your wish to come true, the TSS would have to have some sort of special logic to investigate broken cases beyond the basic checks, looking for things that could never possibly pass.

The only alternative I can think of that doesn't involve NI recoding the TSS or you doing extensive testing after every rewrite is to write VIMs in such a way that there is no "default" case at the last frame of a TSS that works for any incoming data type, and that all frames do use an Assert of some kind.  If each frame works on one and only one data type, then any VI calling the VIM with that data type will break it.  I assume that one of the later frames that we don't see does something along the lines of just passing through the default value as a type if none of the other cases worked, and that's incompatible.

Though, if you're going to do something like that where you just have a list of 4-6 data types that are acceptable, making the VI into a polymorphic one where you just select the data type via a dropdown might work better.  That would sidestep the whole TSS issue so you never have to worry about "false" non-usable code messing up your "on purpose" non-usable code.

[CoastalMaineBird]

---

@Kyle97330 wrote:

The TSS has a pretty simple function: Find the first case that isn't broken.  It doesn't care why.

That's the part I was looking to get around.  It seems technically possible to have a class of breakage because of an ASSERT that fails , and breakage because of broken wires or other failures.  But I guess not.

I recall some examples somewhere which broke the case if an ARRAY SIZE connected to the input was broken, meaning that it's looking for ANY type of array.  Such a construct would fail my little game: you'd have to have different cases for [SGL],[DBL],[I32], etc. 

So, what I want is not possible.

Thanks for sharing your thoughts, Kyle.