Jump to content
X___

Types Must Match

Recommended Posts

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:

Types Must Match.png

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

Hidden Gems.png

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:

Context Help.png

 

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

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

SubarrayTypesMatch.png

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

SubarrayTypesMatch2.png

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

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