LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Parsing hex with Scan from String?

Solved!
Go to solution

A year ago I wrote a VI that parsed an incoming ASCII serial stream and displayed that telemetry with some conversions. Worked great. I used VISA Read into Scan From String.

 

Now I'm attempting to modify that same VI to parse an incoming hex string (not ASCII). I have modified the format string input to be all hex characters, but it does not work. If I write a routine on the device that's sending the data to send it out as ASCII hex, then the VI works great. But for various reasons that's not ideal and I need it to be non-ASCII hex. Is there a way to get Scan from String to interpret straight hex? If not, is there another way to do it? I see Hexidecimal String to Number, but that does not appear to be able to break out the stream into multiple pieces of telemetry like Scan from String does.

0 Kudos
Message 1 of 36
(3,958 Views)

"Hex" does not tell us anything, and non-ASCII-hex even less.

 

You either have a hexadecimally formatted string consisting of the characters 0..F and possibly delimiters or you have a plain binary string where any of the 256 possible bit combinations for each byte are allowed. This has nothing to do with hex, but it could be displayed as hex for readability.

 

If you have a binary string, you could e.g. typecast or unflatten it to the right datatype.

 

We cannot give further advice unless you attach a small example that contains a typical string and information what the result should be.

0 Kudos
Message 2 of 36
(3,953 Views)

The incoming hex string looks like this:

3E80007D0000BB80003E80007D0000BB80003E80007D0000BB80003E80007D00004103400340

Which, when viewed by a terminal in ASCII mode looks like this:

>.<NUL>}<NUL><NUL>..<NUL>>.<NUL>}<NUL><NUL>..<NUL>>.<NUL>}<NUL><NUL>..<NUL>>.<NUL>}<NUL><NUL>A<ETX>@<ETX>@

I only make that distinction to be clear that what is coming in is NOT this:

33 45 38 30 30 30 37 44 30 30 30 30 42 42 38 30 30 30 33 45 38 30 30 30 37 44 30 30 30 30 42 42 38 30 30 30 33 45 38 30 30 30 37 44 30 30 30 30 42 42 38 30 30 30 33 45 38 30 30 30 37 44 30 30 30 30 34 31 30 33 34 30 30 33 34 30

Which looks like the first hex string when viewed in ASCII mode. I hope you understand why I wanted to make that clear.

0 Kudos
Message 3 of 36
(3,941 Views)

@lavadisco wrote:

Now I'm attempting to modify that same VI to parse an incoming hex string (not ASCII).


Then Scan From String will not work.  You need to find the protocol of the device sending this data and decode the message to get the data you need.  This will likely involve String To Byte Array, Unflatten From String, String Subset, Index Array, and/or Join Number along with other functions depending on the message protocol.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 36
(3,937 Views)

So what does that particular binary string (which you apparently display in the first box as hexadecimally formatted with one character/nibble and no delimiters) represent? How long is it?

 

What is generating/sending these bytes? Do you have documentation from the instrument manufacturers? Do you have the program the generates them?

 

0 Kudos
Message 5 of 36
(3,936 Views)

Is there a reason you can't just use the "string to byte array" primitive?  That will convert your string into an array of U8 values.

 

Once it's an array you can use the array primitives to search for delimiters if it uses those, or split it into subarrays if you have a table that details the byte packing, etc.

 

[Edit:  I apparently don't type fast enough, the two above replies weren't there when I started]

0 Kudos
Message 6 of 36
(3,935 Views)

@Kyle97330 wrote:

That will convert your string into an array of U8 values.

 


That really does not do anything useful. All the operations you describe (search, split, etc.) can be done equally well on the original string. Ultimately things need to be unflattened, so it is convenient to eliminate the U8 array middleman. 😄

0 Kudos
Message 7 of 36
(3,922 Views)

Thanks all, sound like Scan from String won't work here. I will look into String to Byte Array. I was kind of hoping what I already had could easily be modified, but it appears it's going to be a bit more work than that.

 

The output device is a microcontroller serial out that I programmed myself, through an RS-422 driver IC. Nothing more than what I posted is coming out of it.

0 Kudos
Message 8 of 36
(3,921 Views)

@lavadisco wrote:

The output device is a microcontroller serial out that I programmed myself, through an RS-422 driver IC.


So you know what the data format is!  So what is the message protocol you programmed into the microcontroller?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 36
(3,908 Views)

Yes, I know exactly what it is and what each byte means. The previous version of this circuit output its data in an ASCII hex stream, so I have already written a complex (for me) VI that successfully parsed and displayed all of that. Since then I have improved the system with much higher ADC resolution, and sending all that data out as ASCII is now too large a data volume, so I'm sending it as straight hex.

 

Was looking for a quick solution here, but the quickest thing to do given my greater experience in C vs LabView is to just write an ASCII conversion on the microcontroller that I can comment out later, which I already did and it works. However, in the future when I have time I'd like to re-write the VI to accomodate the hex stream.

0 Kudos
Message 10 of 36
(3,902 Views)