Real-Time Measurement and Control

Showing results for 
Search instead for 
Did you mean: 

build process works, but RTEXE is broken (cRIO 9067)

oftentimes I get bad realtime executable  builds and it's a total crapshoot what build will be good and what won't. The error log shows many errors of the following form. It seems to be linked to classes and shared variables.



InitExecSystem() call to GetCurrProcessNumProcessors() reports: 2 processors
InitExecSystem() call to GetNumProcessors()            reports: 2 processors
InitExecSystem()                                      will use: 2 processors
VI_BROKEN (1): [VI "" (0x00c6e1f8)]
VIToVariableLinkRefBase::NotifyReferOfChangedLinkCore: vi is [VI "" (0x00c6e1f8)]
refee's ident is [LinkIdentity "RT CompactRIO Target:User-Defined Variables:MyUserIOVariable" [ Main Application Instance]
updateStatus is 1


Any ideas?



0 Kudos
Message 1 of 13

I have been trying ot figure this one out and one thing that does seem to avoid a bad build is to clear compiled object cache, run your main RT VI in interactive mode on the target, stop it, and the build immediately without closing your main RT VI.


When LabVIEW gets into a "bad state" just clearing the cache won't do it. Opening the project from scratch and kicking off the build doesn't work either.


I am NOT separating source from compiled code, running a hybrid FPGA bitfile w/ user IO variables -- LVRT 14.01, cRIO 9067 .



0 Kudos
Message 2 of 13

Hey MarkCG, 



Can you provide your code, or a subset of your code, that reproduces the problem? I'm specifically interested in the VI that is loading broken, "" and its owning class, "MyClass". If you can't share your full project that reproduces, I would at least like to see how the the Class configurations and that contents of that VI. My goal is to reproduce the problem so that I can investigate it further. 


Out of curiosity does selecting the "Disconnect type definitions" option in the "Additional Exclusions" section have any affect on the build?








Tim A.
0 Kudos
Message 3 of 13

Hi Tim,


Thanks! I can send you the whole project. Where to?



Mark Garnett

0 Kudos
Message 4 of 13

Hey Mark, 


I sent further instructions over private message. 

Tim A.
0 Kudos
Message 5 of 13

Any updates on this?  My program also runs fine when running through LabView but fails when trying to run a real-time startup application

The error log has a slew of errors similar to


VI_BROKEN (1): [VI "Cals to" (0x003216d0)]
VIToVariableLinkRefBase::NotifyReferOfChangedLinkCore: vi is [VI "Cals to" (0x003216d0)]
refee's ident is [LinkIdentity "RT Single-Board RIO Target:User-Defined Variables:CE" [ Main Application Instance]
updateStatus is 1
VI_BROKEN (1): [VI "Cals to" (0x003216d0)]
VI_BROKEN (1): [VI "Cals to" (0x003216d0)]

CE, and the other variables showing up in these errors, are user-defined variables under my target (sbRIO 9637) chasis.  They are all "primitive" types (fixed-point and boolean).


User-Defined Variables.png


This particular VI is pulling values out of a global struct to write to the variables, but other instances that throw errors are just writing constants.


Cals to FPGA.png


This is LabView 2015 with an sbRIO-9637 running NI Linux Real-Time ARMv7-A 3.14.40-rt37-ni-3.0.0f2

0 Kudos
Message 6 of 13

it's a LabVIEW bug. Don't use User IOVs in absolute reference mode, change all of them to relative reference mode.



Message 7 of 13

Target-Relative reference mode is doing the trick!


Thank you very much.

0 Kudos
Message 8 of 13

came to this thread last week.

seems because I used same software on 2 different cRIOS 9even different models), so target relative got it sorted, I wish I had known earlier

I added Kudos

0 Kudos
Message 9 of 13

four years later and still not fixed, dang

0 Kudos
Message 10 of 13