Leaderboard

Found a fix for this. It should be fixed in LV 2020. The bug ONLY affects copying from a 1-element cluster of variant to a variant. Or a cluster of cluster of variant to a variant. Or... you get the idea... "any number of cluster-shells all containing 1 element, culminating in a variant" being copied to a variant. This was a fun bug... consider this: The memory layout for an byte-size integer is { 8 bits } The memory layout for a cluster of 1 byte-size integer is { 8 bits } They are identical. "Cluster" doesn't add any bits to the data. That's just the type descriptor for the data in that location. This is true for any 1-element cluster: the memory layout of the cluster is the same as the memory layout for the element by itself. This is true even if the 1 element is a complex type such as a nested cluster of many elements or an array. When a VI is compiling, if data needs to copy (say, when a wire forks), LabVIEW generates a copy procedure in assembly code. For trivial types such as integers, the copy is just a MOV instruction in assembly code. But for compound types, we may need to generate a whole block of code. At some point, the complexity is such that we would rather generate the copy procedure once and have the wire fork call that procedure. We want to generate as few of those as we have to -- keeps the code segment small, which minimizes page faults, among other advantages. We also generate copy procedures for compound coercions (like copying a cluster of 5 doubles into a cluster of 5 integers). Given all that, LabVIEW has some code that says, "I assume that type propagation has done its job and is only asking me to generate valid copy procs. So if I am asked to copy X to Y, I will remove all the 1-element shells from X and all the 1-element shells from Y, and then I will check to see if I have an existing copy proc." Nowhere in LabVIEW will we ever allow you to wire a 1-element cluster of an int32 directly to an int32. So the generator code never gets that case. In fact, the only time that we allow a 1-element cluster of X to coerce directly to X is... variant. The bug was that we were asking for a copy proc for this coercion, and the code was saying, "Oh, I have one of those already... just re-use copy-variant-to-variant." That will never crash, but it is also definitely not the right result! We had to add a check to handle variant special because variant can eat all the other types. So if the destination is variant, we have to be more precise about the copy proc re-use. I thought this was a neat corner case.

I'm happy to report that I can reproduce your bug in LV 2019. I'm even happier to report that I cannot reproduce your bug in LV 2020. We did some work on that window for the new release, including some much needed refactoring. Whatever we did seems to have cured this issue. So it'll be fixed soon. I'm glad you have a workaround.

Thank you once again Dr. Powell for sharing this powerful approach. I can see it being used in "Metronome" actor (e.g. Set Period). And I already started to use it in my projects. If you don't mind I would like to ask you another question: I have an actor (A) that launches a sub-actor (B) to delegate some tasks to it. When sub-actor (B) publishes an event, actor (A) gets a message. However I would like to publish that message beyond actor (A). So that actors subscribed to actor (A) would also receive events from sub-actor (B). Currently my approach is to send Observer Registry of actor (A) to sub-actor (B) during initialisation. Then sub-actor (B) publishes its events into Observer Registry of actor (A) directly. Another idea was to republish the event from actor (A) when it gets the message from sub-actor (B). Neither of these methods feel right to me. The first one shares internal reference of the actor (A). The second method is not as efficient (receives, then sends again). How would you approach this?

[Update: NI Bug 974336] There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here). Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet. Coerce to Variant Fail (LV2019).vi Note that adding another element to the outer cluster causes the problem to go away.