gb119

Many thanks ! This template is used in the new 1.3.1 version. I've noticed one further buglette in the XNode - if you don't connect up wires to all of the inputs and outputs then it doesn't work (even if the outputs aren't then used for anything). I suspect this is the templating code failing to wire a tagged tunnel to a non-existent terminal but haven't had a chance to investigate it properly.

Ta. Just read the comment. Not quite sure when I'll have the time to fix it. It might be easiest just to bump the minimum LV version up.

Ok, let me try to see if I'm understanding. You have a signal (a temperature in this case) that is oscillating in some fashion - possibly not sinusoidally - and you want to track the frequency of this oscillation over a period of time (which one assumes must be longer than the period of the osciallation) to look, for example, for a drift in the frequency of the oscillation. Assuming this is correct, what you need to do is to take a sample of your data that is longer than the expected oscillation period but shorter than the time over which you expect the frequency to change. Take an FFT Power spectrum of this sample. This gives you the signal as Y(f) vs f where f is the frequency (which you would normally plot on the X axis). You want the value of f for which Y(f) is maximum as that will represent the fundamental frequency of the oscillation. You then repeat this process at different times, generating a plot of f vs t.

You really need to give some more information about what you are trying to do. A 2D image is by definition 2D and not 3D - what do you want to use as the data of the third dimension? Please show us what your input and desired output look like and what you have tried so far so that someone can offer some sensible advice.

It's great, I love it, but I only use a tiny fraction of its power (Native GOOP only) - I just wish there was a way I could pay a smaller amount to take the 10 class limit off the subset of the functionality that I use. Unfortunately, I can't justify spending that much of my hard-earned grant income on something that is very nice, very helpful when I'm coding LabVIEW, but not actually core to mission...

Having skipped several generations of LabVIEW (from 8.6.1 to 2012) I was just looking around at the new toys to play with and cam across the matrix data type. Is there a good summary out there somewhere that would explain why having a new data type is so much better than simply using a 2D array of numbers - I see that there is a toolkit that links to the Intel Math Kernel library that uses the data type, but if I'm not using that is there any good reason to convert code to use the matrix type (e.g. more efficient data storage, faster indexing...?). I didn't find the online help particularly illuminating on the subject, but perhaps was looking in the wrong place...

Here

New version of OpenG Array XNodes uploaded with Crelf's R4 version as the templates.

I have been following the thread with a view to incorporating the favoutrite algorithm into the XNode version of the OpenG Array tools when a good one was agreed on (and I had time between getting samples ready for beamtime experiments, writing next year's courses, installing LabVIEW 2012 and trying to explain to my IT department why installing 64bit everything on the computers that run our experiments isn't quite as simple as rolling out a new image onto a standard desktop...).

From comments that Rolfk (the maintainer of LabPython and LuaVIEW) jas made, I suspect that this is prpbably difficult to the point of being impossible.

That would indeed be a nice thing. I have a little utility in the Code repository that will take a class or library and create palette files based on the virtual folder structure. For classes it will also walk back up the hierarchy, creating palette files for each parent class. The palette files are added to the class or library and the 'root' palette file is set as the default palette. There is also an option to do this for every class or file in a directory tree. In principle such a tool can be integrated into the project window, but you need to know details of the project provider API. There is a group on ni.com that one can apply to join to get this information I believe.

I too have played around with writing my own scripting language to drive my LabVIEW applications (a couple of times over even..). Generally I've cheated out of trying to write my own experssion parser and just content my selft with a call to another scripting language - my current version uses LabPython as a parser, but I used to use Perl. What I like about my homebrew versions is that it is easy(ier) to extend the scripting language - every command is a LabVIEW class, so it's relatively simple to make an existing application script aware by wrapping code to interact with it in new script commands. Having the language implemented in LabVIEW also means that the variable name space can be accessed from LabVIEW code too. Obviously it's slower than a 'native' environment, but in most cases I'm limited by waiting on instruments to do their stuff. I think LuaVIEW can do the call backs to LabVIEW code, but if it was able to work with something like a variant with attributes and was able to suspend and resume after each line of script, then that would be really very nice...

New package 1.4.1 uploaded. For reasons of having reinstalled my build machine, the Scripting Tools dependency is now the latest version on LavaG - although it doesn't actually need the latest version to work properly.

Hi, Thanks for the error report. I've identified the problem and will release a new package shortly. In the meantime I can tell you how to patch the XNode to make it work. The problem arises in the code used to count the number of filtered elements. I take an array of booleans into a boolean to zero-or-one node and then sum the resultant array. The problem is that the boolean to zero-or-one node outputs an I16 In the XNode folder find the template vi (<user.lib>/_LAVAcr/Array XNodes/Filter Array/Filter Array Template.vi probably) and insert a U32 conversion node: You will need to force LabVIEW to regerenate the XNode after that. Forcing a type propagation should do the trick e.g. by changing the representation of some control upstream of the XNode). Gavin

Things like this have been suggested before. The thing is that attempting to break the licensing like this would be a violation of your existing license from NI. Of course, if you don't care about doing so and are prepared to take the consequences, then I guess that's up to you. But I wouldn't expect much help from other community members ! XNodes are fun to play with and it is possible to do so without breaking the NI Licensing system as there have been some examples of XNodes where the diagrams were left unlocked and it was possible to look at the code and figure out from those examples how to make things work. However, various NI folks have made it clear that XNodes are not the future so I doubt we'll ever get an official look at them. Roll on the next edit-time scriptable node !

and even when it is metric, it has to be ******* cgs ! Back on topic, I forgot to mention that I also like complex waveforms for representing (2D) vector data, so that'd be a nice thing for a serialiser to grok.

I'd really want variant and waveform attributes to be fully serialisable for it to be useful for my use cases - the thing is that they're still one of the better map/dictionary implementations for storing arbitary metadata about a dataset. This is my biggest bugbear abpout the curtrent (Un)Flatten (from)to XML. Oh yes, and in the UK we also use '.' as a decimal point even if we do put the dates as dd/mm/yyyy rather than mm/dd/yyyy !

XControls can lock you out of classes in rather unfriendly ways (and yes this is documented I know but I still think it's not great that the IDE lets one create uneditable items without a bit more effort to stop you...). Still XNodes are fun to play with and a pain in the backside to work with. It's a shame that that is apparently an unsurmountable hurdle, but hey third (or more ? - External Nodes, XNodes, ...) time lucky

Umm, you have a 1D array of something (e.g. floating point numbers) and you have a single element (e.g. a value) that may or may not be in the array. You wire the array to the array input, the elment (value) to the element input, you get out -1 if value wasn't found in the array or the index (i.e. the position within your 1D array starting at 0 for the first element in the list up to N-1 where N is the length of the array. If you want to limit your search to start not at the first element but somewhere in the middle of the array you wire the starting index (counting from zero) into the start index input. It works, albeit in a not very scalable way because it can't assume that the elements are ordered (or indeed are sortable at all). There's really not a whole lot one can say about it.

Is there any documentation for writing Project Window Providers or is it a question of reverse engineering... ?

Here be dragons and all manner of strange beasts.... http://code.google.com/p/lavacr/source/browse/#svn%2Ftrunk%2F8.6.x%2FLabVIEW%20API%2FXNodes%2FConPane%20Wrapper It worked when I first wrote it, haven't played with it since though...

Ummmm I get this funny feeling of a conversation going in circles here.... What order does the general policy (e.g. exclude vi.lib) and the package specific rules (e.g. but include OpenG packages) get applied in ? If the individual package (in|ex)clusions are taken after the blanket vi.lib rules then it sounds like Ton should be able to build his package even if OpenG were to move to vi.lib (assuming also that the package specific rule handled dependencies, so that if include the OpenG meta package in my build it includes all of the vis in all of the OpenG packages...).

Partially inspired by this thread, the latest array XNodes package in the code repository contains an XNode that randomizes an array of any type. The algorithm is trivial - bundle with a random number, sort, and unbundle. I don't return the randomised indices but it would be pretty easy. I'm also not completely convinced about the robustness of the algorithm since the element value gets used as a 'tie-breaker' if there are two identical random numbers.

And with a bump in the major version of all packages please so that it's really obvious when it's happened....

There is, however, one case when 'rows' and 'columns' are meaningful and that is when displaying the data of a 2D array in any of the LabVIEW controls that support it - e.g. array controls, tables, intensity plots. Then you do want to know that LabVIEW has a row-major convention. I can't say I often work in high dimensions, but I was under the impression that if you dragged a n-dimensional array control to show a 2D slice of data that would always be the first two dimensions of the array with the first dimension running down the screen and the second dimension running across the screen and the third/fourth etc dimensions accessing parallel slices of the data set.