RT does not run when deployed to 9642 sbRIO LV 2011

[MartinMeyer]

One thing we learned as well, was that running a mass compile gives some extra info.  Doing a build and deploy did not report any issues.  We did a mass compile and found that a couple of files had insanities.  We had a corrupt VI, and a library with a "bad" variable.  We had to delete the variable and re-add it. 

Did I miss something during the build and deploy that would have clued me into insanities?  

We also did the typedef trick which worked on a couple of projects. 

[jaumemar]

"Our R&D team is aware of the issue and the corrective action report can be tracked with CAR# 294285"

How can I check a CAR status?

Jaume

[Joel-I]

Hi Jaume,

You can check to see if the CAR # is listed in the ID field for the Bug Fix documentation for LabVIEW.  For example, take a look at the bugs addressed in LabVIEW 2013:

https://www.ni.com/en/support/documentation/bugs/13/archived--labview-2013-bug-fixes.html

Regards,

[MorganRock]

I am having the exactly same problem in latest LV2013 version, and have spent a few days to figure out that the typedefs NSV is causing problem in my cRIO application.

This type of "hidden error" is really difficult to debug and frustrating.

Hope this can be fixed soon.

I will try "disconnect type defs" to see whether it works or not.

[Shane-C]

Post again if you can't get this working by disconnecting the type defs.  That will hopefully resolve the problem for you as well.

[MorganRock]

Shane,

Problem is sovled by checking "Disconnect Type Defination" before building the real-time application.

Thanks

Yan

[jaumemar]

What is the real and practical effect of this typedef disconnection?

If no undesired effects, why not check this option by default and avoid this potential problem related to the NSV?