GregSands

There's a couple of others I found here: http://lavag.org/topic/15895-new-vi-objects/

Is this close enough?

https://decibel.ni.com/content/docs/DOC-13859

Have you already looked at Gavin Burnell's Scripting Tools on the LAVA Code Repository?  It has a number of routines that are really useful for creating XNodes, including "Copy and Wire Tagged Element" which is almost exactly what you're looking for - often, GenerateCode can simply be a call to this VI.

There doesn't seem to be a problem in LabVIEW 2012 (lvanlys.dll 12.0.0.3) or LabVIEW 2011 (lvanlys.dll 11.0.1.2), checked for both 32-bit and 64-bit. This is on a machine with only those versions installed.

What I usually do in these sort of cases is to add an image of the equations to the BD of the VI.

Another option might be to use a Math Node.

Drop a matrix control onto the FP.

Nice trick Darin - you get a numeric control which actually has vertical sizing. I never knew that.

I tried this on the logs and the smoothing assigned NaN values to some of the Y-Points. Do you know what could be causing this?

The final result is that the output curve has many broken regions. I have attached various screen shots that shows this.

Hard to tell without seeing the data, but if your screen-shot is correct, you have a "Weighting Fraction" equal to zero, so I wonder if that is causing the problem. I'm pretty sure that it should be greater than zero - it's the fraction of the dataset to use for fitting at each point.

Thoughts? Critisism? Praise? Ideas to make it better? Good for OpenG?

Without downloading or running, shouldn't this be "seconds to wait" x 100, not "divided by"?

Just has a cursory glance. But it looks like you are calculating the coefficients and passing the XY parms for the linear fit twice with the same data (it's only the weightings that change from the first "fit" to the second) . You could pre-calculate them in a separate loop and just pass them into the other loops.

I used a separate loop to start with, but the speed improvement was minimal, and the memory use would be increased fairly significantly.

Greg,

My first thought would have been to truncate the weighting calculation and fitting to only a region around the point where the weights are non negligible. Currently, the algorithm uses the entire data set in the calculation of each point even though most of the data has near zero weighting. For very large datasets this will be very significant.

Yes, in fact the weighting calculation already truncates the values so that they are set to zero outside of a window around each point. However with a variable X-spacing, the size of the window (in both samples and X-distance) can vary, so it would be a little more complicated to work out that size for each point.

Just had a quick go - with a fixed window size, you get a further 10x speedup, but if you have to threshold to find the appropriate window, it's only another 2-3x. Still, that's around 40x overall, with further increases using multiple cores.

SmoothCurveFit_subset.zip

I'd only ever used it for arrays up to about 5000 points, so it had been fast enough. Interestingly, the greatest speedup still comes from replacing the Power function with a Multiply -- never use x^y for integer powers!

Any further improvements?

Here's a template that doesn't use the IPES, so should work in 8.6. It should be almost as efficient.

OpenG Remove Duplicates from 1 D Array Template.vi

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

Gavin -- there's a small bug in this implementation which I've described in the support topic.

The latest version 1.3.0 (based on these revisions) has broken the "Remove Duplicates" function by not correctly retaining the Array Split in the In Place Element Structure. I presume this was caused by back-saving to 8.6, whereas this functionality is only in 2009+. That appears to be the only function affected.

This may be of interest: http://forums.ni.com/t5/Machine-Vision/ADV-Toolkit-Imageprocessing-on-NVidia-GPU/td-p/1130963

All work fine for me on Win 7/LV 2012. Have you tried remapping the shortcuts in Tools/Options/Menu Shortcuts? In fact, trying to set new shortcuts there will show you whether the keystrokes are getting through to LabVIEW or not.

I think it is intended by precedence. In fact I'm totally surprised that List Directory does also filter directories based on the pattern. So what do you get if you want to list *.txt files? No directories at all?

Yes, my expectation is that you'd get no directories at all (unless the directory name was Something.txt which is always possible, if unlikely). asbo's suggestion is 2nd most logical, that you'd get a list of the directories that contain files matching the pattern (though that can be gleaned from the file paths). But I can't see any logic in returning all directories.

But changing the default is not really an option since it could and likely would break quite a few OpenG Tools such as the OpenG Package Builder, Commander and its decendent, the VIPM.

I can see that now the utility is written, it's pretty difficult to change it, although it could always be deprecated with a new version written. Failing that, perhaps a boolean, or a 3-way enum - e.g. All (default), Files Match, Directories Match - could be added. Or I guess a polymorphic function is another way to extend/correct it.

Oooh, I read a little too much between the lines of what you said. Interesting; does the original node returns directories and files or just directories?

The built-in List Directory function returns all files and directories which match the provided pattern. My point is that List Directory Recursive recursively finds all files in all sub-directories which match the pattern, but it returns all sub-directories whether they match the pattern or not. I don't know whether this was intended, or whether it is a bug in the implementation. If it was intended it would be interesting to know why, and if not, I think it should be changed - though that would break any existing usage.

I would agree that including any subdirectories which do not contain a matching file is a bug.

That's slightly different again - I was thinking it should contain all sub-directories whose names match the pattern, irrespective of any files in those directories. To me, that's the closest parallel to the core List Directory node.

I have just observed that the array of directory paths returned by List Directory Recursive is always every sub-directory of the root Path, no matter what pattern is used. My expectation (and what I'd wanted to use it for) had been that this output would contain only the sub-directories which matched the pattern, in the same way as the array of file paths is generated. Is this result the intended behavior, or a bug in the implementation?

Hah, I do not have any problem with further improvements (although this one is relatively minor I would say) - as long as I'm not the one to update all those polymorph instances again ;-)

Not just updating them all, but choosing what instances are provided - I use arrays of Images, but those are not useful for most people.

If there's ever a reason to have "generic" terminals, then this sort of polymorphic-heavy function gives a great example. Writing them as XNodes (thanks Gavin) means there's no need to code all the polymorphic instances, but there's a lot of extra coding still to do around the function itself. So yes, I know that generic terminals don't officially exist, and won't exist at all soon, and XNodes are somewhat hidden, but I hope there's a third alternative in the wings. Or that there's a slightly easier way to create XNodes.

Greg: Yes, making the subVI inline does make it possible for the output to avoid calculation entirely. Doing it on any subVI call is something that the compiler optimization team has on its list of possible optimizations, but not currently implemented.

So, in the case described here, does that include not allocating the "Indices of removed elements" array before the For loop? If so, I'm pretty impressed.

In my experience, keeping memory allocation to a minimum is at least as important as execution time. The original array should be reused for the output (where possible), and every array access checked that it is performed in-place (with or without the IPES). In addition, output arrays of indices should be optional as to whether they are generated, with the default being false.

As a related note - wouldn't it be nice if LabVIEW could choose whether to create an array depending on whether the sub-VI output is wired or not? I think LabVIEW does take wiring into account within a single VI, but not in terms of connections to sub-VIs - please correct me if I'm wrong. I wonder if marking the subroutine as "inline" would make any difference?