LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Match Pattern of a partial string

Hi,

 

I'm receiving data from the serialport. This data is read as long there is data on the serial port which results in partial strings. I've been using the function "Match Pattern" if the received string is longer or equal to the header. This works fine, but not if the header changes length.

 

Lets say my header has a length of 4, and equals "ABCD". Examples:

  1. AB
    1. Before: empty
    2. Match: AB
    3. Rest: empty
  2. ABCD123.23
    1. Before: empty
    2. Match: ABCD
    3. Rest: 123.23
  3. ACDEAB
    1. Before: ACDE
    2. Match: AB
    3. Rest: empty

Is this possible with MatchPattern? Or do i have to use arrays and for-loops?

 

 

 

 

0 Kudos
Message 1 of 8
(5,594 Views)

I did it the complicated way... At least it works!  Smiley Tongue

 

-Øyvind

0 Kudos
Message 2 of 8
(5,561 Views)

What is the actual format of the data you receive? There are a number of different options (e.g. using a termination character, keeping a string buffer and searching for a start/end character etc.) but it depends on the structure of the data you're receiving.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 3 of 8
(5,554 Views)

it is a 52 byte long string, with header (hex) AA53 and no termination character. With the VI attached above I am able to do what i wanted to, but i was hoping i could use the string function "Match pattern" instead.

 

But it works, and thats whats important!

 

0 Kudos
Message 4 of 8
(5,531 Views)

Ok, if you have a fixed length and a known header string then what I normally do is the following:

 

- Read bytes from the serial port and add to a string buffer (e.g. shift register)

- Use the match pattern/string VI to search for your header bytes, delete everything in the buffer before it

- Check if the length of your remaining string is >= data length - if it is then you have a complete message - remove it from the buffer and convert/parse into your data. Repeat until the length of the buffer is less than your data length (in case you read multiple complete messages in a single read).

 

You can also add in some error checking that if the parsing fails (e.g. invalid checksum if you have one or the header byte appears in your data) that you move to the next header byte and continue.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 5 of 8
(5,526 Views)

Yeah, that is what I've also been doing. But it will give me trouble if the last character of that string (of 52 bytes) is the start of the header. Thats why i needed to search partial strings, and which is what I'm doing in the VI above.

0 Kudos
Message 6 of 8
(5,467 Views)

Hi ThetaMa,

 

why do you get in trouble when your header is 0xAA0x53 and the last char of the message is 0xAA too?

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 7 of 8
(5,455 Views)

As I see it, I will lose the next message if the last char of the 52 byte sting is the first char of the sync.

If I'm searching for xAA53 in the following two strings, I will no be able so see the split message:

 

53 566E BAE8 1C71 2D1A 1BA2 076B 84D5 0000 3A5F 0017 0000 0000 0000 0268 F8E5 0000 0001 0003 0003 0000 0000 0000 0000 0195 3B04 AA

53 566E BAE8 1CD5 2D1A 1BA2 076B 84D5 0000 3A5F 0017 0000 0000 0000 0268 F8E5 0000 0000 FFFE 0000 0000 0000 0000 0000 0195 6799 AA

 

In the case above,my string is shifted one byte (the last AA of the string is the first sync byte, of the next string).

With the attached VI in the previous post, discards everything until AA, which is considered a possible match of the sync. Concetinating AA with the next string will result in a valid string.

 

I know that this will probably not be a problem, but I'm logging some critical data and I dont want to lose some of them...

0 Kudos
Message 8 of 8
(5,430 Views)