LabVIEW
[Bug] Malleable VI / Type Specialization Structure broken wires
Hi all,
I've run into a recurring issue with wires connected to malleable VIs breaking when changing an input type to another supported type. This is in LabVIEW 2020.
The attached VI and VIM demonstrate the issue. The VIM asserts the input is one of a 1D float array, a waveform, or a 1D waveform array:
If the input to the VIM is changed from a 1D float array to a 1D waveform array, the caller breaks, even though this type is supported.
Digging deeper, the root cause appears to be nested Type Specialization Structures (TSS), which get inlined when one of LabVIEW's assert VIMs is placed in a TSS. If the inputs are changed in a certain order (in this case changing a 1D float array to 1D waveform, but NOT vice versa) the nested TSS breaks, and the top level TSS case becomes inactive. LabVIEW then evaluates the other TSS cases until it finds an unbroken case, or the last case. The problem is LabVIEW still considers the broken nested TSS in the inactive case as a reason to break the calling VI.
The error message below was captured from another project with the same issue, and the details indicate a dependency is broken, possibly indirectly, and refer to a deeply nested malleable VI instance (that long list of GUID named VIs).
The broken VI can be fixed with a forced recompile (either by save, close, reopen calling VI, or ctrl + click run button), but it shouldn't be broken in the first place. The broken wires and run arrow make the user think they've done something wrong when they haven't, and is confusing to say the least. The issue can also be avoided by not using assert VIMs in TSS, though that kind of limits the usefulness of the assert VIMs.
Is this a known bug with nested Type Specialization Structures / malleable VIs?
Is there a recommendation against using nested Type Specialization Structures?
I was able to fix it by connecting the waveform array (resulting in broken wire), saving and exiting, and re-opening. Now it works for either array. I work in 2017 so I don't know much about Type Specialization Structures, but from the description I figured a recompile might be the fix in some way.
Thanks for verifying the broken wires and suggesting a workaround, Redhawk. A recompile will usually fix it (ctrl+click run arrow does the job).
The workaround I've resorted to using is to not call the assert VIMs inside the type specialization structure. I've either moved them out of the structures where possible, or copy the content of the assert VIM into the calling structure to avoiding the nesting.
In the posted example, the breakage can be fixed by moving the Assert Floating Point Numeric Type.vim outside the TSS:
In other cases, such as Assert Array Dimension Count.vim, I've needed to copy the internal logic for the dimension checks into the calling TSS / VIM.
The main use case I have for the malleable VIs is as part of a library API, and have had at least one user run into the broken wires without knowing how to fix them. The workarounds I've got are good enough for now, but it'd be nice if NI acknowledges and fixes the issue so I (and others) can use VIMs / type specialization structures / assert VIs properly.
Glad to hear the workaround has helped. Out of curiosity what version of LabVIEW are you using? I've done a quick test to see if this issue is still present in LV2022 Q3 and it seems to be fixed, though there are still malleable VI issues.
Holy crap, I have spent hours chasing down this bug. Thank you SO MUCH for figuring out the workaround!
In my case, the VIM itself wasn't showing any errors in the Error List, but the caller had broken wires aplenty and a "This VI failed to compile" error. A Heap Peek showed a red "SelList" corrupted element, but wouldn't tell me what that was, and Google was not connecting the dots between that error message, Heap Peek code, and VIM's.
It wasn't apparent it was the VIM itself (as opposed to some other corrupted item or "insane element") until I poked around and found that deleting and recreating any of the terminals on the VIM would fix it, then I found this thread and voila, no more issues!
Just wanted to post to 1- say thanks a million, and 2- add some keywords for any future Googlers to find.
