03-20-2018 12:54 PM
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?
03-20-2018 01:28 PM - edited 03-20-2018 01:29 PM
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:
If you haven't already its also worth reading this: http://www.ni.com/compactriodevguide/
03-20-2018 02:35 PM - edited 03-20-2018 02:36 PM
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%
03-20-2018 02:52 PM
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.