PJM_labview Posted January 25, 2007 Report Share Posted January 25, 2007 As seen in the attached example, sometimes (unfortunately quite often) the coercion to variant is no longer working properly. The nameless type always coerce well, but the named type (data has name) do not. The data name is lost most of the time or, as seen below, another data name instance is substituted ... If you play with the attached VI, you will see the name changing from empty to correct to incorrect under no specific circumstances that I can reproduce (although in this case the fact the it use the other typedef instance name seam to give some indication of the direction to dig for NI people). Download File:post-121-1169710597.llb This bug has been present since LabVIEW 8.0. The only work around that I know of is basicaly to never coerce to variant but instead use "To Variant" primitive ( ) on all the wire that will be passed to a variant input.PJM Quote Link to comment
Ton Plomp Posted January 25, 2007 Report Share Posted January 25, 2007 Good one you caught, I was trying to start with OpenG Package builder, and somehow couldn't add VI's to my package.... Then I noticed saving and opening of a .ogbd file wasn't consistent the 'Package Files' tab was always empty. I found out that the [Files] section had no entries, debugging let me to this bug... somehow the read-key doesn't suffer from this problem (maybe because there is only one item under [Files]. I also noticed that the Package builder uses a quit old version of the variant config VI's (2.4 instead of 2.7) PJM, have you tested if this happens on all datatypes? If packagebuilder needs to be updated that's quite some work. Probably builder also needs updates..... Or builder should be elimated in 8+ EDIT: In Package builder I have preceded every Write Key (Variant) and Read Key (Variant with the to variant primitive, now the package builder works. I tried to look up every to variant coercion dot with VI Analyzer but the number was a little bit to overwhelming... Ton Quote Link to comment
PJM_labview Posted January 25, 2007 Author Report Share Posted January 25, 2007 Ton ...PJM, have you tested if this happens on all datatypes? ... I think that it does happen for all data type. I certainly have seen it happening a LOT since LV 8.0, but it is possible that this might be happening only for typedef or strict type def... ...I was trying to start with OpenG Package builder, and somehow couldn't add VI's to my package.... ... EDIT: In Package builder I have preceded every Write Key (Variant) and Read Key (Variant with the to variant primitive, now the package builder works. ... Ton Cool! I knew that the Package Builder was having issue above 8.0, but I never spend the time to investigate what was the issue. Now that we know what the bug is this should be easy to fix. Good catch. PJM Quote Link to comment
Ton Plomp Posted January 25, 2007 Report Share Posted January 25, 2007 PJM, do you know if it is possible to do a search and replace with a merge VI? would be fun if we could replace the read (and write) variant.config vi's replace with a merged one including the to variant primitive Ton Quote Link to comment
Darren Posted January 25, 2007 Report Share Posted January 25, 2007 I posted a VI Analyzer test on the NI Discussion Forums that will detect any terminal on the diagram that is a Variant data type that also has a coercion dot. See here. -D Quote Link to comment
Ton Plomp Posted January 25, 2007 Report Share Posted January 25, 2007 Thanks Darren, I already ran it and posted it at the OpenG bug forum. (this starts to be a major cross-post issue :laugh: ) Ton Quote Link to comment
Ton Plomp Posted January 26, 2007 Report Share Posted January 26, 2007 PJM, here's my (working) version of OGPB.llb Download File:post-2399-1169792253.zipin 8.2 off course Ton Quote Link to comment
Aristos Queue Posted January 26, 2007 Report Share Posted January 26, 2007 The bug looks like a side effect of the speed optimization for Variants that went into LV8.0. "If types are same, just preserve data." I think that only the types were compared, not the name of the type. I had no idea that was important to anyone, and so it doesn't surprise me that whoever wrote the code in the Variants was the same way. Data type name is something that we tend to play pretty fast and loose with within the LV code -- up to now, in my mind, it's pretty much there so that "Create Control" gets a decent label. Didn't know it was useful for something. Someone should file the bug... I'm focused on other things today. Quote Link to comment
Ton Plomp Posted January 26, 2007 Report Share Posted January 26, 2007 Someone should file the bug... I'm focused on other things today. PJM since you found it, could you do that? Ton Quote Link to comment
LAVA 1.0 Content Posted January 26, 2007 Report Share Posted January 26, 2007 PJM since you found it, could you do that? I filed a report... I post the CAR when I get it. Quote Link to comment
PJM_labview Posted January 27, 2007 Author Report Share Posted January 27, 2007 PJM, here's my (working) version of OGPB.llbDownload File:post-2399-1169792253.zipin 8.2 off course Ton Thanks, this will come in handy. I filed a report... I post the CAR when I get it. Thanks jimi PJM Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.