Jump to content

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

Link to post
Share on other sites
  • 2 weeks later...
  • 2 weeks later...
  • 1 month later...

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?

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.

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.

  • Similar Content

    • By hooovahh
      Here is the Hooovahh Array VIMs.  This initial release contains VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques.  In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette. 
      Version 2.0 changed the suffix naming standard.  Updating may mean replacing calls to the new versions since the name on disk has changed.  This was for consistency and I'm sorry for breaking compatibility.  The added type defs in 2.0 may break compatibility too but these help avoid code breaking bugs since VIMs allowed any data type previously.
      Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels.  And a few functions have added performance based on other inputs.  For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted.  The Filter 1D array can also be more efficient if the input is known to not contain any duplicates.
      Because these packages contain VIMs, they require LabVIEW 2017 or newer.  Having these functions be VIMs mean all functions work with various array data types.  Included functions are:
      Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort
    • By hooovahh
      View File Hooovahh Array VIMs
      Here is the Hooovahh Array VIMs.  This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques.  In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette.
      Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels.  And a few functions have added performance based on other inputs.  For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted.  The Filter 1D array can also be more efficient if the input is known to not contain any duplicates.
      Because these packages contain VIMs, they require LabVIEW 2017 or newer.  Having these functions be VIMs mean all functions work with various array data types.  Included functions are:
      Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  
    • By Ryan Vallieu
      I have seemingly found an issue with the shipping example code for Nested Malleable VIs.  Another user has verified that he saw the same behavior in 2019.
       
      I am working through the examples and the presentation from NIWeek 2019.  In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed.  When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi.
      One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same.  The Equals.vi code looks identical, and the calling VIM look identical.  I posted on the LabVIEW NI.com forum here: 
      https://forums.ni.com/t5/LabVIEW/LabVIEW-2019-Malleable-VIs-Shipping-Examples-Lesson-2b-Nested/m-p/3966044/highlight/false#M1129678
       
      I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.
    • By the_mitten
      Has anyone found any properties or methods associated with malleable VIs? Specifically, I was hoping to find a way to invoke the "Convert Instance VI to Standard VI" function after confirming that a selected VI was indeed malleable. LabVIEW reports the class type of a selected malleable VI on the block diagram as a standard Sub VI, and I didn't see any properties/methods under the VI class.
       
      I'm exploring what it would look like to make a utility to convert a malleable VI into a polymorphic VI for the purpose of backwards compatibility. I'd like to have a reference library that uses malleable VIs but create a version that is still accessible to someone using older versions of LabVIEW that don't officially support malleables. 
    • By jacobson
      I am getting this strange error whenever I try to drop a .vim into a VI that is saved. If the VI is not saved, everything seems to work but as soon as I save it and try to drop in a .vim, I receive this edit time error.

      This happens to any .vim file, even blank ones that I have just created. If I double click on the error then it will highlight a specific object that I can delete but the object is otherwise invisible and unclickable. This started happening right after I tried to add a VIM through scripting. I can actually still add a VIM through scripting but it has some pretty interesting context help.

      So I guess the question of the post is what the heck did I do and how can I get LabVIEW to start behaving again.
×
×
  • Create New...

Important Information

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