LabView serial communication issue

[MinHolly]

Hello,

I've encountered an issue with my LabVIEW code. I'm attempting to communicate with an external device that requires serial communication. To achieve this, I've been utilizing the write/read functions. The frame I need to send is as follows:

00x16 00x16 00x16 00x16 00x10 00xFF 00x22 00x00 00x00 00xA7 00x5F 00xF5

It's a 12-byte frame represented in hexadecimal. However, since the write/read function only accepts STR data, I convert it to STR and send the following:

1616161610FF220000A75FF5

Unfortunately, when attempting to communicate with my device, I'm not receiving any response. Additionally, LabVIEW indicates that 24 bytes have been sent, despite sending only 12. It seems that each digit of the hexa representation has been interpreted as a byte.

I'm unsure how to resolve this issue. Has anyone encountered a similar problem?

Thank you for your help.

[altenbach]

Please define all acronyms, for example what is "STR" in your context?

• What happens if you set your string to hex display before entering the values?
• What is the datatype of "00x16 00x16 00x16 00x16 00x10 ..." (formatted string? U8 array set to hex format? something else?) and why are there two 00 for each set?
• Why not show us you code to remove all the ambiguities?

[RTSLVU]

Most serial communication issues can be solved by watching this video: VIWeek 2020/Proper way to communicate over serial

[pincpanter]

---

@MinHolly  ha scritto:
...

It's a 12-byte frame represented in hexadecimal. However, since the write/read function only accepts STR data, I convert it to STR and send the following:

1616161610FF220000A75FF5

Unfortunately, when attempting to communicate with my device, I'm not receiving any response. Additionally, LabVIEW indicates that 24 bytes have been sent, despite sending only 12. It seems that each digit of the hexa representation has been interpreted as a byte.

---

You are probably sending the sequence "1616161610FF220000A75FF5" as a 24-characters ASCII string (that is, 24 bytes).

One way to prepare the frame is to build it as a U8 (unsigned byte) array, then typecast it to a string.

Please post your code so that we can help you more.

[JimB.]

---

@MinHolly wrote:

Hello,

I've encountered an issue with my LabVIEW code. I'm attempting to communicate with an external device that requires serial communication. To achieve this, I've been utilizing the write/read functions. The frame I need to send is as follows:

00x16 00x16 00x16 00x16 00x10 00xFF 00x22 00x00 00x00 00xA7 00x5F 00xF5

It's a 12-byte frame represented in hexadecimal. However, since the write/read function only accepts STR data, I convert it to STR and send the following:

1616161610FF220000A75FF5

Unfortunately, when attempting to communicate with my device, I'm not receiving any response. Additionally, LabVIEW indicates that 24 bytes have been sent, despite sending only 12. It seems that each digit of the hexa representation has been interpreted as a byte.

I'm unsure how to resolve this issue. Has anyone encountered a similar problem?

Thank you for your help.

---

This is a common cause for confusion with the serial functions.

It sounds like you need to send a sequence of bytes. You can do that using this function: https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/byte-array-to-string.html.

What you are probably doing is sending a ASCII encoded hex string rather than the actual hex values.

See attached.

[MinHolly]

Thank you very much for your help. I've made adjustments to my code accordingly. However, I still have a query. As I'm relatively new to LabVIEW, this might seem like a basic question: will this solution suffice given that my device anticipates hexadecimal representation? the hexadecimal representation here is only within LabVIEW, but the data sent to the device will be in a "standard" byte array format.

[MinHolly]

Yes, I think this is what I've been doing. I will adjust my code and try that! Thank you.

[rolfk]

Binary data is not decimal or hexadecimal. It is simply binary. How that data is displayed to the user is another issue. The LabVIEW string display has built in a few Display Modes.

Normal: displays the string as ASCII text based on the current 8 bit encoding that usually is depending on the selected country/language setting in your OS.

\ Display: Same as above except for those byte codes that have non displayable ASCII characters such as control bytes including Tab, Carriage Return, Line Feed and several more. Here the string displays \-code replacements, either special combinations like \r, \n, \t or numeric forms such as \02 for an <start of text> or \03 for a <end of text> control code.

Password Display: simply replaces every character with a star *

Hexadecimal Display: Prints the hexadecimal values of the bytes, which is pretty much what you tried to do in the first place.

However you used Normal Mode and typed in the hexadecimal values, which is a very different thing than putting a string display in hex mode. In the first case every character in your string is the according byte value for that ASCII character. In the  second case a 2 character code displays the hexadecimal value of the byte in the byte stream (string).

Basically your string "1616161610FF220000A75FF5" really produced the byte stream  <0x31 0x36 0x31 0x36  0x31 0x36 0x31 0x36 0x31 0x30 0x46 0x46 0x32 0x32 0x30 0x30 0x30 0x30 0x41 0x37 0x35 0x46 0x46 0x35>

But you want to send the byte stream <0x16 0x16 0x16 0x16 0x10 0xFF 0x22 0x00 0x00 0xA7 0x5F 0xF5>.

In Normal Display mode this looks like "ÿ" §_õ", in Backslash Display mode this would look like "\16\16\16\16\10\FF"\00\00\A7_\F5", in Hex Display mode this looks like "1616 1616 10FF 2200 00A7 5FF5".

Each of these modes looks different but the underlying binary data is always the same.

[JimB. · Accepted solution]

---

@MinHolly wrote:

As I'm relatively new to LabVIEW, this might seem like a basic question: will this solution suffice given that my device anticipates hexadecimal representation? the hexadecimal representation here is only within LabVIEW, but the data sent to the device will be in a "standard" byte array format.

---

You device expects to receive a series of bytes. However it is encoded for the benefit of the human viewer is not relevantbinary.

0x3A, as an example, is easier to type and read than 0b00111010. That is for the benefit of the human. 00111010 is the series of bits that will travel over the serial bus.

Hex: 0x3A

Binary: 0b00111010

Decimal: 58

ASCII Character: ':'

Octal: 072

I could define a specific byte any of those ways and it will result in exactly the same series of bits sent over the serial port.

[MinHolly]

Thank you for your help!