AdamRofer

Voting "never" did not work for me, or seemingly the other 0 people.

Fantastic job on this! :thumbup: This adds the primary necessary functionality to create XNodes now, let the games begin! One thing that could be added is the documentation for each ability. Sounds tricky, but then again you can find them here: 1) Open Labview 8.x\resources\lvstring.rsc 2) Search for "This is a strict type definition" 3) This refers to the State Ability...the rest follow, separated by x00 or whatever bytes that show up as Keep in mind the list has grown in LabVIEW 8.2, so don't get the info from the 8.0 folder! You can probably parse it out, make sure things are pointing to them, whatever here. I might poke around for a fuller Ability list than what you have (you have most of them), I'll let you know. Take a look at the presentation I gave last night at LAVA...I ended up skipping over the two "Create an XNode" pages since your utility does all this now! :thumbup: I'll be posting my example XNode (Recurse) in a couple days when I get a chance to clean it up for the Code Repository. I'd like to attach the presentation, but it's more than 2 megs. XNodes Presentation - Lava meeting 02/23/07 QUOTE(Aitor Solar @ Feb 21 2007, 11:50 PM) I've noticed some XNodes that have abilites (GetImage.vi) that instead say the ability is the "old" name (Image). Check my ppt presentation for the "old" (8.0) list versus the "new" list (8.2). If an ability has a 2, 3 following it then it's the working Ability name (example: AAA, AAA2, AAA3). If it's something like "OnXXX" (in LV8.2) and the original is "XXX" (in LV8.0) then the ability "XXX" is the real name, despite the .vi being called "OnXXX" inside the LLB you refer to. Does that make sense? Not very consistent. I'm also not sure if this is true for all of the "new" names but I noticed it for most of them.

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

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

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

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.

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

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

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

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

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

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

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