RT does not run when deployed to 9642 sbRIO LV 2011

[Zach-H]

What is the file path that you're pulling that INI file from? 

The main INI file for our RT targets is the lv-rt.ini file on the c:/ drive of the cRIO. It should include multiple sections including: 

[SYSTEM SETTINGS]

[TCP_STACK_CONFIG]

[LVRT] 

etc. 

Is lv-rt.ini the file you posted or did you find another INI file? 

Do you have "disconnect type definitions" selected under the additional exclusions section of the build specification?

[MartinMeyer]

The file I posted is the nirio.ini file from the system directory.

I did not use the checkbox in the build specification.  I disconnected from the typedef in the variable definition.

[Zach-H]

Do you mean you the c:/ni-rt/system directory?

I'm unable to find any nirio.ini file there on the 9074 I have set up here.  

What software do you have installed on your cRIO-9074? I don't believe that file gets edited during the deployment process. 

I'm only familiar with the edits the deployment process makes to the lv-rt.ini file. 

[MartinMeyer]

Yes it is /ni-rt/system/nirio.ini. 

I just observed that it appearred to be corrupted.  I noted that it did not seem to fix the problem.  I assume it is used somewhere by NI.

It was resolved by disconnecting  typedefs.  I will try disconnecting in the build spec. 

I have attached a support file.

Thanks.

[Zach-H]

Perhaps the issue was simply related to the typedef linked to a specific shared variable. 

We haven't seen a case of the typedef issue since the release of 2012 Real-Time Module.

I apologize for asking, but are you certain that you're working with LabVIEW 2012, and not LabVIEW 2011 SP1, which was also released in 2012? 

The quickest way to tell  what version you're in is to click on help >> about LabVIEW.

[MartinMeyer]

Yes I am using LV2012, on all of the systems related to this issue.  The ni_support.zip file indicates that on the target. 

[Zach-H]

Again, I apologize, but I needed to verify. 

Did disconnecting type def's within the build specification alone solve the issue? (Allowing the executable to run with shared variables connected to a type def.)

This might be a good point for me to try and replicate the issue on my end.

If there is still trouble with shared variables linked to type defs we'd like to reproduce it and document it for R&D. 

It would be great if you could post your project with the type def's you're using. 

Thanks

Zach

[jaumemar]

Hello, I've found this problem too...

It was crazy, in the development enviroment it works but when I doploy it...

I was preparing my CLED doing sample exam and I loose more than an out investigating when I discover it... Imagine that it occurs in the real exam! Please, solve it or add a warning message when defining a typedef NSV in a realtime environment!

Well, in my case, I use LabVIEW 2013 SP1 and my NSV was an strict typedef enum with 4 elements (descriptions with spaces).

When I see this post, I change the build spec and select the "Disconnect Type definitions" options and then it works.

(the workaround description for this issue is not clear: 2.) Change the build spec so it doesn't disconnect type definitions) [DOES?]

Jaume

[ba_0101]

This issue still exists in LV 2013 SP1. It should be elevated to a critical issue and fixed immediately.

[Joel-I]

Hi all,

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

Regards,