I'm seeing some pretty strange behavior in the course of my usual chicanery and I could use some more eyes on it if there are any here patient enough.
Firstly, I'm writing an XML wrapper/unwrapper. The native LabVIEW one is fine, but I wanted to write my own that, while less robust, provides more readable XML and can tolerate changes in datatype more gracefully. My problem is with the XML unwrapper, or rather the malleable VI that wraps it (I'll try not to overload this word too much).
Image 1
![1.png]( "1.png")
In image 1 (above), there are 3 VIs: the sandbox for unit testing my XML wrapper and unwrapper, the XML unwrapper malleable VI, and the XML unwrapper core VI. I'll go through what's happening here.
First the sandbox: So my test data is the cluster constant named "cluster". My XML wrapper VI takes this cluster as input and outputs the XML text seen in the string indicator named "XML". Then the XML unwrapper malleable VI takes this XML text and the original cluster as inputs, and tries to output a cluster of the same structure with all the values populated from the XML.
Within the XML unwrapper malleable VI, the XML is input as a string (unsurprisingly) and the cluster is input as a variant (though this could conceivably be any datatype). This malleable VI is mostly just a wrapper for the core VI, where all the real magic happens. The core VI takes the same cluster (or whatever other datatype) and tries to create a binary string of that datatype using values from the XML. The unwrapper malleable VI then unflattens that string into the input datatype and outputs it.
With me so far?
Image 1 also shows the results of executing the sandbox as so configured. Looking at the sandbox front panel, we can see that the vale of the cluster indicator "Anything Out". This is bad, it should be populated with the values from "XML". There is a simple reason for this, which I will explain.
We can't see anything from the malleable VI, because it is reentrant, but we can see the control values of the core VI, because it isn't reentrant. Here we see the cluster name is "Anything In", the name of the control in the wrapper VI. However, the cluster element in the XML is named "cluster", after the original cluster. Since there are no elements named "Anything In" in the XML, the core VI doesn't find any appropriate vales and outputs a binary string full of nulls.
The malleable surprise renaming the data is the first issue, but I think I had a work around for that. I remember seeing in the openG toolkit years ago something about unwrapping variants. In some circumstances, the datatype in a variant can be LV variant, but if you "unwrap" (this word is getting really overloaded now), the variant, the type in the variant becomes the original type. That's not exactly what's happening here, as we can see the type in the core VI is cluster, but something's going on.
Image 2
![2.png]( "2.png")
Image 2 shows the workaround and the results of running the sandbox with it. In the malleable VI, we "unwrap" the "anything in" input so the type, and hopefully the name, turns back into the original (a cluster named "cluster"). This is done by converting the variant to another variant of type "void". I don't know how it works either. We run it and... Huzzah! The values of the sandbox indicator "Anything Out" are populated. They're all the same values from the XML. The name of the cluster in the core VI control is "cluster." The variant unwrapper worked and now the XML unrapper works! Or does it...
Image 3
![3.png]( "3.png")
In image 3, I've changed the number of calls to the unwrapper malleable VI from 1 to 2. It's the same code as before, and the same inputs as before both times, but now I'm getting different output. We can see the "anything out" indicator is zeroed out again, and in the core VI control, we can see the name of the cluster has changed back to "Anything In."
So what's going on here? Is "unwrapping" the variant not the right fix? Why is the malleable VI renaming the data anyway? Why does it work for a single call, but not for multiple calls. There is something going on under the hood here and I think only a NI software engineer can answer.
Anyway, thanks for reading about my silly problem. Any comments or suggestions are appreciated.
Edit: also I see the error wires and realize people might think an error is causing the VI to not actually execute a second time. This is not the case. I've inspected the output since taking the screen shot and there is no error. I only added the error wire shift register in to eliminate parallelism.
