LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Type Def'ed Cluster Appears Void?

Solved!
Go to solution

I was working with some hardware abstracted classes, and building them into VIPM packages.  The source was fine and the build seemed fine.  Then I go to drop them on my palette and an array of a cluster appeared as if it was a broken wire...sorta.  Just watch the video:

 

https://www.screencast.com/t/XwSaRtSFY

 

After that I closed and re opened LabVIEW and things were fine again so I believe it to be something I did during the video that forced a compile of that typed control which might have been the issue.  Since then I haven't been able to reproduce this issue.  Anyone seen this before?  This is in 2017 SP1 F1 32-bit Windows 7 x64.

0 Kudos
Message 1 of 10
(3,070 Views)

That video tried my patience... not used to coding that slow. Smiley Tongue

 

The message about the "lock" reminds me about not being able to move VIs around in a Library (to a private scoped folder for example) while an application is currently open and running on a RT target that uses types in a library under the Windows side. Not sure what I can say beyond that observation.

 

It would be very interesting if you could re-create or trap that issue.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 10
(3,049 Views)
Solution
Accepted by topic author Hooovahh

I remembered something similar to this and it looks to be tied to CAR 654251 which has the description "SubVI with cluster containing a class has a Void Wire when initially added to LabVIEW Palettes through VI Package Manager (VIPM)". It sounds like what you are running into so if you want to try any of the listed workarounds they are:

 

1. After installation of the package, switch the order of elements in the cluster.
2. Add the SubVI directly from disk rather than through the LabVIEW Palettes. The subVI behavior will depend on where the SubVI was first added from (disk or palette).
3. Save the VI you create containing the SubVI, close it, then reopen it. (You mentioned closing LabVIEW fixed the problem)

 

The person who originally ran into this chose to disable mass compile after installation for the VIP and then write a post-install VI to swap the order of the elements in the particular cluster (make sure you aren't using the regular unbundle int hat case).

Matt J | National Instruments | CLA
Message 3 of 10
(3,027 Views)
That video tried my patience... not used to coding that slow. Smiley Tongue

I'll fast forward it next time.

 

I remembered something similar to this and it looks to be tied to CAR 654251 which has the description "SubVI with cluster containing a class has a Void Wire when initially added to LabVIEW Palettes through VI Package Manager (VIPM)". It sounds like what you are running into so if you want to try any of the listed workarounds they are:.


Yes this sounds exactly like what I'm seeing.  Those steps sound like a pain to automate.  Especially from a general building process where it isn't know if this will be an issue until it is tested.  Package building for me follows the same rules from package to package in terms of pre/post build/install/uninstall actions and making something custom fragments the code base a bit.  I'll see what I can get to work.  Thanks alot.

0 Kudos
Message 4 of 10
(3,010 Views)

@Ben wrote:

That video tried my patience... not used to coding that slow. Smiley Tongue

 

 

Ben


That bit of bragging almost demands a "Jing" to back it up.  From anyone else , I'd call it B.S.  but, let's see the master at work and teach us.


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 10
(2,961 Views)

What? The Smiley-tongue was not enough to indicate sarcasm?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 10
(2,949 Views)

@Ben wrote:

What? The Smiley-tongue was not enough to indicate sarcasm?

 

Ben


Nope, missed the emoji.

crazy%20lol.gif


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 10
(2,945 Views)

Hooovahh, did you have any luck here?

I think I'm just now encountering this exact issue.  I  can't seem to find a graceful solution.

0 Kudos
Message 8 of 10
(1,412 Views)

Okay well one good thing is I did archive several of my Jing videos and put them on Youtube and this happened to be one of them.

 

https://youtu.be/4e3Rz8cg1hU

 

Since I haven't seen this in recent versions of my reuse library I'd say either a fix came in with newer versions of VIPM, or newer versions of LabVIEW.  I've primarily been using 2020 SP1, but 2018 also uses these libraries.  The original issue was mentioned using 2017.

0 Kudos
Message 9 of 10
(1,398 Views)

Bizarre,

I'm using LV2020 SP1 32-bit.

Your video and description match exactly what I'm seeing.

I rebuilt my code by swapping the offending cluster with a class solely for data encapsulation.  This yielded success.

I'll poke a bit more, but the bug definitely still appears to be present, atleast in some capacity.

0 Kudos
Message 10 of 10
(1,389 Views)