How does the UDP Read VI handle corrupt packets?

[Bob_Shreve]

I am running LabVIEW 2014  Pharlap RT OS. I am using the UDP Read VI to receive messages from a unit under test. The messages contain 128 bytes of actual data. We have a managed switch between the UUT and the test system. The managed switch mirrors all messages to / from the UUT to another computer running Wireshark.

The test program has been running for several years, but in the past week we have seen two instances where a message from the UUT to the test system is in the Wireshark log, but the test system indicates it did not receive the message.

How does the UDP Read VI handle a packet with a bad checksum in the header? For instance if the waveform is distorted such that a bit is misinterpreted, will the VI still return the packet but flag an error?

Thanks,

Bob Shreve

[altenbach · Accepted solution]

UDP does not guarantee delivery and you should handle the possibility that not all messages arrive.

I would guess that the OS stack will discard corrupted messages and LabVIEW will never see one bit of them.

Now the question is of course why you suddenly get this after years of good performance. Maybe check the hardware (cabling, connectors, jacks, etc. try a different cable, etc.). My guess is that if these UUT are constantly swapped, the connecting hardware might wear out.

Does each message have a sequence number so you know if data is missing?

[Bob_Shreve]

The message in question is part of a command / response interchange with the UUT. The test set code clears a "message received" global variable, then sends the command to the UUT asking for data. The steps to clear variable and send the command are dataflow sequenced via the error cluster. When the response is received from the UUT, the receiver code sets the "message received" global. This exchange works correctly 10s of thousands of times over the course of testing a unit.

The wireshark program monitoring traffic between the UUT and the managed switch does see the response message about 400 uSec after the command message. The message seems to be getting lost between the managed switch back to the RT controller. These cables are within the test set rack. However, I will check the connections there.

When we are troubleshooting a failure of this type, we can re-send the command message from the test set and receive a response from the UUT which the test set does see and record.

Thanks for your help

[Mark_Yedinak]

---

@Bob_Shreve wrote:

The message in question is part of a command / response interchange with the UUT. The test set code clears a "message received" global variable, then sends the command to the UUT asking for data. The steps to clear variable and send the command are dataflow sequenced via the error cluster. When the response is received from the UUT, the receiver code sets the "message received" global. This exchange works correctly 10s of thousands of times over the course of testing a unit.

The wireshark program monitoring traffic between the UUT and the managed switch does see the response message about 400 uSec after the command message. The message seems to be getting lost between the managed switch back to the RT controller. These cables are within the test set rack. However, I will check the connections there.

When we are troubleshooting a failure of this type, we can re-send the command message from the test set and receive a response from the UUT which the test set does see and record.

Thanks for your help

---

Why are you using UDP if you have a command/response protocol? With a command/response protocol you generally want to guarantee delivery which TCP would do for you. However as mentioned, UDP is not reliable. By design it is essentially to be used for things where it is acceptable to lose data.

[Bob_Shreve]

The box we are testing is a customer design. They chose to use the UDP protocol since it fit the message exchange requirements (including handling dropped packets in either direction) for their overall system.

[Mark_Yedinak]

They may want to go back and review their requirements. UDP does not handle dropped packets. It can be handled higher up at the application layer but UDP by itself doesn't have any type of recovery for dropped/missing packets. If they really wanted/needed that they should have used TCP.