LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

Real Time Start Up.exe Stops Responding

Dear All,

I am Using NI-9075, Labview 2011

We have deployed StartupRT.exe into controller.

Some time , randomly my RT Exe Stops responding and in such case my complete machine operation and Data aquisition gets freezes.

When such things happen, Then if i trys to connect CRIO from Project.

The Deployment Progess stops at

Initializing...

Calculating dependencies...

Checking items for conflicts. This operation could take a while...

Waiting for Real-Time target (NI-cRIO9075) to respond

Refer Attached Screen Shot.

What is this Condition Called?

In such case i am not able to find where problem is.?

Ones, Controller is Reset then every thing  Works normally.

Thanks

Patel

CLAD
Labiew programmer
0 Kudos
Message 1 of 4
(4,166 Views)

Hi Patel,

It sounds like your network stack is becoming unresponsive, there are a couple of possible causes:

1. Running out of file handles. In VxWorks everything is a file handle, obviously file references but also network connections. If you have a reference leak in your code this could cause you to use all of the available file handles (I believe 64k from memory) and then new network connections can't be made.

2. You have a high priority loop that is running too fast. The RTOS will prioritise this over all other operations, including the network stack. Why this kicks in depends on the software. It could be an error conditions causes it to run faster or a memory leak can lead to higher CPU as it becomes harder to find space to allocate software.

I would suggest a couple of steps:

  1. Watch the CPU and Memory usage in Distributed System Manager. If they trend up there is a memory leak in your software that leads to this failure.
  2. Connect to the output console of the cRIO. With the 9075 you will need to set console out in MAX and then connect a cross over serial cable. This will show you if there are system errors occuring.
  3. Ensure there is error handling throughout your software such that any errors are saved to logs so you can review them afterwards.
  4. Check any timed loops for situations that may cause them to use more CPU such as error paths that cause a lot of processing or dynamic memory allocations.

This should allow you to start narrowing down some likely suspects.

Cheers,

James

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
Message 2 of 4
(3,070 Views)

Dear James

Thanks you for valuable answer.

I have checked CPU Usage from  Distributed System Manager.

All right  CPU Usage Was Very High. It was above 87-91 %

I changed my Loops timing and Now It is around 31-34 %

I am trying to get more closer to 15-20 %.

Are The Following Parameter is OK.

Thanks

Regards

Patel

CLAD
Labiew programmer
0 Kudos
Message 3 of 4
(3,070 Views)

Hi,

Normally I would recommend keeping them below 80% in normal running (so there is room for the occasional spike) so that sounds OK. The other question is just to make sure they don't trend upwards over time, this is a sign of a more significant issue.

Cheers,
James

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 4 of 4
(3,070 Views)