LabVIEW
How to get only the string out of a U8 array?
Solved!
Hi MaSta,
@MaSta wrote:
LabVIEW strings can also contain more than one 0x00 making its length longer than the number of actual ASCII characters. That is, unfortunately, what the standard VI "Byte array to string" does. It keeps trailing zeros.
The other standard VI "Trim whitespaces" would also not remove the zeros, though they are not ASCII characters.
Why do you think NUL is not a valid ASCII char?
And yes, LabVIEW strings can contain any byte values from 0x00 to 0xFF…
@MaSta wrote:
Can someone say, why "Byte array to string" wouldn't remove the trailing zeros?
As said before: LabVIEW strings can contain ANY byte values. They keep their length information seperately!
@MaSta wrote:
How to get rid of the trailing zeros? Is there no VI for it? Of course I could program something to find the first 0 and split the string, but that's it?
When you want to remove "trailing zeros" then you should NOT search for the first 0x00 byte…
- You can look inside the TrimWhitespace function and replicate it's behaviour (for trailing bytes) in you own function.
- You can also work on the byte array level using array functions and loops (autoindexing, conditional tunnels).
- You can prevent those trailing zeros when creating those byte arrays/strings to avoid cutting strings later in the process…
This is what TrimWhitespace is doing:
You can easily copy that code and change it to remove 0x00 bytes at the end…
@MaSta wrote:
In my logic, which is different to what LabVIEW does
That is the main problem in this question… 😄
No, a normal string, but without the zeros, as LabVIEW would have it when you create a string constant.
My solution now is
@GerdW: I hear you, but that doesn't make it logical. "In computer programming, a string is traditionally a sequence of characters". Byte 0x00 isn't a character, it's a value, a number. I actually expected LabVIEW to handle it just like that. Well, you never stop learning...
Hi MaSta,
@MaSta wrote:
@GerdW: I hear you, but that doesn't make it logical. "In computer programming, a string is traditionally a sequence of characters". Byte 0x00 isn't a character, it's a value, a number. I actually expected LabVIEW to handle it just like that. Well, you never stop learning...
You never stop learning!
From your link to "characters" you can read this paragraph:
Examples of characters include letters, numerical digits, common punctuation marks (such as "." or "-"), and whitespace. The concept also includes control characters, which do not correspond to visible symbols but rather to instructions to format or process the text. Examples of control characters include carriage return and tab as well as other instructions to printers or other devices that display or otherwise process text.
So I repeat: 0x00 is a valid ASCII char (named NUL)! I already linked to the ASCII table in Wikipedia in my previous message.
It's the very same character class as is BEL, LF, CR, ESC, FF, STX, ETX, …
What you are referring to are null-terminated strings, which are used only by a subset of programming languages (due to several limitations described in the linked article).
As I wrote before: LabVIEW stores the string length separated from the string data!
For me this all sounds very logical, so I still guess the problem is with your logic (aka programming experience with other programming languages)… 😉
@MaSta wrote:
@GerdW: I hear you, but that doesn't make it logical. "In computer programming, a string is traditionally a sequence of characters". Byte 0x00 isn't a character, it's a value, a number. I actually expected LabVIEW to handle it just like that. Well, you never stop learning...
What you are expecting is a NULL-terminated string, what I usually hear call a C-style String. What LabVIEW implements is a Length-Prefixed string, which has the length of the string (I32 in this case) before the actual bytes/characters in the string. When using this method, a NULL is a valid character.
@GerdW wrote:
What you are referring to are null-terminated strings, which are used only by a subset of programming languages (due to several limitations described in the linked article).
As I wrote before: LabVIEW stores the string length separated from the string data!
Like Pascal, IIRC.
C++ is often used as the norm, but it really isn't and certainly hasn't always been.
There are ups and downs with "Pascal strings". The only downs are when dealing with external code, like most Windows APIs. LV never cared much for interfacing with external code.
Search LabVIEW like a graph!
@MaSta wrote:
No, a normal string, but without the zeros, as LabVIEW would have it when you create a string constant.
My solution now is
If you want to remove all \00's, you might as well use Search and Replace String:
If you only want the beginning of the string, you can use split string:
Note those display styles. They're useful...
If you want to use the match pattern, use \00, not \0 (although it works). If you add a letter to it, \0 won't work: \0a vs \00a. It's officially 2 digits.
Further note that with regular expressions (not match pattern) (also used in Search And Replace String when turned on) you should use \000, at it's a 3 digit octal number, or \x00 to specify a hex number.
As has been said, you seem to have problems with terminology:
@MaSta wrote:
How to get rid of the trailing zeros?
A "zero" is ASCII character 48 (decimal), which is completely different to your \00 (0 in decimal), i.e. ASCII NUL,
Any byte value from 0..127 is defined in the ASCII table, and the rest, up to 255, as extended ASCII. ASCII is just an ancient convention that assigns special meaning to byte values (control character, printable character, etc), for example a printer that receives a decimal byte of value 65 will print the letter "A". while a decimal value of 10 would make it go to a new line.
Are the only \00 in your string "trailing" or could the be others? Do you know why they are there in the first place? How many are there? Where does your string come from? (Instrument? Some third party driver? Some DLL? Your LabVIEW code? etc.)
wiebe@CARYA wrote:
There are ups and downs with "Pascal strings". The only downs are when dealing with external code, like most Windows APIs. LV never cared much for interfacing with external code.
Never cared? It has a Call Library Node with a few 100 options which is generally a few 100 options to much for most users! Do those few 100 options cover every possible craziness out there in external code? No of course not, that would require a few 1000 options and that would be a few 1000 options to much for pretty much every user.
