Problems understanding workarounds for 192804

[Michael_Roth]

Hello,

i have a problem that looks very similar to that described in "Known Issue #192804" (http://www.ni.com/white-paper/13164/en#192804_by_Category).

The Problem is I don't quite understand the workarounds (For example, what is a "prim"?, or what is meant by "use this constant as the new type for the variant", a typedef? or what?).

Could anybody be so kind and make a short example VI how this Workarounds would look in a VI?

Many thanks in advance.

[Norbert_B]

"prim" is a common abbrevation for "primitive" which are most (if not all) 'yellowish' block diagram functions. So this refers to the yellowish "Variant To Data" function.

The bug obviously is that the type is modified during compilation. By recreating it, you force LV to recompile the code and this should resolve the issue. But the 'type' you wired must be created new.

So the procedure suggested here is to open a new VI. Drop the "Variant To Data" and connect the constant data type you were using (copy) from your original VI. Run the new VI once. Create an indicator on the "data" output of "Variant To Data", cut it out and put it into your original VI. Change it to a constant, remove the "datatype" constant and use the new constant instead....

I think, suggestion 2 should be quite clear.

Norbert 

[Michael_Roth]

I managed to get it working with now with solution #2. First I could find the non-variant "Unflatten from String" Function (we sadly are using the German LV version).

In my program the type i use for Variant to Data is a typedef. When i follow your instructions i get an indicator/constant that is also linked to that typedef. Is that how it is supposed to be? I couldn't get it working with that solution.

Anyhow it's working now, so it's ok for me.

Thank you for your help.