Ethernet comm fails occasionally

[FrankHS]

I am using labview to communicate with an Ethernet IO rack. Occasionally, I briefly lose the Ethernet  connection to the IO rack, which shuts down the process I am controlling. If the rack does not receive a message over Ethernet every 100 mS, the watchdog on the rack shuts everything down.

There are only two nodes on the Ethernet cable, the IO rack and the computer running a labview program. I am using the following NI vi’s. UDP Open, UDP Close, UDP Write and UDP Read. The computer runs windows 10 and the labview version is 15. The program is a built exe and runs 24 /7.

At first I opened the port, writing, and reading data and then closing the port each iteration. This worked except that it would occasionally lose connection. It would run OK for days then there would be a shutdown.

 

I know there are things like windows update that attempt use the Ethernet port. Is there any way I can guarantee an uninterrupted connection?

Then I tried opening the port when the program starts, and keeping it open until the program shuts down. There is a bizarre undesirable behavior from time to time that I have yet to understand.

Do you have any ideas of what I can do to solve this problem?

[Jordan Kuehn]

Have you checked the Windows Event Log for any errors reported with the NIC during that time?

[Aniket Gadekar]

Hi FrankHS,

May be you can monitor error outputs of read & write UDP VI's & log error. You can monitor error & analyze.

[EricLarsen]

I had almost the exact issue a few years back.  I had a Windows computer that would send out a UDP packet every 100 ms to a Labview real-time PXI system.  If the PXI system didn't receive a UDP packet for 5 seconds it assumed the Windows machine has failed and would go into a fail safe mode.  The issue was that the Windows system was also doing some data processing, and every so often the data processing would cause the Windows box to freeze long enough interrupt the communication.  

The real issue is that neither Windows or Ethernet is really capable of maintaining a 100% reliable real-time communication link, especially at the relatively fast rate of 100 ms.  In my case I was able to reprogram the receiving hardware with more robustness and autonomy to deal with lost packets and dropped communication links.

Your first try should be to configure the I/O rack to be more robust about dropped packets if possible.  Then try to disable every unused process on the Windows box, and not just the processes that may try to access the Ethernet port, but everything in the background.

 

 

 

[Phillip Brooks]

I had a case years ago where I needed to create a solution that would receive three UDP streams over three distinct Ethernet wires on a single LabVIEW station at 100Hz.

I used queues to receive the data and used VI server to start three processing loops that read from each queue. It worked fine.

The second requirement was to optionally receive a single stream at 1200 Hz. There was no hardware at the time to send the data to my application. I struggled for a while, and finally used a NI-6509 DIO board in a second computer that was connected to a function generator. I used a timed loop that was triggered by an input to the 6509. I interpolated a 16 hour 100 Hz log to create a 1200 Hz data set. I used the function generator with a square wave to trigger a timed loop that sent the UDP data. My application logged the high-speed data with no data drops; the only thing I needed to do was increase the UDP receive buffer size on the application side.

You can definitely get there, but will need some timed hardware resources.