GregSands

Greg. Was an older version of the OpenG LabVIEW Data Library already installed? Unfortunately, the OpenG Toolkit package doesn't specify that it's incompatible with old versions of the dependency packages, so it won't upgrade them if they are already installed.

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.

When you install the other Libraries, if OpenG LabVIEW ZIP Library installs with an error you have to re-install it again.

It is a known issue that I have reported here so I won't go into detail again other than to say that we are also looking for a workaround to fix it.

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.

So I'm also leaning towards it being better to enable automatic type adaption on the write function, and only to offer the VIRegister functions with error terminals. I'll update the toolset and post it here as v1.1.

But I won't touch XNodes for now (due to their unsupported nature and my limited time). I'd rather assist NI in any possible way in making a supported functionality of that sort.

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.

This is an exciting release, since a majority of the work was spent trying to make it easier for OpenG Developers to make improvements to (and release new) packages, in the future.

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

I finally got a chance to get round to looking at this and I've hit a tinsy snag - VIPM refused to install the package properly. I managed to manually install it ok though and it all seems to work nicely.

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.

The coding style seems quite familiar

Indeed - that would be because it's a nice easy way to do it!

Hi Martin --

There's a few solutions you have without purchasing Mathscript!

1. 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.
2. Another way to get a Delaunay triangulation is shown here, using the SceneMesh which is part of the 3D Picture control.
3. 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

Basically I have one or more vi's that have the code wrapped in a sequence structure. The structure and all the tunnels are tagged using the (slightly obscure) tagging api. Generating the code is then just a case of moving the tagged sequence from the template vi into the XNode's working diagram and then wiring up the tunnels to the terminals.

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.

Ummm, yes. Will try and work out what how I've screwed up the packaging...

Edit: Identified the packaging problem (somehow the how XNode had disappeared from my source directory - thankgoodness for SCC..., coupled with some weird linkage problems). Version 1.2.1 should have the missing XNode I believe.

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.

Have now got XNodes for all the OpenG Array tools.

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:

Hmm.... so define "operate independently" for me. (I'm not being pedantic, honest. These are the thoughts running through my head as I wonder exactly what you mean.)

Does that mean you can build the core into an executable and it will execute without any errors, even with the UI layer removed? Is the lack of errors a good enough qualifier, or does it actually have to be useful? (i.e. Does it have be able to *do* some of the things that would normally be accomplished via UI interaction? Say... via the command line and batch files.) If useful functionality without a UI is a requirement, how much of the UI's usefulness has to be replicated at the command line? 50%? Why not 49%, or 51%? Any arbitrary cut off between 0% and 100% puts us in the purely subjective realm of figuring out exactly what should be considered "useful" and how useful it is relative to everything else. Since you're proposing a concrete standard, subjectivism isn't allowed. So we have to choose... Using the 0% bar reduces "decoupled" to mean the same thing as "no run-time dependency." Using the 100% bar makes "decoupling" an impossibility--no command line interface can offer all the same things as an event-driven gui.

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 understand what you're saying and agree with you in principle. What I'm struggling with is the implied idea that there is an arbitrary line you can cross where your UI transitions from coupled to decoupled.

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.

Hi Greg

Did you post this to IE?

I would vote for it.

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

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?

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?

In my part of the world everyone's winding down for their summer holidays! So I thought I'd start a pair of topics to sing the praises (and raise the sins) of LabVIEW. In this topic:

What design feature in LabVIEW most annoys you? The one that you constantly bang your head against, and wish that it had been developed differently, but it's probably too late to do anything about?

In the code I write, it would have to be the separate Image datatype. Why could it not just be an array? Sure, there are benefits to having a separate type - some very fast image processing code, and handling of image borders. But it is so restrictive if what I want to do is not already coded as an IMAQ routine, for example, taking the square root as part of computing the standard deviation of an image region, or wanting to use 3D images. Either I ignore all the really useful image routines, or I use twice the memory and keep swapping back and forth.

OK, your turn.