"Sort Using Other Array" XNode

[Sparkette]

I needed to sort an array by using a different array's sorted order, but I couldn't find a function to do that. The easiest way I could find was to use Index & Bundle Cluster Array with the sorting array first, sort the cluster array, and then unbundle the original values from the array in a For loop. I decided to create an XNode to make this process easier! Since it's an XNode, it can work with any type of array.

Example usage and download:

LabVIEW 2014 version:

Sort Using Other Array.zip

LabVIEW 2009 version, uploaded by request:

Sort Using Other Array.zip

Edited October 4, 2014 by flarn2006

[SDietrich]

I really like the power of XNodes, this is what they are meant for

 

Also, you could have used OpenG like this:

 

This way you can select ascending or descending sort order.

 

 

I think the real difference between the three methods (XNode, OpenG, plain LabVIEW) is the performance for large arrays with memory intensive elements. Unfortunately your code is LV2014 which I do not use (yet), so I can't test your XNode nor investigate the generated code

[Sparkette]

Huh. All this time I thought VI's were backward-compatible. Sorry about that.

If you're interested in the generated code though, here's an example:

Well actually that's after doing a block diagram cleanup; the raw code as it's generated is practically unreadable since everything is placed at (0, 0), and it doesn't programmatically do a cleanup because there's no real reason to.

EDIT: I just realized that the VI snippet will only work in 2014 as well. At least you can see what it looks like.

Edited October 3, 2014 by flarn2006

[GregSands]

In fact, you can even use an XNode version of the OpenG code written by Gavin Burnell, and he has also written a few more Array XNodes including one which replicates your code.

[hooovahh]

Yup an XNode already exists for this along with many others done by gb119 which are pretty neat.

 

Also there is compatibility issues with LabVIEW but you likely wouldn't know that if you just stick with the newest.  For me when I develop code I try to develop it for 2011 knowing the compatibility issues.  Here is a chart showing what versions can open what versions, and what versions can back save to what versions.

 

EDIT:  Oh and as for cleanup, I generally have a constant on my GenerateCode which can enable cleanup when doing debugging, but then turn it off after I'm done.  I also use templates and inline them instead of creating the VI from scratch each time.  It is faster to develop this way, but I suspect the scripting is faster to execute too.

[ShaunR]

the raw code as it's generated is practically unreadable since everything is placed at (0, 0), and it doesn't programmatically do a cleanup because there's no real reason to.

 

A poor excuse.   That is the kind of thing I would expect from a  10 yr old "script kiddie" over at the NI forums You are not, I suspect. (if you are, then we have lots of time to train you better )

Edited October 3, 2014 by ShaunR

[SDietrich]

Huh. All this time I thought VI's were backward-compatible. Sorry about that.

 

Yeah, LabVIEW is, VIs are not. LabVIEW is because it has to, otherwise you would need a "Save for future version" in your old LabVIEW. And VIs are not because every save VI would have to contain a specific block diagram (or parts thereof) for every previous version.

 

Long story short: Would you mind hitting the Save for previous version button on the XNode and exchange the original attachment? Probably save for 2009 or so? That way you would not only do me a favor but you could also reach more users in general.

 

Thanks, S.

 

 

PS:

 

the raw code as it's generated is practically unreadable since everything is placed at (0, 0), and it doesn't programmatically do a cleanup because there's no real reason to.

 

I do the same in my XNodes. Real hackers don't read the generated code anyways, they read the generator

Although I find the concept of optionally cleaning up the code via a constant or using templates worth investigating.

[Sparkette]

Yeah, LabVIEW is, VIs are not. LabVIEW is because it has to, otherwise you would need a "Save for future version" in your old LabVIEW. And VIs are not because every save VI would have to contain a specific block diagram (or parts thereof) for every previous version.

 

Long story short: Would you mind hitting the Save for previous version button on the XNode and exchange the original attachment? Probably save for 2009 or so? That way you would not only do me a favor but you could also reach more users in general.

 

Thanks, S.

 

 

PS:

 

 

I do the same in my XNodes. Real hackers don't read the generated code anyways, they read the generator

Although I find the concept of optionally cleaning up the code via a constant or using templates worth investigating.

Done; check the OP.

[SDietrich]

Thanks for the upload!

 

When I tried to use it with my LV2013 it was broken. The reason was the ability AdaptToInputs.vi which was broken because of the Clear Errors.vi. Apparently LV2014 does nothing to it when saving for a previous version while the functionality in LV2014 actually was extended. This appears to me to be a bug in LV2014 that should be reported to NI. I'll do so in the next couple of days.

 

When viewing the help pages for the LV2013 version and the LV2014 version of the Clear Errors.vi you see that it is not backwards compatible while LV2014 acts as if it was.

 

But back to the topic: I like your XNode and will definitly put it into my archive of LV-gems

 

This is what LV2014 saves for 2009:

 

This is what it should have saved:

[Rolf Kalbermatter]

Thanks for the upload!

 

When I tried to use it with my LV2013 it was broken. The reason was the ability AdaptToInputs.vi which was broken because of the Clear Errors.vi. Apparently LV2014 does nothing to it when saving for a previous version while the functionality in LV2014 actually was extended. This appears to me to be a bug in LV2014 that should be reported to NI. I'll do so in the next couple of days.

 

When viewing the help pages for the LV2013 version and the LV2014 version of the Clear Errors.vi you see that it is not backwards compatible while LV2014 acts as if it was.

 

But back to the topic: I like your XNode and will definitly put it into my archive of LV-gems

 

This is what LV2014 saves for 2009:

AdaptToInputsBroken.png

 

This is what it should have saved:

AdaptToInputsFixed.png

 

While NI goes to pretty extreme lengths to mutate code that has changed between versions when upgrading to a newer version the reverse is not as thorough. It possibly can be considered a bug, but the save for previous has never and won't ever guarantee that code will backsave without broken arrow in the older version.

[SDietrich]

While NI goes to pretty extreme lengths to mutate code that has changed between versions when upgrading to a newer version the reverse is not as thorough. It possibly can be considered a bug, but the save for previous has never and won't ever guarantee that code will backsave without broken arrow in the older version.

I agree, there is no guarantee. It says so in the manual for the Save for previous version and every developer knows how hard it can be to develop new features while keeping full backwards compatibility.

But the aforementioned manual clearly states:

If a VI, project, or project library uses functionality that is not available in the previous version, LabVIEW saves as much as it can and produces a report of what it cannot convert. The report appears immediately in the Save for Previous Warning Summary dialog box.

And such a report is not shown, which definitely is a bug. A fix could be to show a report or - better - to make the saved VI run in the previous version.

 

I therefore contacted the NI-support. The answer I received from there is a case for the cabinet of curiosities (I asked twice and got the same nonsens) but the good news is, they already have a CAR for the issue: 487412.

[JKSH]

I therefore contacted the NI-support. The answer I received from there is a case for the cabinet of curiosities (I asked twice and got the same nonsens) but the good news is, they already have a CAR for the issue: 487412.

 

I prefer to post bug reports to http://forums.ni.com/ -- I seem to get better responses and CARs that way :-D

 

Also, in the event that it's a PEBCAK (http://en.wiktionary.org/wiki/PEBCAK ) instead of a bug, there will be lots more people who can see my issue and point me in the right direction.