02-27-2024 05:17 AM - edited 02-27-2024 05:21 AM
I'm logging a timestamp, a string and a variant to a binary file. Very simple and works fine except that somehow the string "value" gets written to the binary file.
Do the following steps:
1.
2.
3.
So the string "Value" is written into the file, but it does not match the label of the control. (This control is copied from my application to this standalone VI!). I'm positive that in my original application the string "value" comes from the call chain as if change the input name of a variant input 2-3 levels up in the hierarchy then the string "value" in the binary changes to the name of that input. For me it seems that the "value" string somehow sticks to the variant data at the first time the data is converted to a variant, but I couldnt reproduce the issue outside of my app. (also I'm working with malleable VIs, if that matters)
Having that label value doesnt make any sense to me especially if it comes from several layers up in the call chain. Is this a feature? Is this a bug? Can I somehow change this text in my logger VI or can I completely remove it?
pls let me know. Thanks.
02-27-2024 06:55 AM - edited 02-27-2024 07:05 AM
Hi 1984,
This is an expected behavior, because the data name is part of the data type, which is part of the value of a variant.
If you right-click on your variant control and "Show Type", you will see the data name as well.
You can use VI "Set Type Information" from "LabVIEW 20xx\vi.lib\Utility\Data Type" to remove the data name and type definition infos from your variant value:
Note: "Set Type Information" only applies to the top-level value, not recursively to sub-elements (such as cluster elements, array elements, map/set elements...).
Regards,
Raphaël.
02-27-2024 07:04 AM - edited 02-27-2024 07:08 AM
Ok, so it seems I figured out a (bad looking) solution. It looks like that - somehow, somewhere - a name is assigned to the Variant data. This is not an attribute I can get rid of easily, or at least not that I know off.
The Variant_GetName.vi shows this mysterious name and I can change that with the Variant_SetName.vi. The problem is that the latter is extremly slow (about 1ms on my PC) which is a very serious bottleneck. As a workaround the following code does the trick, part which removes the name takes only 1us/iteration.
I still dont know if this is a bug or a feature and I have no clue where the control name upper in the callchain sticked to the variant.
02-27-2024 07:07 AM
Ah ok, I have not noticed this with variants before, but its good to know. Also its good to know that I've figured out how can I remove it so I can save fair amount of diskspace when logging variants.
02-27-2024 07:23 AM
I don't see how your proposed diagram is related even remotely to removing the data name of a variant value.
The VI "Set Type Information" takes less than a microsecond to execute.
Also, if you wonder where does your data name "Value" comes from, it likely is the name of the last wire before your data was converted to a variant.
02-27-2024 09:48 AM
@1984 wrote:
I'm logging a timestamp, a string and a variant to a binary file. Very simple and works fine except that somehow the string "value" gets written to the binary file.
So why exactly does it need to be a variant? Seems like a fragile can of worms.
For example, if you variants have attributes, these will also end up in the file, of course.
02-27-2024 10:57 AM
@raphschru wrote:
I don't see how your proposed diagram is related even remotely to removing the data name of a variant value.
Well, if you run the part of the code inside the for loop it does remove the name of the variant. (Everything else is just there to check the exec speed). I'm not sure how the Set Type Information VI exec time has anything to do with this topic.
02-27-2024 11:03 AM - edited 02-27-2024 11:06 AM
So why exactly does it need to be a variant? Seems like a fragile can of worms.
I made it a variant, because the type of the data can be literally anything and the routine must be really fast. Is there anything I can use which makes more sense (again, data can be anything)? The string is a custom name for the data and it identifies the datatype when we need to check these logs. I'm aware of the possible trouble with attributes at this point the code is written in a way that the variant input for sure has no attributes. I might re-evaluate this later, but for now, no attributes.
02-27-2024 11:20 AM
You could just flatten the data to a string. I doubt it would be slower but have not tested.
02-27-2024 01:19 PM
I think your are confusing the wire name and the data name inside the variant.
A wire has a label and a data type that are fixed at compile-time.
A variant is a data type which value contains 2 things at run-time: an "inner" data type and the value associated to this inner data type.
When you wire e.g. an I32 to a variant input (either directly, making a coercion dot, or via a "To Variant" node), the label of the wire of your I32 becomes the data name of the "inner" data type. So in some sense, the edit-time name becomes run-time. So ultimately, even if your variant control may have some name ("Test data" in your 3rd example), the function "Write Binary File" only flattens the value of the variant, namely the inner data type and the value associated to the inner data type. So this is why you see a different name in the binary data.
The function "Set Type Information" allows to change or remove the data name inside the variant value.
Your code just deletes the variant completely, including its content (data + type), so I don't see what you can do with this...
Regards,
Raphaël.