LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Ignoring Short Hex Streams

Hello all,

I have been beating my head against this problem for nearly 3 hours now and just can't come up with a competent solution. My VI is receiving a hex stream from an external USB device, picking out some bytes, doing some number manipulation and kicking the number to an NI touch panel connected through a different serial port.  Where I am stumped is that my external USB does not always kick out a perfect 19 byte stream, as it should.  Sometimes I will only get partial streams, which screw up my stream by jumbling around the header (xFEFE). So, what I am trying to do is figure out a way for the VI to just ignore the stream if it's less than 19 bytes in length. Some of my ideas include either:

(1) Taking the partial stream and filling in the missing bytes with a hex x00.
(2) Ignoring the short stream, and instead, resending the last full 19 byte stream.
(3) Finding a way to parse through the stream everytime for my header (xFEFE) and restarting the stream there.

The problem with #1 is that it briefly messes up the numbers calculated. But, I can deal with it since it's only for a second, just not sure how to concanate a variable number of strings.
The problem with #2 is finding an easy way to do this in Labview for a relatively new user.
The problem with #3 is that the short stream isn't really always long enough to get all my data, as I need bytes 2,3,4,5,6,7.

I've attached my VI to this post and below is an example of a good stream, a bad stream and what happens to the stream after a bad read.

Good stream: FEFE 0945 163D 2279 1A16 2F0D 1234 5678 2343 02
Bad stream: FEFE 0945 163D 2279 1A16
Result of bad stream: 2F0D 1234 5678 2343 02FE FE09 4598 7698 5476 98

xFEFE should always start the stream.

Thank you for any suggestions on ways to do my current ideas or any ideas on your own.
0 Kudos
Message 1 of 19
(4,128 Views)
Hi Headtrip,
 
Is the 02 at the end, always 02, or a checksum?
 
I just did a serial application, with messages in the form of:
 
STX BCH BCL MSG Data0....Datan CS ETX
 
I implemented a state machine to scan the data stream an validate the message as I went along.  Since you have a fixed message length, it should be even easier.  Scan until you find the header.  Build the string until you have 19 bytes.  If you run out of data, just hold onto the current buffered data until the next block comes along.  At that point you re-enter the state machine and pick up where you left off.  If the last byte is a check sum (or always 02) validate it, if it is good then you have a valid message.  Otherwise, you have a bad message, at which point you either throw away all the buffered data you have so far parsed, or you start re-scanning it and looking for the header again......  
 
If you post more detail as to what the  data stream represents (longs? signed?  does any of the data have value limits? etc) it would help us help you make a robust solution......
 
Regards,
Howard
0 Kudos
Message 2 of 19
(4,123 Views)
I noticed that the "End read on termination character" is on.  Do you have better luck if it is off?  If you are receiving HEX data, then you never want to terminate a read since any byte can be 0x00 - 0xFF....
0 Kudos
Message 3 of 19
(4,116 Views)
Wow tartan, thank you so much. Turns out the bad stream was strictly related to the end read on termination character, turning that off solved the short stream problem. Guess that's what I get for staring at the same VI for too long without another set of "Labview eyes" to look at it. I still plan on possibly implementing one of your ideas though, just as a fail safe, assuming time permits. Thanks again!
0 Kudos
Message 4 of 19
(4,096 Views)
Well, turns out I spoke too soon, it still shorts the stream, just not as much now. I won't lie, I'm not the greatest at understanding the different formats of hex and binary strings. However, I do have a PDF of what the sequence of bits is, if that will help? I have attached it to the post. Let me know.
0 Kudos
Message 5 of 19
(4,091 Views)
Hi Headtrip,
 
I'm on the road now, but the info you posted is very helpfull.  The data packet has lots of structure built in that you can verify per byte as it is being received.  I'll try to post more tonight when I land, if you can wait and someone else doesn't beat me to it.......Smiley Very Happy
 
Howard
0 Kudos
Message 6 of 19
(4,078 Views)

Hi Headtrip,

 

If you can wait until later today, when I get back I could post an example state machine to parse the data for you.......

0 Kudos
Message 7 of 19
(4,054 Views)
Certainly, I appreciate the help!
0 Kudos
Message 8 of 19
(4,051 Views)

Hi Headtrip,

Can you post  5 examples of "good" streams?  I'm looking at the first stream you posted, it has 19 bytes (spec is 18), the marker byte is invalid, and the cs doesn't add up.....  I need some valid streams that I can run through the state machine......

Thanks.....

0 Kudos
Message 9 of 19
(4,036 Views)
Here's six, nearly consecutive readings from the USB device:

FEFE 0949 2023 5310 237B 5875 9100 004E 004E 0C
FEFE 0949 2023 5744 237B 5D27 9100 004E 004E 7B
FEFE 0948 2023 5B75 237B 615A 9100 004E 004E 66
FEFE 0948 2023 5F37 237B 651C 9100 004E 004E 72
FEFE 0949 2023 6278 237B 685D 9100 004E 004E 7B
FEFE 0949 2023 663B 237B 6C1E 9100 004E 004E 07
FEFE 0949 2023 6A70 237B 7051 9100 004E 004E 77
0 Kudos
Message 10 of 19
(4,026 Views)