[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.

Hey everyone,
 
I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
 
As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
 
Does anyone have any knowledge or experience with this? 
 
Cheers,
 
Tim

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example.
I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.)
DVRtest.zip

My colleagues and I use the Fit VI to Largest Decoration function in OpenG all the time, and it (usually) works like a charm.
 
I've got a fairly small Project, a simple State Machine that takes readings from a Vernier SensorDAQ device and plots it on a graph.  I'm using a Queued State Machine pattern, so I begin by creating the State Machine Queue and enqueuing the Initialize State.  The first thing I do inside Initialize is Fit VI to Largest Decoration, and it throws Error 1, pointing to the final FP.PanelBounds Property node that it is setting to resize the Window.  I also watched this function run with Highlight Execution turned on, and sure enough, the Error line was OK until it got to that final Write to the Property node.
 
My initial suspicion was the SensorDAQ function, even though it hadn't been called.  So I took it out, but the error persisted.  I also tried making the Fit VI to Largest Decoration the first VI to be run -- same error.
 
Ohh, an idea.  The VI in question was written by a colleague, who is not big on LabVIEW style.  This morning, I rewrote the entire program, keeping only the Front Panel which has, among other things, a Graph on it.  This problem is so weird that it almost has to be something "unconventional" -- I'm going to leave this post here, in case anyone has other insights, but I'm then going to replace the Front Panel and will report back, especially if it fixes the problem.
 
Bob Schor