XNode Editor

[hooovahh]

UPDATE: These first few revisions are more or less broken.  The first fully working version can be found here.

 

8 Years ago the first version of the XNode Manager was posted to the code repository, and it hasn't seen an update since 2009.  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.  I didn't spend too much time on it, and I don't think it replicates all the XNode Manager functionality, but it does have some major improvements.

 

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.

 

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.  Saved in 2013, but could probably back save earlier if requested.

 

If I get more time I'll add some features, and add it to the Code Repository.

XNode Editor.zip

[ShaunR]

I'm not sure how many were added over time but wow, that's a lot of abilities. I was confused with the few I knew of in 2009. Kudos for enumerating them regardless of LV version-that's sweet! I remember my original forays back in the day just to prove I could write them then forgot about them because they were just awful to create and maintain.

 

When it comes to Xnodes/controls. There is only one aspect that I'm particularly interested in and that is a replacement for a polymorphic VI. I have been thinking for a while that having a tool for creating a xnode that replicates a polymorphic VIs behaviour is quite doable - define terminals, select supported types for each terminal along with a "insert your code here" VI and press "make" but then I look at creating an xnode and say "nah. Too hard"

 

I'm a bit disappointed that NI have just made a rats nest bigger rather than trying to make creating xnodes easier. It was an attempt to placate those of us that wanted to create our own native controls and indicators after all. Hopefully with your fresh enthusiasm and new interface, people will add plugins (hint, hint) to automate various common tasks beyond template creation to make Xnodes a more common and viable solution.

Edited June 27, 2015 by ShaunR

[pawhan11]

That is great job   

[hooovahh]

Hopefully with your fresh enthusiasm and new interface, people will add plugins (hint, hint) to automate various common tasks beyond template creation to make Xnodes a more common and viable solution.

Yeah we'll see, my initial thought is these couple of VIs aren't going to have much of an impact.  If I am able to make tools that make XNodes, then likely others are able to make XNodes already.  This might make, making XNodes easier, but it doesn't make understanding them easier.  For me that's done by looking at what other XNodes have been made, and there are a couple good ones in the Code Repository.

 

I am interested too in the progress of XNode development from NI's side.  They not only add new abilities but update older ones.  Like the GetTerms for instance added new data to their terminals to handle "English Name".  So they are making an effort to continue updating this technology, for their internal uses anyway.

[ShaunR]

 If I am able to make tools that make XNodes, then likely others are able to make XNodes already.  This might make, making XNodes easier, but it doesn't make understanding them easier

 

I'm waiting for your tools so I don't have to understand them Bring the others together with your IDE

[JackDunaway]

I'm a bit disappointed that NI have just made a rats nest bigger rather than trying to make creating xnodes easier.

 

I hear your sentiment, but want to at least commend the continued investment by NI into more XNode capability/stability over the past several years. But yes, they remain hard to develop and opaque and under-powered and quirky and rude to LVClass types, but hooovahh's efforts here will help some of these issues :-)

 

 

When it comes to Xnodes/controls. There is only one aspect that I'm particularly interested in and that is a replacement for a polymorphic VI.

 

Here, Generics could be a lighter-weight syntax to accomplish the same thing (where XNodes are currently the only reliable implementation of Generics in LabVIEW), but XNodes can do *way* cooler things in the IDE than just type propagation and define function signatures. But totally agree with the sentiment that replacing PolyVIs is keen and high-value with C++esque Templates

[hooovahh]

Personally I didn't think Generics was the right approach.  XNodes already do what Generics don't, or sorta did in some use cases, some of the time.  My point is Generics had a subset of features that XNodes did.  Edit time polymorphics exist with XNodes, along with a whole slew of other cool features.  Why create another way to solve the same problem?  Focus on XNodes and on making that interface robust, stable, documented, etc.  Then using scripting you can write a utility that makes a "Generic" which is just an XNode.  

 

That is a challenge that we can accomplish today.  Given a VI as a template, create an XNode that accepts various things as the input, and then automatically change the output.  Whos up for the challenge?

[ShaunR]

Personally I didn't think Generics was the right approach.  XNodes already do what Generics don't, or sorta did in some use cases, some of the time.  My point is Generics had a subset of features that XNodes did.  Edit time polymorphics exist with XNodes, along with a whole slew of other cool features.  Why create another way to solve the same problem?  Focus on XNodes and on making that interface robust, stable, documented, etc.  Then using scripting you can write a utility that makes a "Generic" which is just an XNode.  

 

That is a challenge that we can accomplish today.  Given a VI as a template, create an XNode that accepts various things as the input, and then automatically change the output.  Whos up for the challenge?

 

How are you thinking this would work with your IDE? Some sort of plugin recipe? Would you have an "adapt inputs" script/plugin and "adapt outputs" script/plugin and a way of concatenating them together around a Template VI? A bespoke "scripting language" for Xnodes? What is your vision here?

Edited June 29, 2015 by ShaunR

[hooovahh]

So I was thinking this.  You run Tools >> Create Adaptive XNode (don't go looking it doesn't exist yet).  There you provide a path to a template VI.  Using scripting we read the terminal inputs and show them to the user in a window asking how their the inputs should be allowed to accept various types.  I was thinking there is a list of the common data types, (string, boolean, path, etc) or limit to an array of common types (string, boolean, etc) or a cluster where limits could be set.  Or have an option for accept all data types.  There would probably need to be some additional logic like "Input 1" can be an array of any size of any data type, but can't accept scalars, and "Input 2" must be the same data type as "Input 1" but with one less dimension to the array, or one greater or whatever.

 

After specifying the template VI, and what rules each input should have, you choose to set which outputs are adaptive.  These will change based on the code in the template so I don't think additional rules need to be set on the outputs.

 

Then you hit "Go" and an XNode is made, (copying a already made one to be easiest) which sets the template VI, and sets what the terminal behavior is by editing the constants in the GetTerms, and AdaptToInputs abilities.  For more control I thought about having a blank VI that could be edited which did additional operations on the VI which is ran after the GenerateCode.  There are a few times when I needed to do more than just drop in a template VI but also needed to set some block diagram constants based on the input data types as well.

 

Then what you have is a nice little XNode that behaves like a Generic, but is an XNode and gives control over how the VI can be manipulated as various inputs are changed.

[ShaunR]

Wouldn't adaptive just be an option? A bit like you have the static and dynamic for classes from the compane.

Edited June 29, 2015 by ShaunR

[hooovahh]

Wouldn't adaptive just be an option? A bit like you have the static and dynamic for classes from the compane.

Well sure but...well I'll need to check it but I don't think it can always work like that.  Say for instance I take one of the OpenG array functions, the Search Array.  You give it a 1D array of some data, and you give it a scalar of that same data type to search for and it returns the array of indexes that match.  In this case if I set both the Array, and the Element Data to adaptive then that means that both inputs accept any data type.  The Array input could be a cluster, and the Element Data could be a variant and it would wire up just fine without any broken wires.  

 

But the XNode VI that is scripted (the template) will be broken, and the error returned won't be clear to the user of the XNode because the error will be coming from within a VI that they didn't know was scripted and they can't see inside.  Adaptive is great if you really mean you accept any data type (like my Variant Repository) but seldom do you really want to accept anything.  You may want rules like this input must be an array, and this input must be a scalar.  Generics would similarly need some kind of bounds on their inputs.

[lordexod]

It already exists, is called "function blocks" http://zone.ni.com/reference/en-XX/help/370622M-01/TOC26.htm , which are created using the "FB Core.xnode"

[hooovahh]

It already exists, is called "function blocks" http://zone.ni.com/reference/en-XX/help/370622M-01/TOC26.htm , which are created using the "FB Core.xnode"

While I don't think that was exactly what I'm talking about, I think the spirit of it is true.  Basically you have a XNode that is made to be an interface for a subVI.  You tell the XNode what subVI to interface with and it draw the icon, and creates a block diagram node with inputs and outputs.  You can then double click the XNode and configure those inputs and outputs to come from like the terminal or networked shared variable.

 

I suppose theoretically you could make a generic XNode once, that you can insert any VI into, then double click and tell it what rules the XNode's inputs should have.  Then that copy of that XNode will behave with those rules when wired.

 

The problem I see with this is the settings for that XNode live with that XNode, and could be edited by the user of the XNode.  In general this is not something I would want.  When I make something like the OpenG Search Array, I want those settings to be a thing that is the same for every copy of that XNode.  Instead of making an interface to a subVI, I'd prefer making a new XNode for each function.  But maybe that's because I'm in the old way of thinking, and those settings could be somehow saved with the template VI.  I'm still not convinced this would be the right way.  It would almost be like making a single wrapper for all adaptive VIs of this type, and I'd rather have a wrapper for each function, so that if custom things need to be done, they can.

[MikaelH]

So if I get an error in "APP:XNode.Create", what am I missing?

//Mike

[lordexod]

So if I get an error in "APP:XNode.Create", what am I missing?

XNodeCreateError.png

//Mike

 You must have a license.

[hooovahh]

 You must have a license.

Oh...well this is useless isn't it?  I guess Uh...well back to the drawing board sorry.  Maybe I'll look into updating the current method of the XNode Manager instead.  That sucks.

 

Okay looks like I'm learning things others already knew, but all the abilities and some utility VIs can be found here.

 

<LabVIEW>\resource\Framework\Providers\xi

 

I'm going to look into leveraging these to make the XNode Editor work again.

[lordexod]

Can bypass this detail.

NewXNode.vi

[hooovahh]

Can bypass this detail.

NewXNode.vi

Well sure but I wanted to avoid this technique because when LabVIEW 2015 comes out, this will make XNodes in the 2014 version.  Just like how now XNodes made with the XNode Manager make 8.2 XNodes.  I thought that by using the built in invoke node I could make a new XNode that was for that current version of LabVIEW.  But it looks like this isn't possible, and your method, which is essentially the method used in the XNode Manager, is the only way at the moment.

 

EDIT:  Actually it isn't that bad, if you open a blank XNode, then perform an open, it automatically adds the State Ability, and saving the library fixes things nicely.

[JackDunaway]

Well sure but I wanted to avoid this technique because when LabVIEW 2015 comes out, this will make XNodes in the 2014 version.

 

Can bypass this detail too:

 

[lordexod]

You can always change the version.

NewXNode_v2.vi

[lordexod]

This is interesting, Ability, Method and Property Folder in XNode:

 

"NI" probably also to develops XNodes or XClass (XNode + Class).

[hooovahh]

Can bypass this detail too:

Yeah I made an edit basically saying you can resave the XNode and it fixes these minor concerns.  I then had issues with the Add Ability method which I think is also restricted license issues.  I also saw some oddness when trying to open a XNode that doesn't have a control, it some times would add the State and some times wouldn't.  And then I even saw times when using the Add Ability would return an error saying it can't add that type of ability, but I know it can.

[hooovahh]

GRRRRR, so many work arounds.  I really didn't want to resort to having to parse the XML.  NI has the functions for navigating XNodes just like libraries but they all either don't act the same, or don't work at all without a license.  On top of that they some times use alternate names for some abilities, like how OnRefeeChange might some times be called RefeeChanged and the right one needs to be in the right place or things don't work.  Also some Abilities have other tags like NI.XItem.RuntimeAbility.

 

I wanted to use the Add Ability function, seems like a great idea and takes care of a bunch of things in one function.  But that doesn't work, so you either bring along templates of each ability or you copy them from the resource folder.  But then why do they include Fatal Error Out?

 

Then I found that neat little function that will tell you a Ability, given a ProjectItem reference.  But guess what?  List Members doesn't work without a license, so no getting members for this function.  That also means no finding what the State control is.

 

So at the end of all this I'm 90% there but compromised a lot of the modularity, and have to compromise more doing more XML parsing...

 

So here is what I have.  It does make the XNode, and makes abilities.  But doesn't replace the state control, Fatal error might be there and need to be deleted (the broken arrow will tell you this) and the list of existing members in the listbox doesn't work.

XNode Editor Tool Not Quite There.zip

[ShaunR]

Just thinking on the fly here. Aren't all the capabilities to create and modify an Xnode available in the project window? Could we get around many of these issues by scripting that rather than creating an Xnode from scratch with a bespoke UI?

[hooovahh]

The first post I made created the XNode and abilities using scripting.  It would create the XNode, which is a library, then invoke the Add Ability where you specify the ability to add.  Both the Create XNode, and the Add Ability don't work if you don't have a XNode license.  Additionally List Members which usually tells you what items are in a library also doesn't work without a license.

 

So I'm not sure what other scripting functions you could try from the project window.  Just like with adding a VI to a project, you can't invoke a Create VI on a project using scripting.  You first create the VI, then use the Add Item.  And at this point we can't create the item, but we could probably add it if one was made.

 

The only other hope I had was to see if the Project Provider Framework was used to implement the XNode creation in the project window.  It wasn't, that would have been too easy.

 

Just so I'm not completely defeated I figured I could at least post a XNode which has all the abilities on it for a version of LabVIEW.  So if you want a 2013 XNode attached is one that has every ability.  If you don't like the name, you can open the XNode in LabVIEW, and perform a rename which will resave all the members.  That part does work without a license.  To remove an Ability delete the VI, then open the XNode in a text editor, and remove the Item section for that ability.  There are plenty of deprecated abilities that I probably should have included.  Like how Build Menu has 4 older versions when you should probably just use the newest.

XNode All Abilities 2013.zip