So first I'm on LabVIEW 2015 SP1 32-bit, Windows 7 x64. I have a case where my relatively large test system, returns data from a Variant to Data call, where the input is an empty variant, and the error has an error in. Attached is a screenshot of the paused probes on Windows.
The steps to reproduce it are a bit complicated, but the data being returned, was the last valid data from a previous call when there was no error. If I add an always copy the issue goes away.
I searched the 2016 and 2017 release notes and didn't see anything regarding this fix. Is this a known issue fixed later? I don't feel like putting always copies all over the place catching this issue every where I use a Variant to Data. I tried coming up with a small setup that reproduces it but couldn't. Thanks.
EDIT: Oh wow I just realized that my probe in the second image is actually before the always copy, that confuses me a bit. It is possible we could update the system to 2017 but it would be quite a pain since we talk to some RT devices, and would need to update them as well.
I usually put select: if there is an error after variant to data, use default data (also coming to the type specifier). If I needed to store old data iun case of error, I would do it manually, more robust.
I wonder if it is an undocumented feature of the compiler or Variant to data or debugger only - it does not reallocate memory every time if error has happened and it does not need to copy data. But understands it is empty when it is forced to reallocate it. I will try...
Thanks for the reply. This was observed in the IDE as well as a build EXE so it is a compiler issue I'd assume. I certainly can default to the type input of the Variant to Data, if there is an error in the conversion but I sorta thought that's what the function would do since my input is the default data type for the data (the default of the type def constant). And also there is the fact that this would mean having to write scripting code to fix all the places this exists in my code when presumably this is a compiler bug that needs to be fixed.
Still working on minimizing the code needed for reproducing this bug, but I can confirm this is still present in LabVIEW 2017, and the always copy does fix it. I didn't plan on updating right away, but I wanted to see if this was still an issue.
Okay someone in blue had better reply to this after this post. I have trimmed down the project to a reproducible state. I tried trimming the code down more but had some issues once I did. Vanilla LabVIEW 2017 should be all that is needed, the rest of the dependencies should be included. Extract the attached zip and run Variant Data Bug Test.vi and follow the instructions on the front panel. Basically it can switch between generating an error, and no error. Once the VI sees a no error, it remembers that reply value, and will return it the next time there is an error. This has been seen in 2015, 2017, and in source and EXE running in Windows 7. Can I get a CAR for this? Thanks.
Anyone at NI feel like assigning a CAR for this? I got a friendly reminder email from the forums asking if my problem has been solved on this thread. Despite posting screenshots of the bug 8 days ago, and a work around, on an issue in the latest version of LabVIEW, and then 2 days later providing a full self contained set of code demonstrating the issue, I've seen no CAR and no one from NI has even acknowledge the bug. I'm getting a bit frustrated. The amount of effort I've put into tracking this down has been non-trivial and I'd like to know this will be addressed in future versions of LabVIEW.
Thanks Brian for posting this.
I should be p!$$3d!! But I'm not.. 😞
We encountered a similar (same?) bug on a recent project using LV 2015 and had to implement workarounds in numerous places. The main person implementing the code felt bad because he thought he poorly coded the solution. When I looked at it, I was baffled.. We had implemented a solution that worked in the past LV2012 but did not work for this newer client. It never even crossed my mind that there could have been a bug related to that function.
Also using LabVIEW 2015 SP1 32-bit, Windows 7 x64.
Side note... We encountered something similar using the database function (can't recall its name - this PC doesn't have LV) that converts variant to data. We gave up on that one and created our own. I will now dig it up and post it. The issues may be related.
-- sigh --