12 replies to this topic

[John Lokanis]

Just sent this one to NI but thought I would post here to in case anyone had any ideas. See the att zip for a simple example.
It appears that the Variant to Data primitive *or* the Control Value.Get method does not like to work with complex typedef'd data.
This used to work in LV2009SP1 but now give me error 91 in LV2010.
Has anyone else run into this?

-John

Attached Files

•  Variant to Data bug.zip   30.63K   114 downloads

[SuperS_5]

I have see somthing with a simular result. Mine was on LabVIEW 8.6.1. Mine seamed to be a block diagram corruption, but would reappear randomly. I think we had to copy the code into new vi to replace the problem vi. Anyways, I just had to try this one out to see if it was the same problem. Although it is not the same problem, it appears that the invoke node is not giving the correct data. The output of a "to variant" node is not the same as the output of the property node. Selecting "Show Type" (right click menu) of a variant control/indicator gives this output:

"invoke node"

'FP References': cluster of 18 elements 
	'Run': Boolean Refnum 
    	'': void 
	'Loop': Boolean Refnum 
    	'': void 
...

"to variant"

'Value': cluster of 18 elements 
	'Run': Boolean Refnum 
    	'': boolean (TRUE or FALSE) 
	'Loop': Boolean Refnum 
    	'': boolean (TRUE or FALSE) 
	'Abort': Boolean Refnum 
...

I am curious if this has anything to do with it.

Edited by SuperS_5, 24 September 2010 - 02:49 AM.

[mje]

Considering this code works...




...I'd be putting my money on the invoke node?

Interesting none the less, good find.

[John Lokanis]

It is looking more and more like a real bug. If I get a CAR# I will post it.
Now I need to find a way to rework my app to avoid the Control Value.Get method for complex datatypes.

[John Lokanis]

In the process of investigating this, it appears that NI found another bug. If you try this with simple typedef'd datatypes, it also fails if the datatypes are strict. It works if they are not. Unfortunately, making all the datatypes in my example non-strict does not fix this. So, beware of using the Control Value.Get with strictly typedef'd datatypes.
Still no CAR# yet.

[ShaunR]

If you uncheck "Include Data Type" on the VI server reference classes ( Run, abort. Text display tree etc). It works.
And if you save it to 2009 and add the "include Data Type" it fails.
A default setting has changed maybe?.

Edited by ShaunR, 28 September 2010 - 09:25 PM.

[John Lokanis]

If you uncheck "Include Data Type" on the VI server reference classes ( Run, abort. Text display tree etc). It works.
And if you save it to 2009 and add the "include Data Type" it fails. A default setting has changed maybe?.

Ok, so removing the include datatype fixes the issue. And adding back the strict typedef setting has no effect. So my bug is the 'include datatype' problem. FWIW, the original with all the data types included and the strict type defs still works in 2009SP1 (this has been in my code since 8.2 and always worked until upgrading to LV2010)

Here is the LV2009SP1 version where the datatypes are included and the typedefs are strict and it generates no errors.
 Variant to Data bug 2009.zip   31.24K   110 downloads


But NI did find a bug with the strict type defs. Here is the example from NI support where they demonstrate the strict typedef bug using simple datatypes:
 7299252 Variant to Data bug.zip   33.11K   124 downloads


I might get two CARs out of this one. Nice...

[ShaunR]

Ok, so removing the include datatype fixes the issue. And adding back the strict typedef setting has no effect. So my bug is the 'include datatype' problem. FWIW, the original with all the data types included and the strict type defs still works in 2009SP1 (this has been in my code since 8.2 and always worked until upgrading to LV2010)

Here is the LV2009SP1 version where the datatypes are included and the typedefs are strict and it generates no errors.
 Variant to Data bug 2009.zip   31.24K   110 downloads


But NI did find a bug with the strict type defs. Here is the example from NI support where they demonstrate the strict typedef bug using simple datatypes:
 7299252 Variant to Data bug.zip   33.11K   124 downloads


I might get two CARs out of this one. Nice...

Your example of the 2009 also fails on my 2009 SP1 (error 91). But if I remove the strict type it works again. I can switch backwards and forwards between it working and not working, so I'm not sure what you mean by "adding back the strict typedef setting has no effect"

Hmmm. 2 cars? I didn't even get a rep-point

Edited by ShaunR, 28 September 2010 - 09:50 PM.

[John Lokanis]

Your example of the 2009 also fails on my 2009 SP1 (error 91). But if I remove the strict type it works again.

All I can do is show you this. Note the run continuously and that the include data type red stars are present and the version of LV is now displayed. Must be something wrong with your version of LV2009SP1 or mine. Can anyone else confirm this?

[ShaunR]

Nope you are right (only 1/2 a rep point then ) When I launched your example (dbl clicked) it switched to 2010 instead of my usual 2009. Making sure 2009 was open when I dbl clicked made sure I was using 2009, and it worked ok without moding.

Edited by ShaunR, 28 September 2010 - 09:58 PM.

[John Lokanis]

Nope you are right (only 1/2 a rep point then ) When I launched your example (dbl clicked) it switched to 2010 instead of my usual 2009.

Doh!

Well, in the end it turns out the bug is only associated with the 'Include Data Type' setting on control references. It has nothing to do with 'Strict Type Defs' afterall. Just confirmed that with the app support people. And the CAR# is 251234 for future reference.


Hope this one does not bite anyone else. Luckily, I was able to find a workaround.


Next time I will write my app in OOP and try to avoid these issues of getting data via VI Server methods. (this app was written a while ago when LVOOP was just a twinkle in AQ's eye...)

[ShaunR]

Next time I will write my app in OOP and try to avoid these issues of getting data via VI Server methods.

And replace 1 small insignificant bug with 20 whopping huge ones

[John Lokanis]

And replace 1 small insignificant bug with 20 whopping huge ones

Yes, well I'm not satisfied unless I get at least one CAR issued a week. I think OOP will help me out there! (And I am going to be taking the LVOOP class soon so I look forward to putting it to use)