GregSands

I had oglib_lvdata v2.9-1 installed previously (along with all the other old oglibs). The other oglibs updated as dependencies of OpenG Toolkit, but the lvdata did not get touched - though it indicated an update was available so I could easily do it manually.

Thanks for that. Did you also notice that the OpenG LabVIEW Data Library is not installing with the full toolkit? It's easy to do by upgrading the old lvdata manually, but I imagine it should be part of the standard install.

I'll try an XNode implementation once you've posted v1.1 - though like you, I also have limited time for this! However, I think trying to use XNodes is valuable if it shows NI that there are benefits to officially supporting them, or something similar. I haven't had any real issues in using them across several machines and versions of LabVIEW.

Will be good to hear how this is improved. By the way, I had to manually install the update for lvdata, and on 2 machines (out of 3) also had a failed install for the ZIP tools when installing the whole library, but no errors when doing it manually.

Re: XNodes -- yes, I discovered the difficulty with the Read function when I started a quick attempt at an XNode. There would of course be exactly the same problem even if LabVIEW had an "anything" type. One alternative is to require a type wired into the Read function - given that you need that for a Variant-to-Data conversion, that's not so bad, but it may make things a little more unwieldy for the standard datatypes. XNodes do have a pretty easy option of defining a right-click menu, which could be used for the standard types as easily as a polymorphic VI.

Haven't tried the functionality, but the code and icons look very clean and nice! Your comment on needing an "anything" type -- strikes me as a perfect case for writing an XNode, which would mean you could support any cluster (or any dimension array) without having to recode at all. It's not quite as easy as a true "anything" type, but it shouldn't be difficult.

On seeing the LabVIEW Idea Exchange discussion on the Array to Cluster function, I thought it might be handled fairly simply by an XNode. Here's my attempt. Array to Cluster.zip

I think there are problems with the "Find tagged and replace" routine - the "Replacement Path" control does not default to a truly "Not a Path" value, and the "New VI Object Style" should be a Ring control (with the appropriate values) rather than an Enum. I've attached an 8.6 version of what I think should be the correct VI. I also created a little utility which may be useful to add to your XNode support, though it is quite tailored to your own method for creating XNodes! Find tagged and replace.vi Copy+WireScript.vi

Can you elaborate on what problems there were? It works ok for me (tested on 8.6 and 2010). Must say that I had wanted to use the VIPM package builder, but ran into all sorts of problems getting a valid package - so I went back to the old OpenG package builder, and perhaps something is not configured quite right. Indeed - that would be because it's a nice easy way to do it!

Name: OpenG Config XNodes Submitter: GregSands Submitted: 08 Jun 2011 File Updated: 08 Jun 2011 Category: *Uncertified* LabVIEW Version: 8.6 License Type: BSD (Most common) These XNodes wrap the OpenG Variant Config routines so that clusters are automagically returned as themselves rather than as variants. The XNodes simply call the OpenG routines, as I didn't want to have to worry about handling (or rewriting) the reentrant algorithm used. XNodes are provided for Read/Write INI Cluster, Read/Write Section Cluster, and Read/Write Key, and should work as direct replacements. Many thanks to Gavin Burnell for his extremely helpful toolkit, and his release of Array XNodes which provided the inspiration for trying my first XNodes. I also use a modified version of the XNode Manager by Aitor Solar to create the initial XNodes. All the usual caveats apply when using XNodes - i.e. don't, unless you know what you're doing, or don't care what happens! Dependencies: oglib_variantconfig >= 2.7-2 lava_lib_labview_api_scripting_tools >= 0.22.2.22 Click here to download this file

Hi Martin -- There's a few solutions you have without purchasing Mathscript! There is an old library called Tripolation - found here. It computes a Delaunay triangulation and interpolates from that, however will not extrapolate outside the convex hull of your data points. Another way to get a Delaunay triangulation is shown here, using the SceneMesh which is part of the 3D Picture control. I've implemented a simple version of Kriging interpolation, which has the advantage of working in 2D or 3D, and of being able to extrapolate (with the usual caveats). In the attached code, note that the Kriging Weights would only need to be computed once for any given geometry, and the interpolation quickly updated for changes in data point values. More complex interpolations can be obtained by modifying the weights on the distances, for example to use a Gaussian or exponential weighting. Cheers ~ Greg Kriging Interpolation Simple.vi

Hi Gavin -- It seems as though "Check Cluster Term Type" is missing its connector pane assignments. Cheers ~ Greg

The tagging thing confused me for a while, but I did work it out eventually (I was confused that the terminals weren't tagged until realizing that the tunnels were). Finding the example "Set Tag on Selected Object.vi" in your Scripting Tools made setting the tags much easier. It actually seems reasonably straightforward, though I've had more crashes (LV 2010) in the last two days than a whole year! One handy tip is having "XNodeWizardMode=True" set in my LabVIEW.ini file -- right-clicking to see the generated code is a big time-saver. I also have "XTraceXNode=True" set, but no idea what that does! One question I have is whether anyone knows when and how the generated code is stored. Obviously, it is (re)created when the XNode is wired, or the input type changes, and presumably compiled when the VI is run. Does it store the generated code as part of the VI (i.e. equivalent to an inlined subVI)? Or is it recreated and recompiled every time the parent VI is loaded? How does it interact with the new ability to separate compiled code from a VI? Does the code inherit the same execution properties as the parent VI? Oh, one more thing - with this obscure tagging functionality, do you know if you can get a list of all tag names? I presume not, as NI obviously use tags for all sorts of secret things, but it would be useful.

Thanks - these are brilliant! You've inspired me to try coding an XNode or two - starting with a couple of my own array routines. It's not the easiest, though the XNode Manager does help. Is that what you use? Any other tips? I did get my first one done (with a lot of code reused from yours) in a couple of hours.

When I install, I'm missing Index Array Elements. Should that be there also?

You may also want to look at the Fragmented Array Library to work around the need to allocate contiguous arrays.

You need to do something like this:

What I mean by "operate independently" is that the core doesn't do UI. It communicates through a clearly defined I/O interface - e.g. takes in commands+data, and returns data+status. Absolutely, it has to be useful. But the issue of what UI functionality is "replicated at the command line" doesn't have anything to do with the core. Like I said, it's easier to think of a decoupled core than a decoupled UI. Simplest example I can come up with on the spot - the core accepts two commands: "Compute" and "Exit"; and one datatype: "1D array of DBLs". It returns a result (which is also a 1D DBL array), and an I32 Error Code. Perhaps the whole thing is set up using queues, but it could be through disk files or a serial port - as long as it's defined, it doesn't matter. Now the core doesn't care how the result is used - whether printed to a text screen, displayed in an array control, graphed, or saved straight to disk. It doesn't interact with the user on how to deal with an error. It is 100% decoupled. For some things, this approach is useful; for many it is not. But I think it would be generally true (and as true of my own code as anyone's) that computational parts of my code have way too much dependence on the particular UI that is used. Usually this comes about because things are written "to work now", so as long as the UI doesn't change, it doesn't matter. But if I decide I need to replace a Waveform graph with a 3D graph, then all these references which are directly manipulated now need to be completely reworked.

I disagree. If the core can operate independently of the UI, then it is decoupled; if not, then it is coupled, although there is certainly a wide range of the degree of coupling. But passing a reference from the UI to the core implies that there is a particular control (say a graph) which the core can interact with. It may be easier to think about a "decoupled core" which is able to run independent of whatever UI is used - or not, it could also work exactly the same in a "batch mode" without any user interface at all. What I would agree with is that for most situations, writing a fully decoupled UI/core is not necessary or even practical. It certainly may be slower, and require several copies of the same data. But for those cases where it is warranted, I don't think it is particularly difficult. It's a matter of defining a "data interface", and when using a dataflow language, that almost writes itself.

Yes, it's here. Thanks for the reminder to cross-post.

Don't worry, I just found this, which states that XControls "do not wake up to handle dynamic events". I'll add this to the Idea Exchange and see if there is any support.

I'm just learning to program an XControl and wonder whether the Facade VI can be triggered by registering for a User Event? I've been trying to handle mouse-scroll detection, and while I can get it to work using the parallel-process method suggested, having a hidden control seems slightly messy. So I was trying to get this work by using a User Event (ok, so that's not much less messy!) and registering it on the XControl's event structure. Now the event does get added to the queue, but does not trigger running the Facade VI - it only shows up the next time the Facade VI is triggered by something else. Does anyone know more about XControls and can explain what events can or can't trigger an XControl?

I seem to be having some problems with the search function when searching for two or more words (for example <unit test>) - the first page comes up correctly, but when clicking for the second page, the number of results increases, and the listings are no longer in order, and no longer necessarily contain both words. If the two words are in quotes (e.g. "unit test") then it seems to work ok.

Spotted here: Mac Quadro Computer Processes Pioneer Data Anyone recognise what version this is?