Jump to content

Re-Label Wire Xnode (useful for event registration)


Recommended Posts

I put together a simple xnode to relabel event registration reference wires that feed into dynamic events of event structures.  With the increasing use of event based messaging systems, I found myself manually changing the name of event registration references to clarify the event name when multiple event registration references were used in an object. I did this by manually creating a cluster constant on the build cluster before the dynamic registration terminal on the event structure and renaming each registration reference.  Being a lazy programmer, this seemed tedious after a few times so I decided to attempt to create an Xnode to accomplish the same thing faster.   This video shows the "problem" and the potential solution using the xnode: 

Re-Label Xnode - Event Registration

Here's another example showing another use case with ShaunR's VIM HAL Demo code:

Re-Label Use Case ShaunR HAL Demo

This may have been done before or there may be an easier way to do this, but I wanted to throw it out here to see if there's any interest and to see if people will try it out and give feedback.  I've found it works best using quick drop for initial use (highlight wire, CTRL-Space,type re-label, CTRL-I, type new name in dialog) and for replacing or renaming an existing instance on the diagram (highlight existing xnode, CTRL-Space, type re-label, CTRL-P, type revised name in dialog).  You can also use directly from the palette, but I found much faster from quick drop and also seen a couple crashes replacing through the pallete.  

The Double Click ability is also a work in progress.  Its purpose is to allow you to quickly rename the relabel with the same dialog box, but when it executes it breaks the wire on the output connection.  You can still re-wire it to the event structure, but you will have to open the Event Structure Edit Events menu to get the event to "Re-link".  Something I'm trying to avoid.

The Xnode generated code is simply a pass through wire with the output terminal renamed to the label of your choice.  This seems to update attached event structures.

Relabel in HAL.png

- B

sobosoft_llc_lib_diagram_tools-1.0.4.1.vip

  • Like 2
Link to post
Share on other sites
  • 1 month later...
On 7/11/2016 at 9:30 AM, lordexod said:

New non-xnode update for "Re-Label Wire Xnode" popup plugin Relabelizer.llb , copy to ..\LabVIEW <version>\resource\plugins\PopupMenus\edit time panel and diagram.

lordexod.  I tried your new Relabelizer popup plugin and its a nice solution.  Seems to have a small bug that the terminals may not get wired up properly depending on where you right click to execute the script. See:

Relabilizer Plugin Bug

I still like my solution better :) because it looks better on diagram.  Yours is more elegant because of its simplicity though.

Link to post
Share on other sites
19 minutes ago, bbean said:

lordexod.  I tried your new Relabelizer popup plugin and its a nice solution.  Seems to have a small bug that the terminals may not get wired up properly depending on where you right click to execute the script. See:

Relabilizer Plugin Bug

I still like my solution better :) because it looks better on diagram.  Yours is more elegant because of its simplicity though.

I'm still waiting for you to modify the named event macro to be an xnode that labels the event ref the same as the indicator label and makes the need for the re-labeler in your example, moot :D  (Especially now that it looks like it won't be fixed in LV 2016)

Edited by ShaunR
Link to post
Share on other sites
On 7/15/2016 at 7:34 AM, ShaunR said:

I'm still waiting for you to modify the named event macro to be an xnode that labels the event ref the same as the indicator label and makes the need for the re-labeler in your example, moot :D  (Especially now that it looks like it won't be fixed in LV 2016)

Sorry, I'm a little tied up right now with work stuff.  maybe we could chat offline regarding what you want in detail, so I don't accidentally go off on a tangent when/if I do actually work on it.  I think what was stopping me in my tracks before was figuring out how to determine the "name" to put on the output control based on an upstream connection (input wire)

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
      View File XNode Editor
      8 Years ago the first version of the XNode Manager was posted to the code repository in an attempt to allow the editing of XNodes.  Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality.
      The XNode Manager had a blank XNode, and blank Abilities that it just made copies of.  This is fine but then the abilities and XNode are quite old.  There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager.  My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create.  Then VI server is used to create the XNode, State control, and Abilities.  This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it.  It also reads in the XNode Ability descriptions to help understand how to use the new ability VIs.
      In addition to being able to create and edit XNodes, you also can edit the XNode icon, and description, along with adding any new abilities.
      Be aware this uses several private functions, and several undocumented features that could be potentially bad.  I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable.  But at the end of the day if it blows up and crashes, don't be surprised, you've been warned.  The original thread with discussion and progress on this tool was started here.

      Submitter hooovahh Submitted 03/15/2017 Category XNodes LabVIEW Version  
    • By Taylorh140
      After working on the set cluster element by name xnode, it made me realize i could use the same concept to convert a variant array to a cluster. The technique is actually pretty simple, the xnode generates a case structure for each element in a cluster in cluster order, wherein a bundle by name is used to set the value and an unbundle by name is used to get the type, a variant to data is used to convert the data. This has some benefits over some methods, you are not limited to 255 elements, although that is not usually the case some of us are paranoid that clusterosaurus giganticous will be larger than expected. It also has a draw back  that is that when converting from a variant array all the elements must have unique, non-blank names, and this is usually the case. 

      I think this technique (though very brute-force) might be useful for some other things let me know what you guys think.

      VariantArrayToCluster.zip
    • By Taylorh140
      This Xnode allows setting a cluster element by label string without using references. I pulled a great deal of inspiration from Hooovahhs Variant Array to cluster xnode, which i suppose this could be used for, another benefit is its not limited to 255 elements. Its mostly experimental because I haven't used it much. 
       
      SetClusterElement.zip

      SetClusterElementLV2013.zip
    • By UnlikelyNomad
      I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible.
      That said, I've started on my first ever XNode and it's a cross between an unbundle by name node and the -> operator in C. It functions just like a normal UBN, however it was also pull items out of DVRs. Having to plop down a UBN to pull out the reference from the class, an in place node to dereference, and then another UBN to pull the data out gets tiresome after about the 100th property VI gets written.
      So far I've gotten the node drawing completed (except for data type coloring of the labels), the type inferencing from the input wire, and the popup menu for selecting an item. Next up will be the menu selection code so that the names will finally show up in the terminals! Then I get the daunting task of scripting up the GenerateCode ability >_>
      Anyone interested in something like this? Following this will be a match to the Bundle by Name node that serves the same purpose except to write the items.



    • By hooovahh
      8 Years ago the first version of the XNode Manager was posted to the code repository in an attempt to allow the editing of XNodes.  Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality.
      The XNode Manager had a blank XNode, and blank Abilities that it just made copies of.  This is fine but then the abilities and XNode are quite old.  There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager.  My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create.  Then VI server is used to create the XNode, State control, and Abilities.  This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it.  It also reads in the XNode Ability descriptions to help understand how to use the new ability VIs.
      In addition to being able to create and edit XNodes, you also can edit the XNode icon, and description, along with adding any new abilities.
      Be aware this uses several private functions, and several undocumented features that could be potentially bad.  I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable.  But at the end of the day if it blows up and crashes, don't be surprised, you've been warned.  The original thread with discussion and progress on this tool was started here.

×
×
  • Create New...

Important Information

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