Types Must Match

[X___]

For those who have been playing with malleable VIs, the Type Specialization Structure has probably become a common sight and much abused tool.

The basic use of it is that if the action it performs is meaningless given one of the inputs, the included code will break and the next case will be tried.

This is great, but sometimes, it can be difficult to think of all possible variants of an action, and in particular, if the action needs to be different for two or more types, but two or more types are compatible with different codes, how to make sure which code will be executed with what type?

Enters the Types Must Match function:

I found this little gem in... Hidden Gems, within an odd-looking VI which I felt compelled to check out, Debug Write.vim

Open its diagram and light will shine, opening grandiose vistas and parallel universes remaining to be explored.

Of course, as the comment on the diagram says:

"This structure and the type-testing primitive functions it contains are not public LabVIEW features. They are experimental and should not be edited, copied, or used in other VIs without conducting extensive testing. See Context Help for details."

Here is the context help for Types Must Match:

 

My apologies if this all well-known among expert users, but I couldn't find it mentioned otherwise on the site...

[jacobson]

I remember AQ alluding to this in a few presentations but I assumed it was something to be added in future LV versions. Good to know it's in current versions as well.

[hooovahh]

Yes this is somewhat known and talked about, being able to white list a data type is important and I remember hearing black listing one would be possible at some point too but since that is for a future version of LabVIEW (2018?) it might not come.

That being said AQ has a philosophy that is pretty sound in most cases when it comes to VIMs.  The idea is you shouldn't have to white list data types, and really the true propegation of the code you wrote should dictate what data types are possible.  If the code you wrote accepted the data type and worked fine, then it shouldn't need this function to force only that data type.

While this is true most of the time I can think of a few places where the data type might be accepted, but cause unexpected results.  Imagine if I wrote a randomize string function.  It takes in a string, randomizes its characters, and outputs a new string.  If this were a VIM it would also work with the 2D picture control since this has a data type that coerces to a string, and many string functions work on this data type.  Of course randomizing a pictures bytes will result in garbage data so one might want to force that function to only work on the string, and not the picture data type which can coerce to a string.  Here in my opinion is a good place to white list the data type, allowing for possibly another custom set of code which randomizes the picture in a known way.

Anyway what I'm trying to say is personally I will try to use white listing (and black listing if it exists) as rarely as I can when writing VIMs.  But still won't mind using them in places where I need them.

[X___]

Attached are two VIs containing the two objects discussed above.

Place them in your "Favorites" palette, choosing to "Place VI Content" for easy access.

Types Must Match.vi

Type Specialization Structure.vi

[Aristos Queue]

You'll find more delights regarding that primitive and the structure if you join the LV 2018 beta program...

http://ni.com/beta

along with some other major advances in malleable VI technology.

[GregSands]

I've started trying to use .vim files a little, and have a couple of questions:

1. Looks like a typedef doesn't match with the same structure without a typedef, correct?  I would have thought that if the internal data matches, it should be ok.

2. I get this interesting mismatch between an array and a sub-array:

But if the connection is the other way around, I get this error:

I would have hoped that either (or both) would be ok.  I'm not in the beta, so don't know if this has already changed, or is likely to?

[hooovahh]

If AQ were here he might say something like "This is why these features aren't officially in LabVIEW yet"  I too have noticed that the brokenness when sometimes wiring the Must Match one way versus the other.  I am in the beta but honestly don't remember seeing if this worked better, and couldn't say if I did know.  Just wait a couple months hopefully 2018 will be released at NI week.  As for the type def I think it is functioning the way it should.  One common use I've heard mentioned is you may want a function to work if the input is a 2D picture control but behave differently if the input is a string.  Well those both coerce to the same data type, but the Must Match will reject one or the other based on the input.