LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV_ESys2 stack trace error

I have a VI running on a cRIO-9063. When I debug the labview code running on the device, I will occasionally get alert saying that the device has stopped responding. I usually have to stop debugging and then restart debugging. This hasn't been so much of an issue in the past, more of a minor annoyance. 

 

However, I noticed today that the VI running on the device stopped sending data to a remote server that is collecting messages that is sent to it. The message that has stopped being sent contains a milliamp reading from an installed card in the chassis. When looking at the remote server's logs, I see that the cRIO is still sending messages asking for the current time (we use this as a pseudo heartbeat). 

 

So from my point of view, the VI is still running because it is requesting the time from the server, but the VI is no longer collecting measurements. In NI MAX I checked the error log for the device and found an entry with no end date with the following:

 

******************** LabVIEW Error Log ******************
####
#Date: Tue, Mar 20, 2018 10:53:08 AM
#OSName: Linux
#OSVers: 3.14.40-rt37-ni-3.0.0f2
#OSBuild: 200232
#AppName: lvrt
#Version: 15.0
#AppKind: AppLib
#AppModDate: 


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 2 processors
InitExecSystem() call to GetNumProcessors()            reports: 2 processors
InitExecSystem()                                      will use: 2 processors
starting LV_ESys2_Thr0 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
starting LV_ESys2_Thr1 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
starting LV_ESys2_Thr2 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
starting LV_ESys2_Thr3 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
starting LV_ESys2_Thr4 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
starting LV_ESys2_Thr5 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
starting LV_ESys2_Thr6 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
starting LV_ESys2_Thr7 , capacity: 24 at [3604387999.24697304, (10:53:19.246973000 2018:03:20)]
******************** RTLog ******************************

******************** Exception Log **********************

******************** ni-rt.ini **************************

There were also multiple other log entries that have a similar stack trace of the starting LV_ESys2_Thr# functions.

 

What could be the issue of this?

0 Kudos
Message 1 of 4
(2,274 Views)

There is nothing unusual in that error log. The messages you are referring to a normal log entries (the log also contains debugging information) regarding the startup of LabVIEW's execution system environment.

 

This means that your issue is probably un-related to the RT OS or the RT run-time itself and more likely an issue in your application. You haven't posted any details yet but things I would look at:

  • Are you dedicating CPU0 to any loops (Timed or otherwise)? Could that loop be hogging the CPU? In order for the debugging feature to work the UI thread (along with other RT background tasks unrelated to your app) must be able to run (ie. not starved). The UI thread runs at Normal priority so any higher priority tasks will pre-empt this from running; that includes Timed Loops.
  • What is your typical CPU usage prior to this occurring? This could give hints as to how stretched your CPUs are.
  • Assuming you are exposing the system shared variables from the software install set - do you lose connectivity? Eg. via NI DSM.

 

If you haven't already its also worth reading this: http://www.ni.com/compactriodevguide/

0 Kudos
Message 2 of 4
(2,266 Views)

Looking at NI MAX, I see the CPU stats for the cRIO unit as follows:

 

CPU Total Load         87% | 84%

CPU Interrupt Load     5% | 2%

 

This seems fairly high. This is a simple VI that is taking a reading from 1 input every few seconds and sends it along to a server. Could that high CPU load cause a complete lack of any new measurement messages being sent to my server? I would think if anything it would just delay new messages from being sent.

 

I looked at another device that is running a similar VI with many more inputs we have and the CPU stats for that are as follows which seem more reasonable.

 

CPU Total Load         14% | 10%

CPU Interrupt Load    7%  |  8%

0 Kudos
Message 3 of 4
(2,246 Views)

Don't forget that the CPU has other tasks besides your application (like kernel-related tasks such as processing interrupts) that also take CPU time. Generally anything over 80% load is a concern - this can mean that the determinism of your tasks could be impacted and could also mean that some of your tasks may get starved (which means they never get to execute).

 

Your CPU usage is showing there's a problem with your application. Perhaps you post your zipped project and/or the simple VI so that we can better see what the problem could be.

0 Kudos
Message 4 of 4
(2,241 Views)