UDP Send/Receive Delay

[Cy.Rybicki]

I have a LabVIEW 2015 application running on a Windows 7 PC which communicates with a battery cycler over UDP on one network card, as well as a secondary network card connected to a lab network. Normally this operates without issue, but intermittently either the UDP Write or UDP Read LabVIEW primative VI takes ~ 4 seconds to execute, despite a 200 ms timeout set, and reports no errors. This causes a problem because if the battery cycler does not receive a heartbeat command within 5 seconds it will timeout and disenage from the UUT.

I found a seemingly related post here, but the solution calls for setting the "Dot Notation" input of "IP to String" to TRUE. I am not using this VI, though I am using its inverse (String to IP) which does not have any additional inputs.

I've attached a code snippet of my send/receive VI which is experiencing the delay.

Thanks in advance.

[Jorr-El]

Is the delay consistently repeatable? Does it occur after the program has been running for a certain amount of time? Or does it happen after a reboot?

In the other forum post, they suggested removing all of the "IP to String" and "String to IP" functions and replacing them with numeric constants to see if those functions were contributing to the delay. Have you tried this workaround?

There is also a Simple UDP example project in LabVIEW. Have you tried running this example to check if the delay still occurs?

[Cy.Rybicki]

The delay is seemingly random in when it occurs, but I'll consistently see it at least every few hours. Sometimes it will be two or three times in a ten minute interval, sometimes I won't see it for an hour. I haven't been able to correlate it to any Windows events, CPU or network traffic spikes, etc. 

I am not using "IP to String", but I will try removing the "String to IP" function just in case. When I benchmarked the code, I was able to narrow it down to the "UDP Write" and "UDP Read" LabVIEW primitives as the cause of the delay, though it was always one or the other not both.

I have not used the Simple UDP example but I will likely try that next.

One more thing of note, I disabled the NIC which is connected to the lab network and let my app run overnight. I did not see any instances of the delay, so it seems to definitely have something to do with having two active NICs.

[Jorr-El]

I found some more documentation that might be helpful for dealing with multiple NICs. The first article talks about avoiding assigning multiple NICs in the same computer to the same subnet. This is apparently the number one cause of connectivity issues with multiple NIC systems.

The solution is to statically assign one NIC (and the other networked computers attached to that NIC) to the 192.168.x.x range with subnet mask 255.255.0.0, and another NIC on the 10.0.x.x range with subnet mask 255.255.0.0. Note that this is just one possible configuration, any combination of two or more different subnets will work. It is recommended that you use one of the designated private IP address ranges to avoid conflicts with public servers on the internet.

Best Practices for Using Multiple Network Interfaces (NICs) with NI Products:
http://www.ni.com/white-paper/12558/en/

Can I use multiple network cards with LabVIEW?

http://digital.ni.com/public.nsf/allkb/AE69890A3DB5329386256C4F006F7A5E

[Cy.Rybicki]

Thanks for the feedback, I had not found those articles when searching before.

The two NICs were originally at 192.168.66.X and 192.168.128.X with a 255.255.255.0 subnet mask. I changed the second NIC (which is directly connected to the battery cycler) to the 10.0.0.X range, but still experienced the occasional dropouts.

I had a coworker put together a .NET dll to handle UDP communication and am currently using it to communicate with the cycler. So far it seems to be much improved, no droupouts after several hours of testing. 

[Jorr-El]

Glad to hear you're having some success. Keep us updated on your progess, and let us know about any more errors if they show up.