AdamRofer

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:

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).

Adam,

Thanks for your post. The information you provide are very interesting for some applications. I can already see a couple of system I am working on that could benefit from this thread balancing setting change. Unfortunately, in the case of applications where one does not have access to the end user computer or when the computer changes, asking the end user to go through all these loops so it can run a piece of software (just becasue it is written using LV) is not a realistic option. This need to be fixed.

Thanks

PJM

If you're feeling risky, you can try to change the registry key automatically from your programs (as referenced in the first link)... :ninja:

On a more serious note, you're right...my suggestion is most useful for applications on machines that you yourself have administrative access to. Even then, some applications (on an overall windows client machine level) benefit slightly from the default setting.

I merely provide this information here to suggest that this might be a part of what is causing the problems, since it seems to be in the same ballpark. If you change this setting and the problems reduce or disappear, then that might tell us more about what the problem itself might be.

I think these problems are related to the LabVIEW <-> Windows interface and as one of the guys on info-labview pointed out it seems to be related to which window has the focus in the Windows operating system and the associated priority assigned by Windows. What NI should look into is why this did not happend in LV 7.1.1. on the same operating system.

I have not experienced the problems people are describing here first hand, yet.

I suggest (a) up the priority (which one shouldn't have to do) or (b) set the background processing equal (which I do almost all the time anyways):

For (a), go to Task Manager (ctrl-alt-del or rt-click on taskbar), rt-click on LabVIEW.exe, select Set Priority and try "AboveNormal" or "High"

For (b), see below.

Anyone experiencing this problem can try to set the windows thread quantum to be equal for all processes (default on Windows Server machines):

(Windows XP)

Go to Control Panel, System

Click on the Advanced tab

Click the Performance --> Settings button

Click on the Advanced tab

Select Background Services

Reboot your machine

(Windows 2K is similar but not exactly the same to get this -- Advanced and then Performance Options)

What (non-server) Windows machines do by default is set the foreground window's thread's quantum (amount of time allowed to execute before trying to switch the processor to another thread) to three times that of other threads with the same priority (whew! say that three times fast).

This means if any threads are running in the background they get to process about 1/4 of your processing power if threads are competing at the same priority level.

Setting the setting I describe above instead forces Windows to calculate all threads that are at the same priority with the same quantum value, ie the same amount of net calculation time.

I have personally found that in any large development system (especially those favoring speed increases) that involves any background processing that is time-critical, enabling this setting can make a large difference. A good example would be any application that you have that runs more than one VI at a time. Try it out (even if you don't have this 8.0 problem) and see if this works better for your applications!

I first discovered this when I created a VI that was calculation-intense and that also displayed the current calculation results. It would speed along happily until I placed any other window in the foreground, when I discovered very quickly that it would chug at a much slower pace.

For a lot more detailed information on this, check this Microsoft link. For slightly less in-depth but easier to read descriptions, try this, this, and this.

As for LabVIEW 8.0's problem here:

- Maybe LabVIEW 8.0 splits computation into other processes that do not hold the foreground thread, thereby suffering calculation time.

- Maybe LabVIEW 8.0 does some fancy threading that counteracts Windows' foreground thread priority

- Maybe the default threading of LabVIEW 8.0 differs slightly from LabVIEW 7

- Maybe (and this is likely) none of these are the culprit and it is something else entirely.

Sorry this is such a long post! Maybe this can help shed some light (or, if not, help someone squeeze some bonus time from their apps!)

The example works "almost" perfect Today I tried to expand the functionality (a second Input and Output)

Then the wires were brocken, I tried to relink etc. etc. LabVIEW Crashed etc. etc...

But Finaly I know how to do it without crashing LabVIEW and it really worked!!!

After changing someting in the vi I have always to replace the Vi..

But there is a "little" work arround (add/change the menue)...

But I still miss the thing with the beer...

I could try adding a function on the pull-down menu that says "Relink recursive VI", if that seems to be the problem.

In the mean time, try to double click on the VI, that should rebuild the internals without needing to do any fancy menu stuff.

Is that what caused it to crash?

As for the beer, I like beer.

- Adam

File Name: Picture Hacks

File Submitter: AdamRofer

File Submitted: 13 Nov 2006

File Updated: 14 Nov 2006

File Category: User Interface

Picture Hacks V1.0.1

Copyright

One thing I've noticed is that frames sometimes don't refresh properly, so if you have a problem finding my previously referenced item (and you've been to my documentation site before) you can simply go here:

http://xnodes.lavag.org/recursion.html

Nice idea. I think your example of factorial might take a second look. Maybe I did something simply wrong, but I built your example, exactly as shown and it returns an answer of 0. Makes sense, you keep subtracting one each time, til you get to zero, then pass out the eventual zero result and multiply. What am I missing here?

I took the code directly from NI's example:

http://zone.ni.com/devzone/cda/epd/p/id/1827

Check a few things, like if your VI is re-entrant. That needs to be the case or else my recursion thingy won't do anything but send back the default values for whatever outputs.

- Adam Rofer

Bueller here.

http://xnodes.lavag.org/

Click on Recursion on the upper left.

I desire any and all feedback, this was a quick-as-possible venture that turned out to be quite nasty.

Source code is open for all of those curious, especially since the source code directly touts my abilities as a scripter.

Bonus features:

- Manual construction of a constant by typedef number array (that stupid ref is *not* an object creatable by the Create Object function!)

- Icon tweaking (a shadowed "R" -- which is fully customizable)

- Manual internal reconstruction upon double click (if necessary, which I don't think it should be)

Basically it's all that was talked about...just the code looks impossibly arbitrary because it took me a lot of trial and error to find out what LabVIEW would let me do.

Now if only I could convert this VI directly into :beer:

:thumbup:

- Adam Rofer

Thanks,

I tried this in PropType@mods=1, and it works(lots of interesting stuff to play with, by the way). Then I tried to put it in Init@mods=0 and store the reference in a Global for later use. I observed, no effect where I dropped the Xnode. No Icon, nothing. But, the Xnode front panel displayed the running as subVi symbol. Okay, closed labview completely, switched it back to PropType@mods=0, no change. Deleted it completly from the Xnode, no change. It appears that putting extNodeRefNum.Owner.OwningVI into Init@mods=0 ruins the Xnode for good. Could something be getting stuck in the LV2 globals?

-G

Well, I played around a bit more and saw that extNodeRefNum (typecasted to a string for visual aid) is incremented every event that fires, effectively ruining any 'preservation' of the refnum you desire. If you desire to play around with global reference, I would try writing to it each step (outside of the while loop) rather than assume it still points to the external node after x events fire.

Additionally, I see that in the Init step specifically, extNodeRefNum called with any property or method (not including getting a property that you don't use, LabVIEW apparently ignores this) causes the system to hang. It could be attempting to connect a reference to a block diagram object before it's technically created, causing my (and I assume your) system to hang, forcing a ctrl-alt-del to close LabVIEW (these nodes can easily hang your system if you call the wrong things).

The only solution to this I am able to find is to keep away from extNodeRefNum when it is in the Init step...PropType executes when you drop it on a diagram anyways, but be careful of the incrementing.

When I found out External Nodes, I always saw extNodeRefNum encapsulated in the PropTypes mods=1 step, so I see that as a subtle context hint from the developers. You should be fine outside of Init, however, as long as you compensate for the incrementing.

- Adam

edit:

p.s.: By "incrementing" I mean the refnum "value" is, for example: B160 001E, B170 001E, B180 001E for the three consecutive events that fire on drop. I assume that this means the older values do not refer to the External Node once a new one is created.

Hi,

Anybody know how to get a reference to the vi in which a particular Xnode resides, from within the Xnode? For instance, if I wanted to create a clean up wires routine which could be run by right clicking an Xnode and selecting it from the pop up menu.

Any help appreciated,

-G

If you need the information at run-time and not design-time, I recommend creating a Current VI's Path (refnode type=Function) or Call Chain (refnode type=Function) object.

However, I'm pretty sure you mean to use the information at design-time (node-run-time, what have you), so I did a little investigation.

I found out that extNodeRefNum.Owner.OwningVI returns a reference to the VI in question (I plugged .Name into a global which returned the 'dropped upon' VI's name). I don't know how often the system 'updates' the extNodeRefNum, but you know for sure it should work in the PropType@mods=1 step, where you probably could use the information the most.

- Adam

That's not entirely accurate. You can use the VI class method Fake Exec State to trick LV into thinking that the VI is idle (state 2), but you should be aware that many features will either stop your VI, cause it to crash or cause LV itself to crash, because modifying LV code while the VI is running is almost a sure way to do that.

6026[/snapback]

Too bad you still can't dynamically change the code even when it's "tricked."

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

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

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

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

Why in the world would anyone use a regular OR or AND gate?  The "trick" you missed might be to just never use them... that's my trick anyway.  The easily configurable compound arithmatic is always easier to use, copy and modify.

I think what you're saying would be nice though... actually what would be nice is if the AND, OR, XOR (etc) and COMPOUND ARITHMETIC were all the same thing, easily configurable with a right-click option, the icon would change accordingly if there were only two inputs, and if there would more it would go to the generic compound arithmetic icon (if there wasn't a better way).  That would make things look right logic-wise and still give the programmer the means to easily switch between logic variations.

5492[/snapback]

That sounds pretty easy to do with XNodes...

...but the current compund arithmetic does most of this already. Someone could emulate the compound arithmetic if there were more specific features you wanted added, however.

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