LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Abrupt compile error=6 on running cRIO program

Solved!
Go to solution

Hi, all,

 

We have an array of lab instruments that are each managed by a LabVIEW 2014-1 app running on a cRIO 9067. The app includes our own custom LabVIEW-coded FPGA.

 

The current version of the app has been running on cRIO #4 for several weeks -- not rebooted, not re-downloaded, just running continuously.  Today the cRIO app crashed at about 1:30 PM, leaving 303 very similar messages in /var/local/natinst/log/*cur.txt, like this one:

 

VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_FTP.lvlib:FTP [ACCT].vi"

this->flags=50340352, compilerError=6

VI_BROKEN (0): [VI "NI_FTP.lvlib:FTP [ACCT].vi" (hex code)

 

this->flags appears to have one of two values: 50340352 or 33563136.

 

Each message mentions a different VI.  Some of them are ours, and some are from system libraries.

 

Unix on the cRIO is still alive. Using "top" on the cRIO's unix command line, I can tell that the LabVIEW runtime is still operating, but it's using no CPU time.  I presume all the loops with the broken VIs have exited, leaving only the most trivial to survive.

 

Rebooting the cRIO did not resolve the issue.

 

Re-deploying our software onto the cRIO also did not resolve the issue.

 

I suppose someone's going to suggest I reload the NI environment onto the cRIO, and I'll try that next.

 

Can someone point me to an explanation of what the cRIO environment does to my app when it starts up?  Why does it emit a compile error, when I compiled it on my pc weeks ago? Is it binding my code with the onboard libraries?  

 

And, what would cause the app to die suddenly after several days of smooth operation, with these errors? Is it somehow recompiling or relinking the app on the fly?  Should I worry about a corrupted hard drive on the unit?

 

Any other advice will be heartily welcomed.

 

Thanks,

-- Mark

0 Kudos
Message 1 of 3
(164 Views)

Update: I have used MAX to reload the NI software onto the cRIO, and then a deployed a fresh copy of our app.  The problem remains.

 

Could a hardware problem in the cRIO or one of the modules be causing this?

 

Is there software on the unit other than what is installed by MAX that might be corrupted?

 

What do I do next?

 

Thanks in advance,

-- Mark

0 Kudos
Message 2 of 3
(89 Views)
Solution
Accepted by topic author MarkBowles

Turns out this was a secondary manifestation of the app running out of memory. Buried in the error=6 messages was an error 2 complaint.

 

 

0 Kudos
Message 3 of 3
(52 Views)