LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial data parse, remove head

Solved!
Go to solution

Hello,

I am newbie in labview.

I need simple labview program for reading from serial port, convert 2 bytes to one uint16 value, and show them.

I am receiving 26 bytes. Is it posible to work like that:

Read bytes, and when 2 bytes of head appear, read next 24 bytes. 

Or is it some better solution for reading like that?

Here is example of my incoming data :

F490 F495 F489 F492 F48F F490 F488 F489 FFFF F4A5 F497 F486 F492 F494 F493 F493 F49C F494 F494 F49F F49A 

FFFF is head.

I didn't find any topic here about this problem.

0 Kudos
Message 1 of 11
(3,823 Views)

It's definitely possible to do what you want.

 

The two bytes can be joined to form a U16 using Join Numbers.

Checking for FFFF can be done by checking each byte for FF, then checking if the next is also FF.

 

However, if you know the format of all of the data and can establish the "phase", for want of a better term, you can read all of the data and parse it appropriately.

 

Are the incoming data that you described (.... FFFF ....) the string representation, or are you receiving them in some other form? Take care to note that one byte of serial read will give you one ASCII letter, but that you need two hexadecimal characters to form a full byte numerically (i.e. FF = 255 = 11111111 base 2)


GCentral
0 Kudos
Message 2 of 11
(3,818 Views)

Thank you for answer,

so, i need to read byte by byte and using simple IF statement for checking if Byte is FF.  And how can i check next byte?

Sorry for my question, but I don't get it.

when data comes in one time, it would be OK, but I am sending this 26 bytes each 10ms. 

Could you provide me simple diagram of this serial communication?

My serial communication work, I've opened serial port, Checking bytes, and if there more bytes than 1, I am reading that in while loop.

0 Kudos
Message 3 of 11
(3,806 Views)

Read two bytes at a time (one byte at a time will just give you F, right?) then check for repeated true comparison.

 

Here's a simple example:

test.png

 

Some comments are given to show possible alternative choices - for example, if you know you can't be off by a byte, you can read 4 bytes (ASCII, so 2 bytes of binary data) then check directly for FFFF. However, if you might be offset, that could lead to xxFF, FFxx, which wouldn't satisfy the condition.


GCentral
0 Kudos
Message 4 of 11
(3,796 Views)

I hope its better to read all data bytes in the serial Buffer at once and Process a String Operation to Find the header and Data payload.

----------------------------------------------------------------------------------------------------------------
Palanivel Thiruvenkadam | பழனிவேல் திருவெங்கடம்
LabVIEW™ Champion |Certified LabVIEW™ Architect |Certified TestStand Developer

Kidlin's Law -If you can write the problem down clearly then the matter is half solved.
-----------------------------------------------------------------------------------------------------------------
0 Kudos
Message 5 of 11
(3,785 Views)

Can you be sure that the buffer contains the whole phrase? If it is coming in slowly then it could take a while for it to appear there, better to work iteratively.

CLA - Kudos is how we show our appreciation for comments that helped us!
0 Kudos
Message 6 of 11
(3,780 Views)

There is one problem. Data is coming like HEX byte. Not as string.

So my bytes FFFF is in string this character ˙˙.

So I've found only the possibility to convert that into byte array.

0 Kudos
Message 7 of 11
(3,765 Views)
Solution
Accepted by topic author dbarvik

@dbarvik wrote:
I am receiving 26 bytes. Is it posible to work like that:

Read bytes, and when 2 bytes of head appear, read next 24 bytes. 

Or is it some better solution for reading like that?


You give a lot better information than most when asking these types of questions.

 

So one thing to hit first: Since we are dealing with raw/binary/hex data, make sure the Termination Character is turned OFF.  It defaults to TRUE with the VISA Configure Serial Port.  So just set that input to FALSE.

 

Now as far as code structure, I have found it best to read 1 byte at a time until you read 0xFF.  Then you read another byte and verify it is also 0xFF.  If verified, read the rest of your message (24 bytes).  Then you can repeat the process from there.  I say to read 1 byte at a time instead of 2 because you could be out of sync by that 1 byte and you will therefore never catch the FFFF.  Using your example, you could read 89FF and then FFF4.  Neither of your two reads would match your FFFF requirement and you miss your entire message.  So read 1 byte at a time to find the sync.

Note 1: Notice the FF constants.  I have those set to be in Hex display.  Right-click on the string constant and choose Visible Items->Display Style.  You should see a little 'n' show up as part of the constant.  That is showing you are in "Normal" display.  You can then click on that 'n' and choose Hex Display.

 

Note 2: All FALSE cases just pass the VISA Reference and error straight through.


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 8 of 11
(3,760 Views)

@PalanivelThiruvenkadam wrote:

I hope its better to read all data bytes in the serial Buffer at once and Process a String Operation to Find the header and Data payload.


As somebody who did that early in his career, I can tell you that that is NOT the way to do it.  It led to nothing but slow processing and major memory issues.  Use the VISA buffer and read only what you need for your message and then use a Producer-Consumer to pass that message on to another loop for actual processing.  This becomes especially needed when you have constant data coming through the serial port.


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 9 of 11
(3,758 Views)

Producer/Consumer was my next suggestion, if data processing in-line was too slow for 10ms messaging rates.

Is it? Perhaps depends on amount of parsing computation required and PC...


GCentral
0 Kudos
Message 10 of 11
(3,746 Views)