LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP broadcast causes CompactRIO lose communication with host

I am running LV8.20 (RT) on a cRIO-9012 and an XP SP2 laptop host.

 

I have a sensor sending data over Ethernet via UDP protocol (72-byte packets at 100Hz, or one packet every 10ms).  An Ethernet switch (100Mbps)links CompactRIO, the sensor, and the host PC.

 

My problem is this:  sometimes I get the error message “Waiting for RT Engine to respond”, often followed shortly by the notice that communication with cRIO has been lost.  I use this same (UDP) arrangement in a number of programs, and I have not been able to tie the error message for sure to any particular event.  (Each program has periods of success but occasional failure.)

 

One particular program collects the sensor data, then performs some post-processing operations on it.  This program always runs fine for short collection periods (i.e., a small amount of data to process).  But when allowed to run longer, connection is lost after data collection stops but during the post-processing time.  The program always continues to run to completion on the cRIO, it just loses connection with the host.  Then I am unable to reconnect to cRIO without rebooting it.

 

Can anyone say whether what I am trying is possible, or is it doomed to failure due to data collisions or something else?  What might I try as a remedy?  As for data collisions, I don't care if I lose a few UDP packets here and there.

 

I have pursued this method to receive sensor data because the UDP was much faster than the serial communication option, and thus lower latency.  Initial trials showed UDP was more reliable than serial, as well.

 

My application is a control system which counts on real-time, deterministic calculations based on the input from this one sensor.  Periodic inputs are required of the operator through the host, and a handful of indicators on the host front panel help the operator keep track of what the program is doing.

0 Kudos
Message 1 of 2
(3,546 Views)
Hi David,

From your description is sounds like you might be starving out the TCP/IP stack.  You can monitor your CPU usage by using the Real Time System Manager found by going to Tools >> Real-Time >> Real Time System manager.  If your able to post code that easily reproduces the problem everyone will be able to help much faster too.

Looking to help,

Steve
Message 2 of 2
(3,544 Views)