Jump to content

"Sort Using Other Array" XNode


Recommended Posts

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:

post-15106-0-20074100-1412292227.png

LabVIEW 2014 version:

Sort Using Other Array.zip

LabVIEW 2009 version, uploaded by request:

Sort Using Other Array.zip

Edited by flarn2006
Link to comment

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

 

Also, you could have used OpenG like this:

post-27809-0-22824600-1412294305_thumb.p

 

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 :(

Link to comment

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:

post-15106-0-28617000-1412295730.png

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 by flarn2006
Link to comment

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.

Link to comment

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. :shifty:  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 :D)

Edited by ShaunR
Link to comment

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 :thumbup1:

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

Link to comment

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 :thumbup1:

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

Done; check the OP.

Link to comment

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. :throwpc:

 

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

 

This is what LV2014 saves for 2009:

post-27809-0-98592900-1412534423_thumb.p

 

This is what it should have saved:

post-27809-0-38839800-1412534435_thumb.p

Link to comment

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. :throwpc:

 

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

 

This is what LV2014 saves for 2009:

attachicon.gifAdaptToInputsBroken.png

 

This is what it should have saved:

attachicon.gifAdaptToInputsFixed.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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.