09-06-2018 10:36 AM
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.
Solved! Go to Solution.
09-06-2018 10:49 AM
"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.
09-06-2018 11:07 AM
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.
09-06-2018 11:11 AM
@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.
09-06-2018 11:16 AM - edited 09-06-2018 11:18 AM
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?
09-06-2018 11:18 AM - edited 09-06-2018 11:19 AM
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]
09-06-2018 11:23 AM
@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. 😄
09-06-2018 11:25 AM
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.
09-06-2018 11:48 AM
@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?
09-06-2018 12:00 PM
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.