Sending a packet structure

[Diaspora]

Dear Experts,

I am being told I need to send a packet structure and receive it along with the data already being passed. Kindly pardon me as I am unable comprehend what it is and how it can be accomplished. I have roughly developed a packet structure based on below information 

Could anyone be kind enough to assist me on how this can be accomplished? Herewith, I attach the vi here. Your kind help will be greatly appreciated.  Thank you.

[Mark_Yedinak]

Your clusters will not work for the protocol as specified. The packet is actually 6 bytes long and each byte is a I8. I have created a cluster definition that will work for you.

[BertMcMahan]

I can't open your VI in 2018 (use File -> Save for Previous and go back to 2016 or so to get more help), but I can make a guess.

Making this packet should be super easy- just take each element (make sure they're I8 values) and use Build Array to make them into an I8 array, then use Flatten Into String to cast it into a string, which you can then connect to the Send UDP function.

You can also type cast them to a String using "Type Cast".

[Mark_Yedinak]

Strange, I thought I saved it for 2016. Anyway, no I created a cluster with six elements. Each element is a I8. You can use flatten/unflatten from string when sendingreceiving the data. The nice thing about the cluster definition over an array is that your fields are named. With an array, you have to manage how you index the array in the code to get to your desired elements. It is much easier to maintain a simple cluster typedef rather than indexing an array through the code. In addition, the code is more readable and if need be your packet content can contain data of different types. Hard to do that with a simple array.

[BertMcMahan]

Mark, your reply went in while I was typing mine- I was talking to the OP. His code is in 2019 and wouldn't open in 2018. Your code opens just fine for me. I actually didn't realize a cluster would flatten that way- I hadn't tried it before and assumed it might include field names or some other metadata in the flattened version. Good to know it works like that... I never would have thought to try it 🙂

Also I would recommend using Flatten to String over Type Cast as it lets you specify endianness. Depending on the system it might not matter, but I know LabVIEW stores things a little differently from other platforms (sometimes) so having the option helps, especially if you're going between LabVIEW and non-LabVIEW applications.

[Mark_Yedinak]

---

@BertMcMahan wrote:

Mark, your reply went in while I was typing mine- I was talking to the OP. His code is in 2019 and wouldn't open in 2018. Your code opens just fine for me. I actually didn't realize a cluster would flatten that way- I hadn't tried it before and assumed it might include field names or some other metadata in the flattened version. Good to know it works like that... I never would have thought to try it 🙂

Also I would recommend using Flatten to String over Type Cast as it lets you specify endianness. Depending on the system it might not matter, but I know LabVIEW stores things a little differently from other platforms (sometimes) so having the option helps, especially if you're going between LabVIEW and non-LabVIEW applications.

---

One thing to know about flattening clusters is that if you have a string or an array, the flattening includes a 4 byte length before the actual string or array. If other languages need to use this data, you simply need to include the length fields in your definition of the structure for them. I have successfully passed data between LabVIEW and other languages using this method.

[BertMcMahan]

And note that Flatten To String *ignores* the "prepend array or string size" if it's inside a cluster. If it's just operating on a string, it will respect it, but not within the cluster itself.

[billko]

Doesn't "Flatten to String" have the option not to include the size when flattening?  Anyway, a cluster is better also because it strictly defines how big the message is.  There's no way to send the wrong amount of bytes.

Edit: Oh, I was assuming that you were using the "Flatten to String" to send it as a message over a network or something.

[BertMcMahan]

---

@billko wrote:

Doesn't "Flatten to String" have the option not to include the size when flattening?  Anyway, a cluster is better also because it strictly defines how big the message is.  There's no way to send the wrong amount of bytes.

Edit: Oh, I was assuming that you were using the "Flatten to String" to send it as a message over a network or something.

---

Yes, FtS has an option to include the size of a string or array when flattening, BUT if the string or array is inside of a cluster, it will ignore this and will always include the size.

[billko]

---

@BertMcMahan wrote:

---

@billko wrote:

Doesn't "Flatten to String" have the option not to include the size when flattening?  Anyway, a cluster is better also because it strictly defines how big the message is.  There's no way to send the wrong amount of bytes.

Edit: Oh, I was assuming that you were using the "Flatten to String" to send it as a message over a network or something.

---

Yes, FtS has an option to include the size of a string or array when flattening, BUT if the string or array is inside of a cluster, it will ignore this and will always include the size.

---

This is a packet is being sent somewhere.  The cluster shouldn't be flattened; right before it is to be sent, it should be unbundled, and all values converted into an array of U8 and be sent in order.  (It's highly unlikely that the recipient of the message will be expecting a LabVIEW datatype.)  That's why it never occurred to me that the option would be ignored.