Simple Xnode generation

[pawhan11]

Hello,

 

I have some string data that is written in format *x*xxxxx*xxxx*xxxxxxxx*xxxx*xx,xxxx*. There are data elements are separated by *. I want to make xnode that will convert this data into cluster or 1D array. Types of that data will be only strings , numerics and booleans. This is very like in DB connectivity toolkit. I have xnode manager but all xnodes that I find from NI are password protected and i can;t take a look how this is made. 

Do You know where to start looking for some good examples?

[hooovahh]

Not all XNodes are passworded.  But I'm guessing all of NI's ones recently are.  Here are some from the community that can be picked appart.

 

https://lavag.org/files/category/10-xnodes/

 

So what defines the data types of the cluster?  Will it be another input?

[pawhan11]

Thanks for reply

 

I want input to be array or cluster defined by user that will convert my string accordingly. Here is image how I see that:

 

And i think ahat are all cases than can happen when comes to data types. in DB toolkit this works in similar way. 

This data comes from PLC and is mostly used to archive something DB or sent some commands. It is annoying to do the same all over by adapting this data accordingly after read

Edited February 3, 2015 by pawhan11

[hooovahh]

Yeah that's pretty doable.  I'm guessing you saw this already but I made an XNode that takes an array of variant and turns it into a cluster, without using that toolkit.  That function is surprisingly inefficent and mine is very simple.

 

https://lavag.org/topic/18520-database-variant-to-data-function/#entry111141

 

What you'll likely need to do is convert the string into an array of string.  Then read in the cluster type that is wired, and then go into a for loop, for each element in the cluster, and for each element in the array of string.  You can then deal with data as variants so your output will be a 1D array of variants, in the types you want, then come up with a way of converting that array of variants back into the cluster in a similar way to what I did.

 

Not impossible, but you'll have a lot of playing around until you figure it out.  I hope you are good at scripting.  Oh and if you do come up with something, the community would appreciate it if you shared it when you are done.

[pawhan11]

Thanks for help and pointing me in right direction   . One last question.

Xnode manager is the best tool to play with Xnodes?

[hooovahh]

Xnode manager is the best tool to play with Xnodes?

I've wanted for some time now to make an improved version that integrates with LabVIEW better, but I don't know if I'll ever get around to it.

[pawhan11]

I have made converting vi and it seems that it was the easiest part. Now I just need to replace input and output accordingly with scripting?

Vi is attached

 

When most of subvis in xnode are clear to me  I have hard time understanding how Insert and Write Xnode template.vi created by You works. Could You explain it to me??

template.vi

Edited February 4, 2015 by pawhan11

[hooovahh]

Ahh okay, lets get to the meat of the XNode.  Good job by the way in making the template I think everything is how I would have done it more or less.  

 

You'll need to have that cluster be a control.  Then wire it to the Variant to Data you have at the end, and make an indicator for it.  Both these terminals will be adaptive in the GetTerms function.  What this will mean is they will accept any data type as the input, and the output will be changed to whatever is needed, which in this case will be the same as the input.  In the AdaptToInputs you can read the type of the input, and if it isn't a cluster, you can choose to then go back to GetTerms, where you can break the wire for that adaptive input.  This way it will accept any input, as long as it is a cluster.  Several of my XNodes do this like the circular buffer on init when you are defining the type.  The type is adaptive accepting anything, but then it checks to make sure the input is a scalar, otherwise it will break the wire.

 

So you are probably familiar with some of the XNode abilities and the descriptions help you understand their purpose but how to use them is up to you.  And there are pit falls that can be a problem so I generally stick to a few methods that have worked in the past.  When using the GenerateCode ability you basically start with a blank VI.  At this point all you'll have is the control terminals on the block diagram that you defined in the GetTerms ability.  

 

So one method is to wire up from scratch those terminals to their respective locations, and drop down all the functions you would want to making this VI.  For you that would be quite a task.  You would basically be writing code, which can make your VI with all the case structures, OpenG functions, for loop, and everything.  This can be done sure, but a much easier way is to write the code once in a template, then just plop it down and wire up the terminals through scripting.

 

The method of doing this isn't standard.  I started coming up with my own way which more or less works but could be improved.  My method will drop down your template as a subVI, wire up terminals to matching control names (so wire "error in" to "error in"), then it will inline that subVI, meaning replace the subVI call, with the actual code from the subVI.  This works well enough, except it needs to know what terminals are adaptive because they don't wire up nicely until there is a type defined.  But now that I think about it I could probably catch this because the type will be void, and just don't wire any terminals if the type is void.  Another issue is if you have any control names that may change it needs to know that too.  Like say your subVI has a terminal called "Tests" but your XNode can work with a scalar or array so you may have a terminal called "Tests" or you my just have a terminal called "Test".  You'll need to know that you can wire "Test" to the subVI "Tests".  This is what the "Custom Connections" input is intended for in the Insert and Wire XNode Template.

 

The other method of using a template I think is not a simple, or as manageable.  This is the method seen in the OpenG Array XNodes.  It basically works by wrapping the entire template in a sequence structure.  Then through scripting set tags on each of the terminals going into and out of the structure, and save that tag data with the subVI template.  Then the GenerateCode will copy the sequence structure (and all of its contents) to the new XNode, and wire up the controls to terminals, that have a tag with the name of each terminal.

 

I don't like this method because it means more work for making the template having to set custom tags, when the information should already be there based on the control names.  Also you'll need to remember to wrap your template in a structure and have it be identified in some way so you can know what to copy.  I talked to AQ a while ago about my method of inlineing and he showed concern but once I mentioned that the regular expression XNode used inlineing he seemed to think it was safe.

 

Oh and one other thing, how did you get your data needed for the GetTerms?  Attached is a subVI that you provide the template VI to, and it should generate the data for the terminals.  You obviously can make changes like choosing which terminals are adaptive, but it is a starting point.  Sorry it is so ugly it did goofy things when I back saved it a few times.

Get Terms Data From Template.vi

[gb119]

I guess as the proponent of the "other" method of using templates in XNodes, I'd say it's a trade-off between work done in preparing the template and work done in the XNode ability - but mainly when I started playing with XNodes we didn't have inline subvi's (I think, or they were very new and I didn't trust them inside an XNode). Working out which thing to copy from the template can be just a convention that there is one node object on the top-level of the template - tagging the tunels just made it easier to keep track of what got wired where....

 

I've been toying with the idea of setting up an LVClass that implements all of the XNode abilities as dynamic dispatch methods of the class. An XNode with an instance of a child of this class as it's state control and whose abilities just wrapped calls to the relevant methods would be a sort of "Universal" XNode whose behavious was controlled by the class. Setting up a new XNode would then just involve making a new copy of the Universal XNode, setting the default value of the state to be an instance of a new child class and then filling in the child class methods. The advantage is that you can edit a class with regular LV tools - so it makes it all a bit easier.... One could even write an intermediate generic templating XNode class, perhaps that got information about which controls needed to be adapted to type from the control captions - implementing a new templated XNode would then just mean creating a new child class, adding the template and going...

[hooovahh]

I guess as the proponent of the "other" method of using templates in XNodes, I'd say it's a trade-off between work done in preparing the template and work done in the XNode ability

I totally agree that these are basically the two mind-sets between these two methods.  And to me this could be seen as like a framework, and in my mind I would rather put more code and effort into making the framework easier to work with, with as few steps for the developer to implement it.  Which is a reason I prefer the inline method.  It means less work for the user, and more work for the developer...but in this case they are both developers but I think you get what I'm trying to say.  

 

Another thing I like is that my XNodes that use the inline method don't have any other dependency packages to make them work.  I'm not into duplicating work, but I'd rather not force people to install a package, that they aren't going to use, which will just clutter up the palette more.  But on the other hand maybe they will find something valuable there.

 

I still don't think the inline method I show is perfect.  There is plenty of room for improvement.  Over the weekend I thought of a neat way that I could make a wizard, where you provide the template VI.  You can then tell the wizard what terminals should be adaptive, and then it using scripting, creates the XNode for you.  This could be a simple way for people to get exposed to the power of XNodes.  Of course cautioning them along the way about the experimental technology.

 

As for mixing classes and OO with XNodes.  I tried and failed.  I didn't try long but when I first was working on them I tried having a class with multiple XNodes in it and editing one would lock all the rest, and made working on any of the files very difficult. I also noticed really long name space names because it would be something like "This is my OO Class::This is my XNode Class::This is my VI.vi".  I don't know if a name could ever be too long but I was curious if it could break something eventually.

 

NI has more or less stated XNodes are stables in some use cases, and not tested in others.  So I'm guessing the combining of OO and XNodes is one thing that NI may have experimented with, but not tested for, or coded for.  At some point your application may crash, and if you are using an XNode you will likely blame it for your problems, because it is the biggest unknown in the application.