UDP Reader

[altenbach]

Here's a version that works correctly for odd number of characters.

It also output a hex formatted string, replacing that clumsy text.text property. If you want ot grouped with spaces, add a bit more code.

I assume the possible values for "bit index" is 0..15. Correct? Do you have documentation for the instrument output?

[Zuc_lab2]

You're right octets sorry for the error in typing

[Zuc_lab2]

The messages can change i have a UUT that generates different messages that are still in construction.

You're right bit indesx is from 0 to 15

[Zuc_lab2]

The messages can change i have a UUT that generates different messages that are still in construction.

You're right bit indesx is from 0 to 15.

Best Regards,

Zuc

[GerdW]

Hi Zuc,

---

@Zuc_lab2 wrote:

So how i can modify the input so that the user can both insert a string (so a word) and a Hex payload (always in the format of "45AA 7712 61")?

---

Simple suggestion: Show the "display mode" indicator for your string input: now the user can change to the desired mode. (This may result in "more user teaching" and "more support requests"…)

The questions are:

• Why does the user has to input that string when you want to read it from an external device (using UDP messages)?
• Why don't you ALWAYS handle that UDP message payload as byte array?
• Why don't you show the message payload twice, as byte array AND as (human readable) string? (Like any common hex editor does?)

Generic comment:

In LabVIEW a string is just an array of U8. The chars get their "context" from a common ASCII definition, maybe mixed with OS (Windows) codepage handling for the upper 128 chars/bytes.

The difference between your two "string" examples isn't very helpful, because BOTH examples show plain ASCII chars!

[Zuc_lab2]

You're right, sorry but i was working on different application with common parts and i have made a mix. I have corrected the post!

Thank you for the patience!

Best regards,

Zuc

[GerdW]

Hi Zuc,

---

@Zuc_lab2 wrote:

… i have made a mix. I have corrected the post!

---

No, you deleted most text from your message and so removed a lot of context of my answer to that deleted text…

[altenbach]

---

@Zuc_lab2 wrote:

You're right octets sorry for the error in typing

---

An octet is eight bits. You use the term for 16bit words, which is confusing independent of spelling. 

[Zuc_lab2]

altenbach you're right sorry for my confusion and thank you for the patience!

Two doubts:

1. i don't get why using the logical shift. if i have an array and i need an element why don't using directly the index?

2. I don't understand completely this sequence of operation. 

best Regards,

Zuc

[altenbach]

---

@Zuc_lab2 wrote:

altenbach you're right sorry for my confusion and thank you for the patience!

Two doubts:

1. i don't get why using the logical shift. if i have an array and i need an element why don't using directly the index?

2. I don't understand completely this sequence of operation. 

best Regards,

Zuc

---

Each element of the array has eight bits, not one.

The logical shift is done on a U16 integer (Joined two U8 to get a U16, i.e. 16 bits), not on an array If you take the number 1 and do a logical shift, the 1 moves correspondingly, so you always end up with a value that has exactly one bit in the designated spot. Doing an AND with the number to be tested will result in zero if the bit is not set, and nonzero otherwise. The sign function turns it into 0 or 1 to be compared.

Boolean operations on integers are done bitwise. For example if we have the number (in binary) of 11001101 and we AND with 10000000 we get a nonzero value because the highest bit was set. If we AND with 00100000, we get zero.