LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unknown string when logging Variant to binary

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.

1984_0-1709032247527.png

 

2.

1984_1-1709032297730.png

 

3.

1984_2-1709032381722.png

 

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.


 

logger-snippet.png

0 Kudos
Message 1 of 18
(659 Views)

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:

 

raphschru_0-1709038437411.png

 

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.

0 Kudos
Message 2 of 18
(624 Views)

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.

 

remove name from variant.png

0 Kudos
Message 3 of 18
(618 Views)

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.

0 Kudos
Message 4 of 18
(614 Views)

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.

0 Kudos
Message 5 of 18
(597 Views)

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

 

altenbach_0-1709048841361.png

 

0 Kudos
Message 6 of 18
(570 Views)

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

0 Kudos
Message 7 of 18
(560 Views)


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.

0 Kudos
Message 8 of 18
(558 Views)

You could just flatten the data to a string. I doubt it would be slower but have not tested.

0 Kudos
Message 9 of 18
(550 Views)

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.

0 Kudos
Message 10 of 18
(531 Views)