I have been getting more than my fair share of grey hairs the past few days because of this. Over the past few months this almost never happened. Lately, after a seemingly minor change to some serial communications code, hardly a single build works without throwing errors like this: #OSVers: 6.3#OSBuild: Jun 6 2014, 09:14:16#AppName: /c/ni-rt/system/lvrt.out#Version: 14.0#AppKind: AppLib#AppModDate: InitExecSystem() call to GetCurrProcessNumProcessors() reports: 1 processorsInitExecSystem() call to GetNumProcessors() reports: 1 processorsInitExecSystem() will use: 1 processorsstarting LabVIEW Execution System 306708506 Thread 0 , capacity: 1 at [3507679466.00933790, (19:24:26.009337710 2015:02:24)]starting LabVIEW Execution System 306708507 Thread 0 , capacity: 1 at [3507679470.59560204, (19:24:30.595601929 2015:02:24)]starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3507679481.25993776, (19:24:41.259937648 2015:02:24)]starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3507679481.25993776, (19:24:41.259937648 2015:02:24)]starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3507679481.25993776, (19:24:41.259937648 2015:02:24)]starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3507679481.25993776, (19:24:41.259937648 2015:02:24)]Thread consumption suspected: 3 Try starting 4 threadsstarting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3507679515.59324312, (19:25:15.593243004 2015:02:24)]starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3507679515.59324312, (19:25:15.593243004 2015:02:24)]starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3507679515.59324312, (19:25:15.593243004 2015:02:24)]starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3507679515.59324312, (19:25:15.593243004 2015:02:24)]Thread consumption suspected: 8 Try starting 1 threadsstarting LabVIEW Execution System 2 Thread 8 , capacity: 24 at [3507679515.73854351, (19:25:15.738543576 2015:02:24)] and #####Date: TUE, FEB 24, 2015 04:47:22 PM#OSName: VxWorks#OSVers: 6.3#OSBuild: Jun 6 2014, 09:14:16#AppName: /c/ni-rt/system/lvrt.out#Version: 14.0#AppKind: AppLib#AppModDate: InitExecSystem() call to GetCurrProcessNumProcessors() reports: 1 processorsInitExecSystem() call to GetNumProcessors() reports: 1 processorsInitExecSystem() will use: 1 processorsstarting LabVIEW Execution System 306708506 Thread 0 , capacity: 1 at [3507670087.84041262, (16:48:07.840412710 2015:02:24)]starting LabVIEW Execution System 306708507 Thread 0 , capacity: 1 at [3507670092.45153570, (16:48:12.451535843 2015:02:24)]starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3507670103.11840487, (16:48:23.118404925 2015:02:24)]starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3507670103.11840487, (16:48:23.118404925 2015:02:24)]starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3507670103.11840487, (16:48:23.118404925 2015:02:24)]starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3507670103.11840487, (16:48:23.118404925 2015:02:24)]VI_BROKEN (0): [VI "NC serial comms protocol.lvlib:Set Lower Temperature Limit.vi" (0x04667310)]VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NC serial comms protocol.lvlib:Set Lower Temperature Limit.vi" (0x04667310)]this->flags=33563136, compilerError=6VI_BROKEN (0): [VI "Heater Control HAL.lvclass:Write Heater Control Active.vi" (0x058c4e98)]VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Heater Control HAL.lvclass:Write Heater Control Active.vi" (0x058c4e98)]this->flags=50340352, compilerError=6VI_BROKEN (0): [VI "NI_LVConfig.lvlib:Save Config File.vi" (0x047b7e90)]VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_LVConfig.lvlib:Save Config File.vi" (0x047b7e90)]this->flags=33563136, compilerError=6 and so on. This is using a cRIO 9074 running CompactRIO recommended software set 14.0.1 . These errors happen right at startup. Memory use is steady in interactive mode, about 20 MB contiguous memory is unallocated out of 128 MB. I have taken pains to prevent allocation and follow cRIO besta practices non concatenated strings array building in loops etc). CPU is 50-60% when running interactive mode. Really at my whit's end here, I have tried the various combination of enabling / disabling debugging in the RTEXE, disconnecting typedefs etc. I have not noticed a pattern. Regards, MarkCG

Real-Time Measurement and Control

According to NI the ethernet interrupt on FPGA loading is an expected behaviour.

The broken VI happens only on an application re-deployment to the RIO. The existing VIs are overwritten and this is logged in RIO error logs.

Message 11 of 11

(1,819 Views)

What do you need our team of experts to assist you with?

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?