XNode / Express Node Documentation

[AdamRofer]

Hi all, here's a nice start for XNodes / Express Nodes:

Download the ZIP to conserve traffic if possible, and let me know what you think.

- Adam Rofer

edit: Feel free to distribute or host this wherever you want. Thanks!

Edit by: Michael Aivaliotis

LAVA has offered to host the xnodes information and Adam has agreed. Here is the new link:

http://xnodes.lavausergroup.org

[m3nth]

What a way to debut. VERY nice sleuthing.

[m3nth]

The quote on your website mentioned that the storage VI's use this... It appears that the Timed Loop VI's also use this.

LabVIEW\vi.lib\Platform\TimedLoop\ConfigExtNode.llb

First one on the list has the indicative ;D prefix.... ;DConfigExtNode.vi

[brian175]

...and let me know what you think.

I think that this is an impressive piece of work! I took a look at the example and found one minor correction and I also have a suggestion on how to make the creation of the scripted code a little simpler. First, the case for the PropTypes mod=0 was a "2" in the case which was preventing the terminals from changing to an array of errors if needed. To fix, just change the case "2" to a "0".

Here is a screen shot of the code generated from a modified version of your original sample.

The idea is to only script the pieces that need to be changed and use a regular SubVI for the rest. Just look at the mod=1 case and see how much less scripting is required.

Download File:post-987-1123096042.zip

Same as Adam's example, rename with ";D..." and _MergeErrors.vi must be in the same directory as the xnode

Thank you Adam for sharing your discoveries.

Brian

[AdamRofer]

I think that this is an impressive piece of work!  I took a look at the example and found one minor correction and I also have a suggestion on how to make the creation of the scripted code a little simpler.  First, the case for the PropTypes mod=0 was a "2" in the case which was preventing the terminals from changing to an array of errors if needed.  To fix, just change the case "2" to a "0".

Here is a screen shot of the code generated from a modified version of your original sample. 

The idea is to only script the pieces that need to be changed and use a regular SubVI for the rest.  Just look at the mod=1 case and see how much less scripting is required.

Download File:post-987-1123096042.zip

Same as Adam's example, rename with ";D..." and _MergeErrors.vi must be in the same directory as the xnode

Thank you Adam for sharing your discoveries.

Brian

5523[/snapback]

Brian,

Fantastic! This solves the problem scenario where Stephen Mercer warned me that additional processing (catching ALL errors) would tend to be quite a large bottleneck. This version of ;DMergeErrors combines the ease-of-use of XNodes with the performance benefit gained by using the simple _MergeErrors.

You could even make it call the vi.lib version or MergeErrors and input in the array section to avoid needing the modified _MergeErrors version in the same directory, but that's just a detail. Well, I attached the modified version (no need to have multiple files now!).

I am glad that my example and documentation is enough to get people started, I was worried that I wouldn't have been comprehensive or user-friendly enough in trying to explain how things work.

As for the PropTypes mods=0 / 2 bug, this was a bug I discovered yesterday afternoon and I have since fixed all instances with the "good" version...good catch! :thumbup:

I think I will include a section in http://xnodes.lavausergroup.org for open-source XNodes (I haven't ported minesweeper or mrt over yet) so that a comprehensive library of functionality can be listed.

Thanks!

- Adam Rofer

Note: just noticed that CTRL-Z returns the XNode to its original state no matter where it is. I'll look into which Init event is being called.

Download File:post-2496-1123103017.vi

[brian175]

Note: just noticed that CTRL-Z returns the XNode to its original state no matter where it is. I'll look into which Init event is being called.

5526[/snapback]

CTRL-Z has another curious artifact in that it leaves void terminals if extra terminals were added. To see, right click and select "Add Item" a couple of times and then do a CTRL-Z. Move the wiring tool to the Merge Errors and you will see the now deleted terminals, but if you try and wire to them you get a broken wire and a void as the sink. This can be "fixed" by double clicking on the Merge Errors XNode.

Which brings me to another question, where is the double click event? Have I missed it in your docs? If not, the Storage VIs use the double click event to launch the configuration windows so it must be there somewhere.

Brian

[AdamRofer]

Note: just noticed that CTRL-Z returns the XNode to its original state no matter where it is. I'll look into which Init event is being called.

I remembered that XNodes act weird with UNDO. It calls an event Init with mods=0 (mods > 0 is a new instance).

If you modify the termSpecs (Add Terminal) and then UNDO it, I suppose I have to include the code that removes the termSpec terminal that was last added. That's more hassle than not, but it makes sense in a sick way.

In the meantime, keep in mind that UNDOing anything will currently make it reset itself.

If I include the ability to retain information (Init: if mods = 0, then bounds, image, and termSpecs stay the same as shift registered values), it works fine. UNLESS you issue an UNDO immediately after "Add Terminal." Then LabVIEW forces the XNode to stay within the specific bounds it previously owned. This is a problem, since no "unique" information is sent into an XNode that describes:

1) UNDO issued somewhere in project

2) UNDO issued on XNode (set bounds to previous bounds in LV action list)

3) REDO issued on XNode (set bounds to next bounds in LV action list)

Basically, things are OK if you assume (1) and retain your information (as in attached XNode, see Init:mods=0,Default).

However, if you "Add/Remove Terminal" and then issue an UNDO your XNode will appear to be smaller but in fact it still thinks that it is the same size.

Too bad I can't see any way to discern between (1), (2), and (3). :headbang:

Any ideas?

Attached is a version that fixes (1) but look out for (2) and (3).

- Adam Rofer

Download File:post-2496-1123105264.vi

[AdamRofer]

Which brings me to another question, where is the double click event?  Have I missed it in your docs?  If not, the Storage VIs use the double click event to launch the configuration windows so it must be there somewhere.

Brian

5527[/snapback]

SelPopUp, mods=-1. I use this event heavily in my Mr. T and Minesweeper (codeless) examples.

- Adam Rofer

[brian175]

Here's another correction I found, it is in the Details section of the first XNodes section:

XNodes are not reentrant VIs, but they can have multiple instances in parallel.

I believe that you do need to make the XNodes reentrant in the VI Properties Exectution Category. See what happens if you place the Merge Errors XNode on a diagram and add another input. Now place a second one on the same diagram, and the first one breaks. (Best seen with ExternalNodeDebugging=True). Now change the Merge Errors XNode to reentrant and everything works.

I have been experimenting with trying to make the Merge Errors XNode growable. Is there a way to keep the XNode from growing in the horizontal direction? If I reset the bounds it doesn't seem to work once I stretch in the horizontal direction? Any ideas.

Brian

[AdamRofer]

Here's another correction I found, it is in the Details section of the first XNodes section:

I believe that you do need to make the XNodes reentrant in the VI Properties Exectution Category.  See what happens if you place the Merge Errors XNode on a diagram and add another input.  Now place a second one on the same diagram, and the first one breaks.  (Best seen with ExternalNodeDebugging=True).  Now change the Merge Errors XNode to reentrant and everything works.

I have been experimenting with trying to make the Merge Errors XNode growable.  Is there a way to keep the XNode from growing in the horizontal direction?  If I reset the bounds it doesn't seem to work once I stretch in the horizontal direction?  Any ideas.

Brian

5546[/snapback]

I stand corrected with the re-entrant aspect.

As for Grow, I actually implemented a Merge Errors that used the Growable ability, but it snaps to 48x48 (or at least 48 in the direction stretched) whenever the user drags it in any direction. I have not been able to find a way to "lock" it from expanding in any specific direction.

I didn't really know what these were until I heard they were sequence structures. If you try a sequence structure, you'll find you can't resize it below a certain amount (where the outside is 48x48).

Another quite useful feature that seems hindered by a lack of completion. Let me know if you find some workarounds for these problems.

- Adam Rofer

[m3nth]

Which brings me to another question, where is the double click event? Have I missed it in your docs?

5546[/snapback]

Yup you missed it, but probably because it isn't obvious. A double-click is handled by a selection on the popup menu... indicated with What = SelPopUp and Mods = -1. You could then call the VI you wanted to popup for configuration or whatnot by opening a reference with the connector pane typedef and use a call by reference node to pass values or get them back from the popup.