[CR] Hooovahh Array VIMs

[hooovahh]

View File

Hooovahh Array VIMs

---

Here is the Hooovahh Array VIMs.  This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques.  In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette.

Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels.  And a few functions have added performance based on other inputs.  For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted.  The Filter 1D array can also be more efficient if the input is known to not contain any duplicates.

Because these packages contain VIMs, they require LabVIEW 2017 or newer.  Having these functions be VIMs mean all functions work with various array data types.  Included functions are:

• Conditional Auto-Indexing Tunnel
• Delete Elements from (1D or 2D) Array
• Filter 1D Array
• Index (1D or 2D) Array, Scalar, Row, Column
• Remove Duplicates from 1D Array
• Reorder (1D or 2D) Array
• Reverse 1D Array
• Slice 1D Array
• Sort (1D or 2D) Array
• Convert 1D to 2D
• Convert 2D to 1D
• Find Subarray
• Force Array Min/Max Size
• Foreign Key Sort

---

• Submitter
  hooovahh
• Submitted
  10/11/2017
• Category
  *Uncertified*
• LabVIEW Version
  2018
• License Type
  BSD (Most common)

 

[Porter]

I finally had a moment to take a look at this. Nice job!

I particularity like the conditional auto-indexing tunnel vim and the delete elements from array vim.

I will have to tell our developers to start moving away from the openG array VIs.

Are you going to put this up on github or the NI Tools network?

[hooovahh]

I didn't plan on git or Tools Network.  The Tools Network has a larger barrier to entry than I want to mess with for something like this.  And I've been lazy and just never done anything with Git.  The source is all there when you install it, the only thing missing is the VIPM config, and a Pre-Build VI.

I use Remove Duplicates From Array probably the most, and also I think I use Foreign Key sort quite a bit.

[Michael Aivaliotis]

On 9/23/2019 at 1:56 PM, hooovahh said:

I didn't plan on git or Tools Network.  The Tools Network has a larger barrier to entry than I want to mess with for something like this.  And I've been lazy and just never done anything with Git.  The source is all there when you install it, the only thing missing is the VIPM config, and a Pre-Build VI.

I use Remove Duplicates From Array probably the most, and also I think I use Foreign Key sort quite a bit.

Not having looked at your code, do you think this should go into OpenG? How can we improve OpenG? Where is the OpenG repo?

[hooovahh]

13 hours ago, Michael Aivaliotis said:

Not having looked at your code, do you think this should go into OpenG? 

Sure, why not.  OpenG array tools are great but could have used improvements over the years, from inlining, to conditional terminals, and now VIMs.  But to pump the brakes a little, I heard some rumors NI might also be in the works trying to make their own VIM array functions.  No solid timeline and no idea what functions they are tackling, or distribution method.  Then again we don't need a rumor about what NI might be doing to dictate what we are doing.  Also I have no idea who is in charge of OpenG, or how to contribute to it. <shrugs>.

[JKSH]

20 hours ago, Michael Aivaliotis said:

How can we improve OpenG? Where is the OpenG repo?

https://sourceforge.net/projects/opengtoolkit/

@Rolf Kalbermatter has access.

[hooovahh]

Oh another consideration with this is currently OpenG Array tools work in LabVIEW 2009+.  This would make a version which would only be compatible with 2017+.

[Michael Aivaliotis]

4 hours ago, hooovahh said:

Oh another consideration with this is currently OpenG Array tools work in LabVIEW 2009+.  This would make a version which would only be compatible with 2017+.

We can create a VIM array package for OpenG that is separate from the other array package. We could call it something else. So it could be distributed in 2017. Currently the entire OpenG sources are in a single repo. So you have to build everything in one LV version (2009). If we made each package its own repo then it could have its own LV versioning roadmap separate from the whole. See discussion here.

[mcduff]

Not sure if VIPM could do this, but, if it could add the following lines to the LabVIEW ini file,

ExternalNodesEnabled=True
XNodeWizardMode=True

I think the VIMs would work in 2009+, I don't have the versions to test it.

mcduff

[hooovahh]

VIPM packages support Post Install VIs, and Post Uninstall VIs, and in there you could have a VI that edits the LabVIEW.ini file to add or remove things.  I also don't have a 2009 machine to test it with, but if this ever became an official thing I'd encourage the use only after the point NI made VIMs official.  I didn't use VIMs in pre-2016 for anything real just experimenting and don't know the stability of it in earlier versions.

[Michael Aivaliotis]

12 hours ago, hooovahh said:

VIPM packages support Post Install VIs, and Post Uninstall VIs, and in there you could have a VI that edits the LabVIEW.ini file to add or remove things.  I also don't have a 2009 machine to test it with, but if this ever became an official thing I'd encourage the use only after the point NI made VIMs official.  I didn't use VIMs in pre-2016 for anything real just experimenting and don't know the stability of it in earlier versions.

NI does (Stephen Mercer) not recommend using them pre-official release version.

[Antoine Chalons]

@hooovahh Hi,

Somehow, I have Array VIMS 1.2.0.12 installed on my computer, the latest version here on LAVA CR is 1.2.0.9, I can't quite remember where I found 1.2.0.12

Has it been publish and them removed or is it just well hidden?

 

Edit :

Ha, I see it comes as a dependency of the Tremendous TDMS package 1.0.0.4

Edited June 25, 2020 by Antoine Chalons

[crossrulz]

VIPM is showing 1.2.09.  I thought I saw a notice on LinkedIn about Hooovahh Array VIMs being released.  I don't have access to check vipm.io at the moment (blocked by work firewalls).

[Jim Kring]

2 minutes ago, crossrulz said:

VIPM is showing 1.2.09.  I thought I saw a notice on LinkedIn about Hooovahh Array VIMs being released.  I don't have access to check vipm.io at the moment (blocked by work firewalls).

We should have a fix for that (firewall issue) out in the next week or so. Thanks for your patience.

[hooovahh]

Yeah sorry for the confusion.  I don't have official release process in place for this community stuff and I really should.  I did make a newer version of this for the TDMS package and just included it in it because I wanted to make consuming my code easiest for other developers.  But with the efforts of VIPM, and GCentral I need to evaluate the best way to share and hold myself to the process to avoid confusion in the future.

[bjustice]

Hi Hooovahh!

I think I found something that could be considered a bug?

I saw that a sort option was added to the remove 1D duplicates VI.

It looks like the old version of this VI was left in the package.  (Presumably to protect backwards compatibility)

However, something must have happened, and I'm seeing that the connector pane on the old version of the VI got rotated.

[hooovahh]

Pretty weird right? I just noticed that recently.  I've moved on to using the newer version with the Sort option, since it is better than the original.  But I opened some legacy stuff and saw it was rotated like that.  I had to relink some VIMs, and the whole purpose of leaving the old method was to preserve existing functionality, but now that is lost.  Not sure how that happened.  Thanks for letting me know.  That being said I'm not sure I want to push out an update for such a small change.  I'll see if I have any other Array stuff in my candidates folder and push out some other changes along with that in the future.

[bjustice]

I'm updating my dependent packages to reference the new method.
So, don't feel pressure to push a new package on my behalf.
But it felt like it was worth bringing to your attention.

Cheers!

[MikaelH]

We just migrated to LV2023. and I thought we should update this library as well to the latest.
That did break a lot of code.
E.g.
So the new version didn't accept the old non-typedef sort direction, so I've modified it.

Also the array filter vim, don't support reference wires anymore (e.g. Ctrl Refs).

I also had to add I32 here

The old version did handle it

[hooovahh]

Also great feedback thanks.

Sorry about the type def input breaking.  That was sort of needed.  Previously you could wire any numeric to it and it would accept it as a VIM input, but I really did want to only allow that enum.  So I made it a type def, then forced it inside to only allow that.  I knew that would break things, but it is a simple fix and if I were someone like NI I could make the mutation automatic in previous versions.

The filter not accepting references is not intentional.  I added some performance improvement stuff, and I see how that this relies on the Search Sorted 1D Array, but some data types aren't supported in the sort function.  In these cases the right answer is to not use that function, and fall back into the less performant method.  Thanks for catching this it will be in the next update.  Control references do work for filtering Scalar data types, just not filtering a 1D with a 1D.

The filter only accepting an I32 is intentional, but yes I could see that any numeric should be accepted.  I thought it would just coerce to the right type, just like the primitive index does.  I'll remove the strict I32 input requirement.

[hooovahh]

Okay new release 3.1.0.16 should fix the issues I mentioned.

[MikaelH]

BTW, can you also update this library to make LV2023Q3 to build applications with these VIMs to work ;-).
We use these VIMs a lot, and in LV2023Q3 several VIs stops the builds complaining that "VI is not in memory".
And to get the App building to accept these VIs I have to replace your VIMs with the old style OpenG version :-(.
 

[hooovahh]

On 10/23/2023 at 2:20 AM, MikaelH said:

BTW, can you also update this library to make LV2023Q3 to build applications with these VIMs to work ;-).
We use these VIMs a lot, and in LV2023Q3 several VIs stops the builds complaining that "VI is not in memory".
And to get the App building to accept these VIs I have to replace your VIMs with the old style OpenG version :-(.

Yeah it sure would be great if NI fixed that bug wouldn't it?

Back in May I did open a service request with NI for a build issue related to VIMs.  After some back and forth they did assign a bug number to it 2401803.  The cause was a VIM with a VIM inside it, but no classes involved.  Attached is the project which demonstrates the issue.  For some reason the project takes a while to open, then once opened the VI runs fine, but the build to an EXE fails saying it isn't in memory. 

NI's advice was to use Disconnect Type Defs in the build.  But in larger applications that causes different issues.  NI has said this will be likely be fixed in 2024 Q1.  When I filed that bug I told NI that I had users of my VIMs that would complain and that they should fix this.  Because if I'm complaining, they are going to get others having the same issue.

Also NI just posted LabVIEW 2023 Q3 Patch 1, which fixes a bug 2296528 related to VIMs.  I haven't tested it yet but it is possible this fixes this build issue.

Filter VIM Issue VI Not In Memory (1).zip

[hooovahh]

Okay new version release 3.1.1.22.  I had to flatten a few VIMs in the Filter 1D Array VIM until builds started working again.  To be clear this is a bug on NI's side, and they sound like they will fix it, but I understand how frustrating it is to have builds fail for seemingly no good reason.  I also made a few minor fixes for clusters, and a couple other data types.

[MikaelH]

FYI, we have switch back to 2023Q1, which don't hate VIMs.
We can now finally build our applications without any LV crashes and any modifications to get the build to work.