what is the best way to parse TCP data packets?

[CoastalMaineBird]

 do I need to define the size (number of array elements) as a typedef (of U8 controls)

No.

Simply place an empty ARRAY constant, with U8 elements, on your diagram, and use that as the TYPE input to an UNFLATTEN function.

LV will figure out how many there are.

[CoastalMaineBird]

OR

Since it is U8, there is a shortcut - in the STRING palette, there is a STRING to BYTE ARRAY function which will do that for you.

The case I gave is more general.

[robojeff]

Thanks Steve-

After being distracted by other duties, I am finally getting back to this and finally have the VI parsing TCP packet data correctly.

What is the best way to display the contents of each element of this 1D array on the front panel and what is the best way to access

an individual element fo this array for further calculations?

Thanks again

[CoastalMaineBird]

What is the best way to display the contents of each element of this 1D array on the front panel and what is the best way to access

an individual element fo this array for further calculations?

Oh, now you're not even trying.

Use an array indicator.   Pop up on the output of the STRING to BYTE ARRAY and then CREATE INDICATOR from that.

[robojeff]

After digging in on this VI, there seems to be a lot of different sizes of data packets and cases depending on certain fields within the data packets.

I would like to simplify this and noticed that each TCP packet has a Wrapper which contains the overall length of the TCP data packet.

Couldn't I read the first word of the TCP packet to determine the overall packet length and then read it into a string where I can disect the data that i need instead of doing this with a bunch of different clusters and wouldn't this be easier?

Any thoughts on this from some of your experieinced Labview users would be most appreciated

thanks 

O

[CoastalMaineBird]

OK, the best time to find this out would have been a long time ago.

No reason to start writing code until you know what your target plan is.

In any case, yes, you read a LENGTH quantity and that determines how many MORE bytes to read.

It might or might not tell you what the payload means.

EXAMPLE (totally fictitious protocol):

03 05 00 40    (length: 3 OpCode: 5 = Left Exhaust Temp  40 = value (64 degrees))

03 06 00 42    (length: 3 OpCode: 6 = Right Exhaust Temp  42 = value (66 degrees))

02 08 01         (length: 2 OpCode: 7 = Status of Relay   1 = value (on))

05 09 01 23 45 67   (length: 5 OpCode = 9 = mSec since reset, 01234567 = value)

[robojeff]

Thanks Steve...

yes it would have been nice to know this but getting information on what I am interfacing with has been like wringing spit out of a rag...

Thanks for your guidance

[robojeff]

So I am attempting to adjust my string for the big endian data order configuration with the following but am getting the shown error.

 Is there a better way of doing this?

Thanks

[CoastalMaineBird]

If you need to deal with endian-ness, then why are you unflattening it as BYTEs?

Bytes have no "endianness".

You FIRST need to figure out what you need to receive.

[CoastalMaineBird]

Can you write down, in words, what is the meaning of the string: 

4200 0000 A3CF A100 0000 00

?

If you can't, you shouldn't be writing code yet - not until you nail that down.

If you can, then can you explain why the "Packet size" is 0x42 (d66), but your result string is only 11 bytes long?