LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help parsing UDP Packet

Solved!
Go to solution

Hello, I am new to Labview and am working on a program to read UDP packets. I have been looking at the UDP Receive example from Labview and also reading older posts.The data consists of 1-Header word (32-bits), 24-data words (each word is 32-bits), and the rest of the data is filler data which is all ones. Every packet is the same size.  So far by using the UDP Receiver.vi example I am able to receive the data and could probably push on with what I have but I would like to know if there is an easier way to parse a UDP data packet? I've read others that used a Cluster and the TypeCast but can't seem to get it to work. When I try to connect my Cluster up to the TypeCast it the wire goes to dotted line.

 

If anyone has some suggestions on easier ways to parse a UPD packet please let me know.

 

Thanks,

joe

0 Kudos
Message 1 of 15
(6,197 Views)

Can you show us what you've tried, using Type Cast? The cluster to which you are typecasting cannot contain strings, arrays, or any other variable-length data type. You should create a cluster containing 25 32-bit values (to save some time, create an array of 32-bit values, insert "Array to Cluster", and set the cluster size to 25, then create a constant or control from that, after which you can delete the array and "array to cluster"). Typecast to that cluster. You may need to use Unflatten from String instead of Type Cast, if the endianness is wrong. You can safely ignore the filler. You still need to read it, but when you do the type cast it will ignore any data past the end of the target data type.

 

Why does your current VI have a lot of unnecessary controls? Why are you initializing a bunch of unused arrays? The reason your UDP_PACKET cluster doesn't work for Type Cast is because all the elements are arrays where they should be scalars (single values).

0 Kudos
Message 2 of 15
(6,177 Views)

As mentioned there are limitations to what type cast can do, and it relates to how labview stores data in memory.

 

My personal way of handling this situation is to convert the string into an array of U8s ("string to byte array") and then manually fiddle with the data -- but there are easier ways. I've attached an example VI which shows you a few ways of handling the data. Basically, use a combination of type cast and array manipulation functions to get the data to the size/type you need.

 

One thing that can be handy is "unflatten from string" because (a)it will return excess data (this is shown in the example -- I yank the header off the front of the string, and it returns the rest to me for further processing) and (b) it has the option of specifying a byte order. If your data is coming from pretty much any text-based language, there is a chance it is in a different byte order than what LabVIEW is using. Rather than having to manually switch the order ("split number" and "join numbers" functions), unflatten can sometimes help you out for free.

0 Kudos
Message 3 of 15
(6,164 Views)

Hello, thanks for responding to my post. Yesterday I got something working and I'm going to attach it to this post. joe

Download All
0 Kudos
Message 4 of 15
(6,139 Views)

Hello, thanks for respoding to my post. I am unable to load your example into my copy of Labview which is version 2012. Could you instead attach some screen shots. Thanks, joe

0 Kudos
Message 5 of 15
(6,134 Views)

Oops! I left out one file. I'll attachem them again. Sorry.

Download All
0 Kudos
Message 6 of 15
(6,127 Views)

I'm sorry to say it, but this is definitely a candidate for the Rube-Goldberg code thread. You get a string containing binary data, which you convert to an array of bytes. You turn each byte into a string containing 6 zeros followed by the hex representation of that byte. Then you extract just the last two letters to get back to the hex representation of a single byte, concatenate 4 such strings together to get 4 bytes, and convert that string back to a 4-byte value. Or at least I think that's what's happening, although the "UDP_Cluster - Copy" VI is missing and the UDP_Cluster VI you provided isn't the same.

 

On top of that, you have a 24-frame stacked sequence structure putting values into local variables, and in parallel you bundle all the local variables into a cluster. You have no idea of the order of execution - it may bundle some of the local variables before the sequence structure updates them - so the data in the cluster could be a mix of data, some from the previous packet and some from the current one.

 

I highly recomend starting over. Did you even try what I suggested - creating a cluster that matches the actual format, and typecasting to it? It will be much, much, cleaner and simpler. There should be no local variables and no sequence structures, stacked or otherwise, in your code. You can possibly use the UDP_DATA structure you already have as the data type for the Type Cast (or unflatten from string).

0 Kudos
Message 7 of 15
(6,116 Views)

You are correct. I will try your recommendations. Thanks, joe

0 Kudos
Message 8 of 15
(6,104 Views)

I've fixed the missing files and attached them again. It's not the right way to do things, but it was a start. I'll start over.

Download All
0 Kudos
Message 9 of 15
(6,102 Views)

Hello all. Well I finally got it to work. It's not perfect but I did get some exposure to TypeCasting and Clusters.  I appreciate all your comments and suggestions. Thank you very much.

0 Kudos
Message 10 of 15
(6,096 Views)