LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Search 1D Array ... Changed in 2020 SP1


@Hooovahh wrote:

@Darin.K wrote:

Seems risky to make a change like this (1) without warning (2) in a SP instead of major release and (3) without a beta test.  Had there been a beta, I would have easily fixed this for them.  Better late than never, drop this in as a replacement in <vi..lib>\Array\Search Unsorted 1D Array.vim  

 

I just added a dummy case to allow an element to be wired first.


I kudo'd you and thought it was the solution, until I realized it also allows for wiring an array of one data type, to a scalar of a different one, since it will select the dummy case as being unbroken.


I noticed this myself.  I tried a few things, and figured that the only real solution would be to XNode it or tweak the primitive.  Always one too many loopholes trying to massage the VIM.

 

For me, the current shipping version is useless, simply too jarring to have the broken wire.  My fix works just fine for me since I would not be inclined to wire a mismatched scalar, and at least when I do it gives the "correct" answer....

 

As they say, "the only winning move is not to play".  The next patch should revert the palettes and these VIMs should be relegated to hidden 'gems' in vi.lib.

Message 41 of 44
(1,734 Views)

@Darin.K wrote:

As they say, "the only winning move is not to play".  The next patch should revert the palettes and these VIMs should be relegated to hidden 'gems' in vi.lib.


I looks like 2021 "fixed" this.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 42 of 44
(1,571 Views)

So a side effect of this just absolutely crushed me for a day before I finally figured it out. Posting it here in case someone else has a similar problem in the future.

 

A project I'm working on with some other developers utilizes a plugin architecture utilizing PPLs. One of our developers pushed out code for a new plugin that ran fine in development but always failed with Error 1498 (at Get LV Class Default Value.vi) when we called it from the rtexe.

 

Turns out the developer was using 2020 SP1, whereas most of us are still using regular LV2020, and thus used Search 1D Unsorted Array since it was the only one on his palette. Because (I assume) the vim existed outside the class, the PPL compiled without errors. It took a whole day of going off in a completely different debugging direction chasing down the 1498 error before we finally saw this buried 4 subVIs deep. Swapped it out with Search 1D Array primitive and now the 1498 error is gone and the PPL can be loaded properly.

 

If I can save anyone even a fraction of the frustration I've felt for the last 24 hours tracking this down then I've done my duty.

Message 43 of 44
(1,501 Views)

@DHerron wrote:

Because (I assume) the vim existed outside the class, the PPL compiled without errors. 


I'm sure people have used .vilib .vims in PPL before.

 

There might be specific issues with this .vim or specific details in your use case.

 

That actually makes it a nastier problem. 

 


@DHerron wrote:

If I can save anyone even a fraction of the frustration I've felt for the last 24 hours tracking this down then I've done my duty.


Yes, thanks! +1

 

If you can reproduce this in a simple example, I'm sure people would like to see that. 

0 Kudos
Message 44 of 44
(1,475 Views)