Jump to content
Sign in to follow this  
Aitor Solar

My first Xnode

Recommended Posts

This is my first Xnode (not an External Node, but a true LV8 Xnode). I don't know how "revolutionary" is this, I suppose not much. I haven't found info about new Xnodes, but sure a lot of you are playing with this technique and are more advanced than myself. In fact, a couple of days have been enough to grasp the basics, so my first impression is Xnodes are far better "thought" than old External Nodes :thumbup: .

The purpose of this Xnode is simple, it just returns the selected string value from an enum. This was already easily done, for example with the "Format into String" function or with the "Get Strings from Enum" VI from OpenG (impressive by its own), but I think it can be an useful proof-of-concept for people who want a VI that accepts all kind of enumerations as inputs without using variants (something I've found desirable from time to time).

post-1450-1168960156.jpg?width=400

The function accepts all enumeration types and representations (even typedefs), or at least it should. If you find any error please tell me, I've tried to make the Xnode as light as possible.

Obviously, Xnodes can do a lot more things, but unfortunately just one example comes with LV82, so if anybody knows better, please share your wisdom :yes: .

Saludos,

Aitor

Download File:post-1450-1168960151.llb

Share this post


Link to post
Share on other sites
This is my first Xnode...

How do you manage to edit the XNode. When I open the .xnode file with my LabVIEW, a project explorer opens with a locked xnode in it. I think XNodes require a license, have you got one? Or is there an INI file setting that allows one to edit the XNode? Could you please write a short tutorial on how you created the XNode.

jimi

Share this post


Link to post
Share on other sites

Xnodes are used as a subVI, not opened directly. From another VI's diagram -> right click -> Select a VI -> Go to "EnumToString.xnode.llb" -> Select "View all" in the bottom options -> Select "EnumToString.xnode"

I attach an example of use (put it in the same directory the EnumToString.xnode.llb is). Connect any of the enums (or other ones you create) to the input, it should adapt to it; run and get the selected string.

Tell me if it works for you ;) .

Saludos,

Aitor

Download File:post-1450-1169019643.vi

Share this post


Link to post
Share on other sites
Xnodes are used as a subVI, not opened directly. From another VI's diagram -> right click -> Select a VI -> Go to "EnumToString.xnode.llb" -> Select "View all" in the bottom options -> Select "EnumToString.xnode"

I attach an example of use (put it in the same directory the EnumToString.xnode.llb is). Connect any of the enums (or other ones you create) to the input, it should adapt to it; run and get the selected string.

Well it's not the use people here are interested ;-). It's how you made them! As far as I know there are only two possibilies:

- You got a license from NI somehow (and have signed an NDA or someone has on your behalf) and then posting this here could get you in trouble.

- You hacked LabVIEW to not do a license check anymore or something like that and then you are also in trouble in at least certain countries on this globe who think that even thinking about circumventing anti-copy protection is a major crime.

Rolf Kalbermatter

Share this post


Link to post
Share on other sites
Well it's not the use people here are interested ;-). It's how you made them! As far as I know there are only two possibilies:

- You got a license from NI somehow (and have signed an NDA or someone has on your behalf) and then posting this here could get you in trouble.

- You hacked LabVIEW to not do a license check anymore or something like that and then you are also in trouble in at least certain countries on this globe who think that even thinking about circumventing anti-copy protection is a major crime.

There are also other options, which, I think, would be legal. The .xnode file is not itself copy protected (I think) but a plain text XML file. So the hard part is how to make the ability VIs (the VIs which control the behaviour of the XNode) and how to link the ability VIs so that they know they are part of the XNode library.

- There is a XNode shipping with LabVIEW or some external package, the ability VIs of which have not been password protected. Then you could propably edit the ability VIs as the license is (techically) required only to create new ability VIs.

- A. Solar has somehow been able to create ability VIs without needing to overcome technical copy protection.

Share this post


Link to post
Share on other sites
Well it's not the use people here are interested ;-).

Well, sorry, from the previous posts I got the impression some people was simply opening the xnode instead using it in a diagram.

It's how you made them! As far as I know there are only two possibilies:

- You got a license from NI somehow (and have signed an NDA or someone has on your behalf) and then posting this here could get you in trouble.

- You hacked LabVIEW to not do a license check anymore or something like that and then you are also in trouble in at least certain countries on this globe who think that even thinking about circumventing anti-copy protection is a major crime.

Ouch, come on... Do you really think I would do something illegal? And even worse, do you really think I'd do something illegal and posting it in a public forum? :nono:

Creating an xnode is really easy and doesn't need any license. A Xnode is just a type of library and can be open, modified, etc with scripting.

post-1450-1169034577.jpg?width=400

And, as Jimi says, a xnode file is just a XML file. You can extract it from the llb, open it in a text editor, change what you want and returning it to the llb.

About the abilities... that's even easier :) . The ability VIs just need to have the correct connector pane, and you can find that connector panes in the xnode example that comes with LV82 (search for *.xnode in your LV82 installation directory). Not everything is exposed, but with some trial-and-error and knowledge of the old External Nodes is not so difficult. So you can create new ability VIs without problems (they are normal reentrant VIs).

About linking a VI to a library, it's answered in this same forum, in a question about linking VIs to a Xcontrol, IIRC. You have the library reference and use the "add item from memory" method.

So, I ask you, members of the jury, must this man go to jail for all his life?

The answer is "probably yes, but not for this" :P

Saludos,

Aitor

Share this post


Link to post
Share on other sites
Creating an xnode is really easy and doesn't need any license. A Xnode is just a type of library and can be open, modified, etc with scripting.

post-1450-1169034577.jpg?width=400

Would you Aitor Solar like to post the VI in the above image to the forum, of course assuming it doesn't contain any stuff under NDA or something that would be illegal.

Share this post


Link to post
Share on other sites
Well it's not the use people here are interested ;-). It's how you made them! As far as I know there are only two possibilies:

- You got a license from NI somehow (and have signed an NDA or someone has on your behalf) and then posting this here could get you in trouble.

- You hacked LabVIEW to not do a license check anymore or something like that and then you are also in trouble in at least certain countries on this globe who think that even thinking about circumventing anti-copy protection is a major crime.

Rolf Kalbermatter

I would take it easy on the condemnation. A lot of this stuff is not super protected. It just requires some one with a little sense of curiosity and the ability to use Windows file explorer. You know, it's really ok to browse inside your C:\Program Files\National Instruments\LabVIEW 8.2\resource folder... ;)

Keep up the good work Aitor!

Share this post


Link to post
Share on other sites

Here's a couple INI entries:

XNodeWizardMode=True (try right clicking on an XNode now!)

XTraceXNode=True (um, I forget what this did actually...it's been a couple weeks)

Of course, I personally prefer:

ExternalNodesEnabled=True

XNodes are easy to edit without any licensing (XML). There's really no security around those, and a lot of NI "examples" are given (albeit locked diagrams).

:)

Share this post


Link to post
Share on other sites
This is my first Xnode (not an External Node, but a true LV8 Xnode).

Aitor: This is very cool! great work :)

Here's a couple INI entries:

Adam: Thanks for these!

Michael: I think we might be getting to the point where we need an XNodes subforum, with a pinned README topic on how to get started.

Share this post


Link to post
Share on other sites
Michael: I think we might be getting to the point where we need an XNodes subforum, with a pinned README topic on how to get started.

I agree with Jim. Perhaps even better possibility for the future would be a special XNode Wiki where registered LAVA users could describe their finding on XNodes.

Investigating some .xnode XML files gave me the following information. XNodes are XML project files that can contain any number of files. What's special of XNode project files is that XNodes can contain special Ability VIs that control the behaviour of the XNode. The following code in the .xnode XML file specifies an Ability VI. The NI.XItem.Name property is mandatory for all Ability VIs and it specifies which ability is in question. NI.XItem.Type property is present for only some of the ability VIs and I don't currently know it's meaning. The VI_name can be arbitrary. Ability VIs can also be controls, at least State ability is always control and propably defines the format of XNode internal state.

<Item Name="VI_name.vi" Type="Ability VI" URL="/path/to/VI_name.vi">			   <Property Name="NI.XItem.Name" Type="Str">AbilityName</Property>			   <Property Name="NI.XItem.Type" Type="Int">0</Property>	 </Item>

At least the following values are valid for the NI.XItem.Name property.

State, AdaptToInputs, Bounds, CanAcceptDataDrag, DataDrag, DoubleClick, GenerateCode, GetDataForDrag, GrowInfo, Image, Initialize, ListErrors, Size, Terms, Compare, DisplayName, Message, UpdateState, Help, RefeeChanged, AutotoolRegions, BuildMenu, SelectMenu, OperateClick

I browsed trough the LabVIEW.exe file (LV 8.0) with a hex editor, here are some findings. Many of the Ability VIs have an output terminal called "Reply". You can return information from the Ability VI using this terminal. The returned information is called "xreply". One can return zero or more xreplys. Possible values for an xreply are at least: UpdateTerms, UpdateImageAndBounds, ShowMenu, GenerateCode, ChangeTransactionName. Also the following values may be valid: UpdateLabel, UpdateImage, UpdateHelp, UpdateAutotoolRegions, ShowMenu, FailTransaction, ChangeTransactionName, PreserveUserCodeGUID.

EDIT: Next Steps I think that the following things need to be clarified somehow.

  1. To create a ZIP file with all the ability VIs with correct front panel and connector pane
  2. To create an XNode with all of the abilities
  3. Figuring out what each ability does and when each ability is called by LabVIEW
  4. Figuring out the meaning of each xreply

EDIT 2: To make reverse engineering a little easier, just take a look at the block diagrams of the Ability VIs in the following directory. For some reason they are not password protected in LV 8.0.1

LabVIEW 8.0\vi.lib\Platform\TimedLoop\XDataNode

EDIT 3: To make things even more easy...

  1. open the following file in LabVIEW 8.0.1 "LabVIEW 8.0\vi.lib\Platform\TimedLoop\XDataNode\XDataNode.xnode"
  2. Right click XDataNode.xnode in LV project explorer and select "Save as"
  3. Select Copy and give a name for your own XNode
  4. Select a directory where you want to create your own XNode
  5. Start playing around...
  6. Note that even though the VIs are not password protected, there is a password in the .xnode file itself

Share this post


Link to post
Share on other sites
Here's a couple INI entries:

XNodeWizardMode=True (try right clicking on an XNode now!)

XTraceXNode=True (um, I forget what this did actually...it's been a couple weeks)

Of course, I personally prefer:

ExternalNodesEnabled=True

Great! Now is much easier :) .

Here is a llb with blank Ability VIs, with the appropiate connector pane. Is not the complete set, there are still some more abilities, though the most frequently used are included. I'll try to complete later. I'm surprised they are so many and not cleared differenciated (there is "BuildMenu" and "BuildMenu3", for example). And yes, State.ctl carries the internal state just it does in Xcontrols. Replies are used to call another Ability (for example if you generate code that changes the terminals, you should return a "UpdateTerms" reply).

Saludos,

Aitor

EDITED: Ok, now the llb has all the Ability VIs I know of. So if anybody finds some else, tell us :) . Is there any list of all the possible abilities?

Download File:post-1450-1169210073.llb

Share this post


Link to post
Share on other sites
Ouch, come on... Do you really think I would do something illegal? And even worse, do you really think I'd do something illegal and posting it in a public forum? :nono:

Sorry Aitor.

I remembered from my limited investigations (yes that kind of thing is legal here although using the knowledge to circumvent such protection is not) into the 8.0 license manager that there were two explicit areas that seemed to require a license in order to run. One was the scripting feature that we all know about and the other was something like XNode Development. Knowing scripting I did investigate a bit further into it but not being familiar with XNodes I never went further on that. Maybe they changed the Xnode protection in 8.20 or there are two different aspects about XNodes that are protected differently. I do not know and won't have time to investigate in the near future.

Rolf Kalbermatter

Share this post


Link to post
Share on other sites
... Is there any list of all the possible abilities?

Here is the complete list -

State, AdaptToInputs, AugmentSelf, BuildMenu, BuildMenu2, BuildMenu3, CalculateFeedthrough, CanAcceptDataDrag, CanAcceptDataDrag2, Compare, Copy, GenerateCode, GetAutotoolRegions, GetBounds, GetDataForDrag, GetDisplayName, GetDisplayName2, GetErrors, GetErrors2, GetErrors3, GetGrowInfo, GetHelp, GetImage, GetTerms, GetTerms2, GetTerms3, Initialize, Message, MessageWithUI, MessageWithoutEffect, MessageWithUIWithoutEffect, ModifyCode, MutateForPrevious, OnDataDrag, OnDataDrag2, OnDoubleClick, OnDrop, OnFontChange, OnOperateClick, OnRefeeChange, OnResize, ReplaceSelf, SaveForPrevious, SelectMenu, SelectMenu2, SelectMenu3, SpecifyInsertTerm, UpdateState, UpdateState2

The reason for the BuildMenu, BuildMenu2, and BuildMenu3 is that the first and second are depreciated, so you should always use the latest (if you look at the ability VIs you can see that the cluster data has changed.)

Here is a another place to get Ability VIs:

..\LabVIEW 8.2\resource\Framework\Providers\xi\xnode.llb

However, beware that the connector panes may not be correct. The first and only one that I looked at was BuildMenu3 and it has a different connector pane than ones in use such as:

..\LabVIEW 8.2\vi.lib\variable\varXNode.llb\varXNode_BuildMenu3.vi (which is not password protected)

Warning this VI will crash LabVIEW

Download File:post-987-1169247482.vi

I started to play around with adding a new ability VI to an existing xNode library but it so far has only caused crashes.

Brian

Share this post


Link to post
Share on other sites
Here's a couple INI entries:

XNodeWizardMode=True (try right clicking on an XNode now!)

XTraceXNode=True (um, I forget what this did actually...it's been a couple weeks)

ExternalNodesEnabled=True

:)

I remembered from my limited investigations (yes that kind of thing is legal here although using the knowledge to circumvent such protection is not) into the 8.0 license manager that there were two explicit areas that seemed to require a license in order to run. One was the scripting feature that we all know about and the other was something like XNode Development....

Rolf Kalbermatter

Hello Adam and Rolf

Thanks for the ini keys- Now I konw how to get some of them by myself...

I just figured out those for LabVIEW 7.1 (but you probably already know them)

ExternalNodesEnabled=True

ExternalNodeDebugging=True

But be careful, you will create insane objets... so save your work bevore using them...

Anyway it's nice to see that a timed loop consists of xnodes...

So just enable both keys, restart LabVIEW 7.1 and place a timed loop...

Share this post


Link to post
Share on other sites
Anyway it's nice to see that a timed loop consists of xnodes...
And so are the storage VIs.

Share this post


Link to post
Share on other sites

Ok... I'm about to do something very out of character. I'm going to give some advice about the unreleased features of LV.

For the love of all things holy, do not use external nodes. Use XNodes.* Build on XNodes. Write poetry to your XNode. But do not attempt to propagate the entity known as the external node. Shun the ;D prefix. It was a useful research project in "what not to do." We learned much from that research. And, having learned, we now abandon. National Instruments is re-writing every single toolkit that uses external nodes to use XNodes. We are switching off that technology as quickly as we can find staff to do the rewrite. And that means at some point we really will switch off that technology -- some future version of LV will ship from NI stripped of the code that supports that tech support nightmare (internal tech support of course... external tech support doesn't support unreleased features, X or external).

And now this LV developer will return to his usual principle of denial: "What XNodes? I see no XNodes in the feature list..."

* Yes, I would turn on "blinking" for this bit of feedback if LAVA had such a font setting. I mean it. Do not use external nodes. Bad juju. Bad.

Share this post


Link to post
Share on other sites
For the love of all things holy, do not use external nodes. Use XNodes.*

Aww... but they're so fun! And comparatively licensing-free (7.1)!

:thumbup:

Share this post


Link to post
Share on other sites
Aww... but they're so fun! And comparatively licensing-free (7.1)!

:thumbup:

And they're a type propagation nightmare that is prone to crashing and produces bizzare errors unless you hold your CPU at just the right angle so the instructions go down the pipeline juuuuuust right. And, of course, they're dead code in the future. Not that I'm implying they exist today or anything. Nope. Definitely not implying that.

If you want licensing free, use a Mac. Or Linux.

Share this post


Link to post
Share on other sites
For the love of all things holy, do not use external nodes. Use XNodes.*

* Yes, I would turn on "blinking" for this bit of feedback if LAVA had such a font setting. I mean it. Do not use external nodes. Bad juju. Bad.

So that's quite clear (what about a animated gif?)

Now one advice to NI, when you release it in an official version (I heard rumours about 9.2), give some serious documentation with it.

We don't expect that it will be stupid/Jimi proof, we know NI can't do with it what we do for testing. But in the case of XControls the documentation is quite lacking. No information about how it is called exactly when it is called. Sometimes XControls are called without reason, or they loose their state information...

Ton

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.

Sign in to follow this  

×
×
  • Create New...

Important Information

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