From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP Error 74 occured at Unflatten From String

Hello,

 

I am trying to run a simple example that recieves data using UDP from an external source.

 

When I run the example, I am able to correctly recieve the data, but after some time running the following error occurs.

 

cjegues_0-1597784027541.png

 

Any tips on how I can troubleshoot/resolve this error?

 

I've attached the VI files.

 

Thanks!

0 Kudos
Message 1 of 5
(1,212 Views)

The error isn't a UDP error.  It means that it tried to unflatten whatever data you received and it didn't believe it was an integer data type.  (I can't tell what tye because I don't have LV 2020 at work.)

 

Put a probe on the output and see if what you get would unflatten into an integer.  You're looking for the correct amount of bytes that correspond to that integer.  e.g., 2 bytes for a 16 bit integer.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 5
(1,193 Views)

Bill,

 

Thanks for the speedy reply.

 

I did some more testing before you had responded and previously I was sending the data to labview manually by clicking a button. As long as I kept clicking the button to send the data often enough, I noticed that error would not occur. However, if I waited longer and did not trigger the data to send, eventually the error would occur.

 

If instead of manually triggering the data to send using a button if I instead trigger the data to send peroidically, the error never occurs.

 

Does this give any hint as to what could be happening?

 

I will try to figure out the probe and see if I can get back to you. I am inexperienced in LabVIEW so I'll let you know how things go.

0 Kudos
Message 3 of 5
(1,179 Views)

To set up a probe, right-click on the wire you want to see the and you should get an option to create a probe.

 

Unfortunately, I can't see the code because it's in LV 2020 - BUT - I'm going to make some guesses, anyway.

 

There's some code somewhere where you click a button to send data.  If you don't click fast enough, the UDP read will time out, throwing an error (that you won't see yet).  This error causes the UDP read to return an empty string, which unflatten has no idea what to do with, so it throws the 74 error.  If you click the stop button, you probably also get a 56 UDP timeout error.  You won't be able to click the stop button because the error message will always get in the way.  Try putting a probe on the error wire right after the UDP read to see what you get when you get the error 74.

 

How did I do?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 4 of 5
(1,171 Views)

Bills analysis to what causes your problem is totally spot on. UDP Read has a timeout and will return with an according error after this timeout expired without any data to return.

 

You should make sure to only execute the Unflatten from String when de UDP Read did not return any error. Also you should wire the error output of the Unflaten from String too (or disable automatic error handling in the VI Settings, but that is not a good fix). The easiest way to do all this is to actually wire the error cluster also through your Unflatten from String node.

 

And there are several more things you will need to do for a reliable data transfer. The first one will be to make sure you never try to send more than 548 bytes in one go. UDP is an unreliable message oriented protocol. There is no guarantee that routers between the sender and receiver will transport the data at all (UDP traffic is usually discarded at router bounderies) and even if they do they are not obligated to send the datagram message in its entirety but can decide to simply clip it at their minimum Datagram MTU length which is specified to be 576 for the IP frame, which after subtraction of the IP and UDP header results in the above 548 byte. This is also the default input to UDP Read and UDP Read returns without timeout error only if it received one or more bytes up to the requested amount of bytes.

 

Creating reliable network communication code is not trivial and requires quite a bit of proper error handling and an understanding of the underlaying protocol intricacies.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 5
(1,112 Views)