Jump to content
bbean

Change Detection VI Macro (.vim)

Recommended Posts

After reading this LabVIEW Idea exchange request:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi-p/920487

 

I was inspired to create VI macro(s) to attempt to address the problem mentioned in the request.  Attached is my first attempt and I'm looking for feedback since I know people here have strong opinions.   The benefit of this method is that a single vim (or 2 could replace a polymorphic VI with over 48 separate VIs....unless I'm missing something.  I know that VI macros are not officially supported by NI, but that hasn't stopped us from using unsupported features before.  Some people have probably already done something like this, but I couldn't find an example.

 

To use the files, unzip them and copy them all to your \LabVIEW (version)\user.lib\macros\ directory.  

Create the directory if it does not exist.  For example: C:\Program Files (x86)\National Instruments\LabVIEW 2014\user.lib\macros\
 
And as described in the wait-ms-with pass through post below, modify your LabVIEW.ini file to have the following
    ExternalNodesEnabled=True
and Optionally
    XNodeWizardMode=True
 

 

Open the Example Changed.vi and review.

Changed Example.zip

  • Like 1

Share this post


Link to post
Share on other sites

Yup. Good example of where a VIM wipes the floor with the other solutions in terms of conciseness and ease of implementing..

Share this post


Link to post
Share on other sites

VI Macros (VIM) supports "XMacro.xnode".

 

Are you suggesting one could copy/modify that Xnode to extend its capabilities to their liking?

Share this post


Link to post
Share on other sites

vim file works with any path, not only "user.lib\macros".

XMacro.xnode - is the engine of the vi macros.

Share this post


Link to post
Share on other sites

VIMs in my mind are the express VI of type adaption.  If your use cases are completely within the capabilities of a DAQ Assistant function, then you are going to love how simple it is to use.  But if your needs don't fit those cases, then you need to write DAQ code using the DAQmx API.  Same here.  

 

If you want XNode like features like mouse clicking, double clicking, right clicking, running a VI when a new type is wired, etc, then you're going to have to do it in an XNode, not a VIM.  What we really need is some scripting code that generates XNodes, with the features of VIMs, then you have the simplicity of VIMs, with the flexibility of XNodes.  The fact that VIMs just call the code in <LV Install>\resource\GenericLabVIEW makes it look possible.

Share this post


Link to post
Share on other sites

Okay a couple more things I learned.  The first is something already does happen when you change the type on your VIM, two VIs are ran, 

 

<LV Install>\resource\GenericLabVIEW\GenericLabVIEW_AdaptToInputs.vi

and optionally

<LV Install>\resource\GenericLabVIEW\GenericLabVIEW_GenerateCode.vi

 

If you look at some of the XNodes posted in the code repository they follow the same design.  Basically if you re-wire a normal XNode, then the adapt ability is ran.  Now if the data type of a terminal you cared about changed, you may need to go regenerate the code.  Just like our XNodes, this VIM works in a similar way and these two VIs are ran, with the second one being optional.

 

Next I also discovered something that basically breaks VIMs, but I think they are intended to allow for making some inputs adaptive, and some not.  Imagine you have a delete from array, like the OpenG ones.  It takes an array of something, and an array of indexes.  If you turn this into a VIM both inputs are adaptive, but that isn't what you really want, indexes should always be an array of I32.  Well if you put on your front panel of a VI a control named "Generic LabVIEW:Adapt To Type States", have the data type be a 2D array where columns 0 is control labels, and column 1 defines what that control should be.  I believe FT means fixed, and unspecified are adaptive (which is why all inputs are adaptive by default).  Of course when I go to use this it doesn't do some other things properly, like icon, and terminals aren't right so this isn't very useful yet, but I was just so excited I had to share, even if it doesn't do anything yet.  Of course even if you do get some inputs adaptive and some fixed, you still have the issue of limiting some inputs to say scalar, or say 1D array but no other size.  That again is where the flexibility of XNodes is needed at the moment.

  • Like 1

Share this post


Link to post
Share on other sites

 Well if you put on your front panel of a VI a control named "Generic LabVIEW:Adapt To Type States", have the data type be a 2D array where columns 0 is control labels, and column 1 defines what that control should be.  I believe FT means fixed, and unspecified are adaptive (which is why all inputs are adaptive by default).  Of course when I go to use this it doesn't do some other things properly, like icon, and terminals aren't right so this isn't very useful yet, but I was just so excited I had to share, even if it doesn't do anything yet.  Of course even if you do get some inputs adaptive and some fixed, you still have the issue of limiting some inputs to say scalar, or say 1D array but no other size.  That again is where the flexibility of XNodes is needed at the moment.

Interesting.  Good find.  If you look at the front panel enumerator for Terminal Behavior there is another option "Depends" and also a "dependency chain array" control and "index of dependency" control below it.  Any speculation as to what that option would be for.?

Share this post


Link to post
Share on other sites

Okay a couple more things I learned.  The first is something already does happen when you change the type on your VIM, two VIs are ran, 

 

<LV Install>\resource\GenericLabVIEW\GenericLabVIEW_AdaptToInputs.vi

and optionally

<LV Install>\resource\GenericLabVIEW\GenericLabVIEW_GenerateCode.vi

 

If you look at some of the XNodes posted in the code repository they follow the same design.  Basically if you re-wire a normal XNode, then the adapt ability is ran.  Now if the data type of a terminal you cared about changed, you may need to go regenerate the code.  Just like our XNodes, this VIM works in a similar way and these two VIs are ran, with the second one being optional.

 

Next I also discovered something that basically breaks VIMs, but I think they are intended to allow for making some inputs adaptive, and some not.  Imagine you have a delete from array, like the OpenG ones.  It takes an array of something, and an array of indexes.  If you turn this into a VIM both inputs are adaptive, but that isn't what you really want, indexes should always be an array of I32.  Well if you put on your front panel of a VI a control named "Generic LabVIEW:Adapt To Type States", have the data type be a 2D array where columns 0 is control labels, and column 1 defines what that control should be.  I believe FT means fixed, and unspecified are adaptive (which is why all inputs are adaptive by default).  Of course when I go to use this it doesn't do some other things properly, like icon, and terminals aren't right so this isn't very useful yet, but I was just so excited I had to share, even if it doesn't do anything yet.  Of course even if you do get some inputs adaptive and some fixed, you still have the issue of limiting some inputs to say scalar, or say 1D array but no other size.  That again is where the flexibility of XNodes is needed at the moment.

 

I don't see why all VI terminals can't have an option to adapt to type. We have them for CLFN which is very useful. It'd be great if it was just a checkmark on the compane like the "Required" or "Dynamic Dispatch". Then it would be easy to fix the type of controls/inidcators and mix-n-match adaptive and static types and we wouldn't even need a special type of VI/Xnode.

Share this post


Link to post
Share on other sites

Any speculation as to what that option would be for.?

It's hard to say, I honestly think this functionality just isn't complete, or if it is I'm missing some key component.  The Dependency Chain is suppose to be be provided in the same way that a terminal is told to be adaptive or not, using that control on the front panel.  Look at the NamesInFullyQualifiedName.vi, it generates the Dependency Chain.  If you put in something like "a.b" you get two elements in the output "a", and "b", if you put in something like "[1a.b] you get two items, first has an index of 1, which is specified, and the second is "b]".  I think this is some kind of way of specifying specific data types that a terminal can be, not just "Adaptive" changing to anything, or "Fixed" not changing, but instead changing to specific types.

 

Personally if I were to implement something like this (and I've thought about it) I would specify the types that a terminal could be differently.  Maybe provide a set of options in a wizard stating which controls can be what, and then that information could be saved as tags on that control, or maybe in a subfolder where control references could be which applied to that control.  Having it be another control on the FP named a specific way, with data in it a specific way seems clunky, especially if that control isn't hidden.  But even if it is as a developer I'd wonder why this random control is there which doesn't do anything.  I think VI Analyzer would probably flag that as unused code that could be deleted.

 

I don't see why all VI terminals can't have an option to adapt to type. We have them for CLFN which is very useful. It'd be great if it was just a checkmark on the compane like the "Required" or "Dynamic Dispatch". Then it would be easy to fix the type of controls/inidcators and mix-n-match adaptive and static types and we wouldn't even need a special type of VI/Xnode.

Oh don't get me wrong I think every terminal should have the option to be adaptive.  But under some circumstances the developer of the function might want inputs to have a limited number of data types that they support.  Like in the example I gave if I have a Delete From Array, and I provide a 1D array of Doubles, and I want to delete and index, but the index I specify is a string data type with the value of "blah" what should my function do?  It is clear that an index input should not adapt to any data type, but only a limited number.  Even the array input should be limited to only 1D arrays of anything, not scalars or multi dimensional arrays, unless the function can handle those types.

 

Having it be a right click option on a connector pane seems like a perfect fit.  Imagine if you right click and choose adaptive, and then are given a dialog where you specify what types it should adapt to.  Any data type?  Any 1D array?  Any cluster? Any Numeric of N dimensions?  Then in your code for that VI you could read what the type is, and do specific things if needed.  I honestly think we could make something like this today, just given enough time.

 

BTW sorry for hijacking your thread.

Share this post


Link to post
Share on other sites

 Then in your code for that VI you could read what the type is, and do specific things if needed.  I honestly think we could make something like this today, just given enough time.

 

In the spirit of dreaming, I think what would also add to this idea would be a new LabVIEW primitive called TypeDetectDisableCase Structure that would work like a case selector for datatypes, but would automagically (like an Xnode) disable the irrelevant case and enable the relevant type case for the inputs.  I think having all the code in one VI (even for different types) is key so you don't end up with a Xnode solution that circles back to the polymorphic situation where you have a bunch of template subVIs to manage.

Share this post


Link to post
Share on other sites

I think having all the code in one VI (even for different types) is key so you don't end up with a Xnode solution that circles back to the polymorphic situation where you have a bunch of template subVIs to manage.

Well NI sorta tried that and it was called External Nodes and it wasn't flexible enough.  And to be fair you don't need N templates of subVIs to manage the different permutations, it is just the most straight forward way.  I've had an XNode where there are multiple disabled diagram cases, and one case will get enabled based on the options selected.  If you code in the smartness then you don't necessarily end up with multiple templates.  Heck you don't have to even have one template you can write the VI from scratch, but again that isn't the most straight forward solution, so it seldom is used.

 

I guess one down side I see from accepting multiple data types, then having one template VI read the data type, and then act differently based on it, is that then there is this extra overhead that wouldn't have been needed.  I mean the XNode (and VIM) can know the data type it is being used on, and again if the logic is made, you don't need to do things like read the data type and act one way or another, it's just simpler this way.

Share this post


Link to post
Share on other sites

Instead replace vi to vim.

Macroizer.llb copy to "..\resource\plugins\PopupMenus\edit time panel and diagram" and right-click on subvi and "Convert To Macro". 

Share this post


Link to post
Share on other sites

Instead replace vi to vim.

attachicon.gifMacroizer.llb copy to "..\resource\plugins\PopupMenus\edit time panel and diagram" and right-click on subvi and "Convert To Macro". 

Been waiting for an excuse to install 2015

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.


  • Similar Content

    • By Bas de Jong
      Hello, I'm trying to display an animated GIF on the front panel. This gif should be loaded programmatically based on some user event. My google search led me to use the OpenG Read GIF File (Animated)__ogtk.vi file. However, loading a GIF is extremely slow. It takes almost 20 seconds to execute the vi when I load the attached GIF (I found randomly on the internet). Is this normal? And if so, is there a way to load a gif faster? Because I need to load several and I cannot afford to load maybe 2 minutes only for the gifs.

    • 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 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  
    • By 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...
    • By hooovahh
      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 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 fennectp
      Hi all,
       
      I've got a customer that wants to zip/unzip files on their cRIO-9035, so I had them playing with the OpenG Zip tools to see if it would fit their needs. Although they've found that they can zip files on their cRIO just fine, they find that they get disconnected from their RT target and the shell shows the following error message:
      LabVIEW caught a fatal signal 15.0 - Recieved SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x0x10000000 stdin: is not a tty  
      The zip file they're testing with includes two simple .txt files with short strings in them ("booya" and "booya2"). This file unzips just fine on the host PC with the "ZLIB Extract All Files To Dir" VI, but when copied over to the cRIO and unzipped via the same VI, it only unzips the first text file and the resulting file doesn't have any text in it.
      I've attached a copy of the project and the zip file I used to reproduce this behavior using a cRIO-9033 that I had on hand. (The only thing I can't provide is the cRIO >_<)
      Could anybody tell me what I'm doing wrong? Any suggestions as to what other workarounds I could take to zip/unzip files on a LinuxRT target would also be very much appreciated!
       
      Regards,

      Tamon
      Unzip on cRIO-9033.zip
×
×
  • Create New...

Important Information

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