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

[MarkCG]

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 "MyClass.lvclass:MyMethod.vi" (0x00c6e1f8)]
VIToVariableLinkRefBase::NotifyReferOfChangedLinkCore: vi is [VI "MyClass.lvclass:MyMethod.vi" (0x00c6e1f8)]
refee's ident is [LinkIdentity "RT CompactRIO Target:User-Defined Variables:MyUserIOVariable" [ Main Application Instance]
updateStatus is 1

Any ideas?

[MarkCG]

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 .

[timtamslam]

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, "MyMethod.vi" 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?

[MarkCG]

Hi Tim,

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

Regards,

Mark Garnett

[timtamslam]

Hey Mark, 

I sent further instructions over private message. 

[esci]

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 FPGA.vi" (0x003216d0)]
VIToVariableLinkRefBase::NotifyReferOfChangedLinkCore: vi is [VI "Cals to FPGA.vi" (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 FPGA.vi" (0x003216d0)]
NotifyVIOfChangedLink
VI_BROKEN (1): [VI "Cals to FPGA.vi" (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).

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.

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

[MarkCG]

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

[esci]

Target-Relative reference mode is doing the trick!

Thank you very much.

[Steffen01]

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

[MarkCG]

four years later and still not fixed, dang