11-30-2015 06:36 PM - edited 11-30-2015 06:38 PM
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
11-30-2015 09:52 PM
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 .
12-01-2015 11:19 AM
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?
12-01-2015 08:28 PM
Thanks! I can send you the whole project. Where to?
12-02-2015 12:47 PM
I sent further instructions over private message.
05-09-2016 03:34 PM - edited 05-09-2016 03:37 PM
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
05-12-2016 09:48 PM
it's a LabVIEW bug. Don't use User IOVs in absolute reference mode, change all of them to relative reference mode.
05-13-2016 11:31 AM
Target-Relative reference mode is doing the trick!
Thank you very much.
05-04-2020 06:24 PM - edited 05-04-2020 06:25 PM
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
05-06-2020 12:16 PM
four years later and still not fixed, dang