what is an xnode?

[vivante]

Hallo,

I am a new member and browsing the "VI scripting" forum, I've found many posts about XNode, but I cannot find tutorials or other technical papers about them.

Please, can somebody explain me what an xnode is? Are there documents related to xnode?

thanks in advance,

Vivante

[Francois Normandin]

Hi Vivante,

there is no documentation on XNodes because this is unsupported technology from NI. Start by reading about it on the LabVIEW Wiki.

[vivante]

Hi Vivante,

there is no documentation on XNodes because this is unsupported technology from NI. Start by reading about it on the LabVIEW Wiki.

thank you, François

[crelf]

Personally, I think that XNodes could be the next big thing we push NI to release officially. I mean, look what we did for scripting. We could start by creating more examples that use XNodes, and maybe clean up the documentation a little on the LabVIEWwiki. Anyone with me?

[Daklu]

Anyone with me?

Not having experimented with xnodes I can't be *with* you, but I would certainly find it helpful if better documentation and examples were available.

(As an aside, I thought xnodes were only available in 8.2 and earlier?)

[ShaunR]

Personally, I think that XNodes could be the next big thing we push NI to release officially. I mean, look what we did for scripting. We could start by creating more examples that use XNodes, and maybe clean up the documentation a little on the LabVIEWwiki. Anyone with me?

What did it do for scripting? Scripting is only useful for tool developers.

Those of us that create product have zero use for scripting. Except perhaps the occasional need to automate a few tedious tasks if we find ourselves in a lax minute or 2..

OK just re-read you post...lol. Missed the "we" bit . Yes "you" (as in tool developers) did get it published by NI, but my original point still stands.

Edited September 7, 2010 by ShaunR

[Francois Normandin]

Except perhaps the occasional need to automate a few tedious tasks if we find ourselves in a lax minute or 2..

That's what "programming" is all about, isn't?

[Daklu]

Scripting is only useful for tool developers. Those of us that create product have zero use for scripting.

I agree that those who don't create tools have zero direct use for scripting. I disagree its release is only useful for tool developers.

Having scripting released means tool developers get better support. Better support for tools means better tools are developed. Better tools makes for more efficient programmers. That's to everyone's benefit.

[Cat]

Those of us that create product have zero use for scripting. Except perhaps the occasional need to automate a few tedious tasks if we find ourselves in a lax minute or 2..

I'm in the midst of writing code to use scripting to crawl thru huge C header files and create LabVIEW clusters out of all the structures. (If I ever get time to finish it) This will save me loads of time every time those C header files get changed.

[vugie]

I'm in the midst of writing code to use scripting to crawl thru huge C header files and create LabVIEW clusters out of all the structures. (If I ever get time to finish it) This will save me loads of time every time those C header files get changed.

OT

Cat, did you hear of SWIG? It is able to create XML with pure information about data structures and functions out of a header file.

[ShaunR]

I'm in the midst of writing code to use scripting to crawl thru huge C header files and create LabVIEW clusters out of all the structures. (If I ever get time to finish it) This will save me loads of time every time those C header files get changed.

Why do you need to do that? Are you porting to LV?

[John Lokanis]

Those of us that create product have zero use for scripting.

I have to disagree with this. I only create product and have used scripting to do things I could not otherwise do. For example, in LV2010, you can now run a VI before and after you do a build (of anything). Well, since NI decided to not include a version number in a built LabVIEW Web Service, I added a function to my web service that returns my own version number. And, I created a VI that will (using scripting) increment the value that function returns. I then call this VI everytime I build the web service. Thus, I have used scripting to create an auto incrementing version number in something that had no version information at all before. This is very important in LV2010, since you can create a project that does not build any EXE but instead builds a web service and an installer to deploy it on a target.

I am sure that over time we will find even more ways to add a little scripting into our code to help us build better deployable product. Just need to think a little outside the box (or sequence structure, in LV terms ).

-John

[ShaunR]

I have to disagree with this. I only create product and have used scripting to do things I could not otherwise do. For example, in LV2010, you can now run a VI before and after you do a build (of anything). Well, since NI decided to not include a version number in a built LabVIEW Web Service, I added a function to my web service that returns my own version number. And, I created a VI that will (using scripting) increment the value that function returns. I then call this VI everytime I build the web service. Thus, I have used scripting to create an auto incrementing version number in something that had no version information at all before. This is very important in LV2010, since you can create a project that does not build any EXE but instead builds a web service and an installer to deploy it on a target.

I am sure that over time we will find even more ways to add a little scripting into our code to help us build better deployable product. Just need to think a little outside the box (or sequence structure, in LV terms ).

-John

I'm sure (as we've seen) people that create product will use scripting (the same way that a programmer will use more memory if more is available). But as it cannot be deployed it remains a feature that I (not being a tool developer) could have, quite happily, lived without . Tool developers, however, love it to death because it is the only way they can exist. It has opened up a 3rd party business where previously there was none and, previously, non-NI add-ons and tools were petty much free (this being a cultural change rather than a technological one) .I just find it really hard to get excited about scripting:P

I can't comment on your LV 2010 (or indeed web-services) only to say that in LV2009 an executable, DLL, and .NETs build number is included and indexable and maybe the lack of one on a web service is an oversight that should have been reported. But you didn't need scripting to do that,. The useful feature (and I do think this is really useful AND in benefits all of us) is the additionof the pre and post vi's without wihich, even scripting couldn't help and you would have had to use your previous method (which was probably a vi you run after the build, manually)

[dannyt]

I'm sure (as we've seen) people that create product will use scripting (the same way that a programmer will use more memory if more is available). But as it cannot be deployed it remains a feature that I (not being a tool developer) could have, quite happily, lived without . Tool developers, however, love it to death because it is the only way they can exist. It has opened up a 3rd party business where previously there was none and, previously, non-NI add-ons and tools were petty much free (this being a cultural change rather than a technological one) .I just find it really hard to get excited about scripting:P

Sorry Shaun, but I also totally disagree with you on this. The Scripting Tools are something that will be of use to ALL LabVIEW developers and I strongly encourage all developers to play with them and not be afraid of them.

Surly we ALL develop "Tools", in some way, they are the things that on a daily basis make our job of developing a "Product" easier, quicker and in many cases more reliable.

When I programmed in C and Perl on Unix I used things like 'grep' and 'awk' and other stuff all the time, I wrote my own scripts that used these basic Unix commands to do things for me that (as I said above) were quicker and more reliable than I could do by hand. Most people who write in text based languages are totally familiar with the concept of knocking up a little script to do some regular task in an automated manor, that is what being a programmer is about.

I use LabVIEW to create Production Test Software that we use in manufacturing to test our products. However I use scripting in a number of different ways, I using scripting to help so that I can automatically create LabVIEW executable builds, I use scripting to help auto-generate and populate a LabVIEW function Global we use. This reads some specification files our product engineers generate. I could use scripting to help auto-generate some documentation of our system, the list of possible uses is endless.

The LabVIEW IDE can not be deployed but I still find it very useful

Dannyt

[ShaunR]

Once again in the minority. Its good to be back

Sorry Shaun, but I also totally disagree with you on this. The Scripting Tools are something that will be of use to ALL LabVIEW developers and I strongly encourage all developers to play with them and not be afraid of them.

Afraid? Hardly (that's almost funny ).

Surly we ALL develop "Tools", in some way, they are the things that on a daily basis make our job of developing a "Product" easier, quicker and in many cases more reliable.

Can't argue with that

When I programmed in C and Perl on Unix I used things like 'grep' and 'awk' and other stuff all the time, I wrote my own scripts that used these basic Unix commands to do things for me that (as I said above) were quicker and more reliable than I could do by hand. Most people who write in text based languages are totally familiar with the concept of knocking up a little script to do some regular task in an automated manor, that is what being a programmer is about.

I think you mean most people that program in Linux or Unix. When I write text programs in windows and I need a quick "tool" I write something in LabView On the rare occasions I am required to do something in Linux, I probaly still wouldn't use those utilities for task automation unless there was no other way. On windows the analogy would be using the cmd.exe do tasks which I think (personally) is a bit icky, But I recognise it is a standard method on Linux/Unix.. Now pearl I would use to write a script to automate a task after all it is a "scripting" language (if only i could understand my own code 3 weeks later ).

I use LabVIEW to create Production Test Software that we use in manufacturing to test our products. However I use scripting in a number of different ways, I using scripting to help so that I can automatically create LabVIEW executable builds,

I find the project manager is sufficient. Although perhaps you could elaborate?

I use scripting to help auto-generate and populate a LabVIEW function Global we use. This reads some specification files our product engineers generate. I could use scripting to help auto-generate some documentation of our system,

Hmmm. One of the areas I definitely wouldn't use scripting is data population. I would prefer a run-time solution so that I only have to replace the document not re-hash/re-compile my code every time there is a spec change..

We have a similar implementation where the design engineers create a spec, which I deploy as part of the distribution and is parsed by the software. The document comes under document control and i've offloaded the responsibility of keeping it up to date onto a technician.

As for system documentation. Shouldn't this be generated from the requirements spec?

the list of possible uses is endless.

Maybe so. But my time and budget aren't. There has to be a very strong reason for doing something that is not easily equatable to tangible benefit (damned accountants ). Should I spend 2 days writing a script that can only be used to make my life as a programmer easier? Or should I spend that time to write a piece of code, that I can deposit on the clients site,and means I save travelling expenses, board/logging and corporate face?. If it was deployable I could do both Tool developers don't have this dilemma since they can monetise scripting directly.

The LabVIEW IDE can not be deployed but I still find it very useful

Dannyt

Perhaps we should start another thread since we are now way off topic. Or maybe we're getting to the point where there we just admit there are 2 camps (ok one of them isn't really a camp, more of a sole resident )

[dannyt]

Hi Shaun,

I do understand where you are coming form, honest I do. I just think spending the 2 days to script up something that will then save you two weeks over the coming year as you do the same thing again and again is a good think to do.

Still I am happy to agree to disagree and I will cease now :-)

Danny

[gb119]

Personally, I think that XNodes could be the next big thing we push NI to release officially. I mean, look what we did for scripting. We could start by creating more examples that use XNodes, and maybe clean up the documentation a little on the LabVIEWwiki. Anyone with me?

Certainly would be nice to have XNodes made "official". One thing that would be nice to do would be to write a reference example XNode that showed off as many features as possible in properly documented code.

I'm intending (as time permits ) to reimplement the OpenG Array tools as XNodes so that one doesn'thave to have loads of polymorphs for each and every type of array.

[Val Brown]

Certainly would be nice to have XNodes made "official". One thing that would be nice to do would be to write a reference example XNode that showed off as many features as possible in properly documented code.

I'm intending (as time permits ) to reimplement the OpenG Array tools as XNodes so that one doesn'thave to have loads of polymorphs for each and every type of array.

In the same vein as Shaun, and beginning to push the off-topic envelope further, I get concerned when I hear about OpenG and other 3rd party tools seeming to become "coin of the realm". Yes, I'm an oldline LV hack (and an older line C/Unix hack -- and I DO mean C), but I don't like having to rely on 3rd party tools that are tied to certain non-NI implementations. For my purposes it works far better to use only NI "tools" and, no, at this point I haven't found scripting to be directly useful; so Shaun that club has at least doubled in size.

On the other hand, would it be useful to ALL (or most) LV users to have xnode functionality more exposed -- perhaps. I don't know. Was it useful for scripting to be officially released -- again, perhaps. But not if the outcome of that release is more 3rd party tools instead of one integrated environment that has a large, multi-use/multi-user base. After all, I'm STILL using the Blowfish implementation based on a 1998 CIN implementation! It was the ONLY option for a long time and still remained the best option -- for me (yes!) -- after other options became available. I really don't want to see similar patterns repeated.

And that's why -- despite the HIGH quality of JKI tools -- I always ask: Is there a way to implement "x" WITHOUT having to use OpenG or...

OK, I'll slink back into the shadows...too much work to do.

[ShaunR]

In the same vein as Shaun, and beginning to push the off-topic envelope further, I get concerned when I hear about OpenG and other 3rd party tools seeming to become "coin of the realm". Yes, I'm an oldline LV hack (and an older line C/Unix hack -- and I DO mean C), but I don't like having to rely on 3rd party tools that are tied to certain non-NI implementations. For my purposes it works far better to use only NI "tools" and, no, at this point I haven't found scripting to be directly useful; so Shaun that club has at least doubled in size.

On the other hand, would it be useful to ALL (or most) LV users to have xnode functionality more exposed -- perhaps. I don't know. Was it useful for scripting to be officially released -- again, perhaps. But not if the outcome of that release is more 3rd party tools instead of one integrated environment that has a large, multi-use/multi-user base. After all, I'm STILL using the Blowfish implementation based on a 1998 CIN implementation! It was the ONLY option for a long time and still remained the best option -- for me (yes!) -- after other options became available. I really don't want to see similar patterns repeated.

And that's why -- despite the HIGH quality of JKI tools -- I always ask: Is there a way to implement "x" WITHOUT having to use OpenG or...

OK, I'll slink back into the shadows...too much work to do.

Couldn't agree more. There's nothing more annoying to me when I see a piece of code that I'm interested in to find out, I have to download VIPM then the RCF and also install 5 other openG libraries that I neither want or use.

I wonder how many people actually read all the licensing and actually do distribute the source code, licensing and associated files when they build an application with 3rd party tools? (not necessarily openG) Might be a good poll

[gb119]

In the same vein as Shaun, and beginning to push the off-topic envelope further, I get concerned when I hear about OpenG and other 3rd party tools seeming to become "coin of the realm". Yes, I'm an oldline LV hack (and an older line C/Unix hack -- and I DO mean C), but I don't like having to rely on 3rd party tools that are tied to certain non-NI implementations. For my purposes it works far better to use only NI "tools" and, no, at this point I haven't found scripting to be directly useful; so Shaun that club has at least doubled in size.

I'm not sure I really understand the problem here. With something like Vi Scripting I can see that there is a point as to whether it's useful to a develoipers other than those writing tools to run within the LabVIEW IDE (and XNode authors). For something like OpenG which in essence is just a bunch of straight G code that you can download, keep your own copy of and (since its BSD licensed) redistribute as part of your product, it seems to me that one is not dependent on the third party at all after the initial download. I don't see the qualitative difference between OpenG and say a manufacturer's instrument driver (the quantitative difference is that I'd trust OpenG to be written in sane LabVIEW ). There is a valid argument that expecting everyone to have VIPM and to be able to download and install VI packages is an ask, but on balance the vbenefits to my mind outweigh the hassle.

Releasing XNodes might be a bit like XControls - they're not something that every user will immediately want to go out and make use of, but they are a good way of handling reusable, type agnostic code without having to write huge numbers of polymorphic vis or use clunky to/from variant conversions.