Real-Time Measurement and Control

cancel
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 "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?

 

 

0 Kudos
Message 1 of 13
(6,261 Views)

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
(6,252 Views)

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?

 

 

 

 

 

 

 

Tim A.
0 Kudos
Message 3 of 13
(6,236 Views)

Hi Tim,

 

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

 

Regards,

Mark Garnett

0 Kudos
Message 4 of 13
(6,229 Views)

Hey Mark, 

 

I sent further instructions over private message. 

Tim A.
0 Kudos
Message 5 of 13
(6,209 Views)

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).

 

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
(5,575 Views)

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
(5,545 Views)

Target-Relative reference mode is doing the trick!

 

Thank you very much.

0 Kudos
Message 8 of 13
(5,527 Views)

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
(3,131 Views)

four years later and still not fixed, dang

0 Kudos
Message 10 of 13
(3,115 Views)