Jump to content

[CR] Hooovahh Array VIMs


Recommended Posts

  • 1 year later...

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?

Link to comment

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.

Link to comment
  • 2 weeks later...
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?

Link to comment
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>.

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment
  • 8 months later...

@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 by Antoine Chalons
Link to comment
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.

  • Thanks 1
Link to comment

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.

Link to comment
  • 3 years later...

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.

image.png.9695da372702d2361d548db4f1a780d6.png

Link to comment

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.

Link to comment

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.
image.png.e22066e80eb572639941575f0c1067a0.png
Also the array filter vim, don't support reference wires anymore (e.g. Ctrl Refs).

I also had to add I32 here
image.png.677fb2dc103f621ce3a60fe17586fb15.png
The old version did handle it

Link to comment

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.

Link to comment
  • 2 weeks later...

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

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

Link to comment

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.

Link to comment
  • 3 weeks later...

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.