Convert to number

[BPerlman]

GerdW,

You are right; I didn't look back at the original post.  And the 10 or 14 does seem to be the amount of data in the message.

I don't fully understand how your hexadecimal displayed data relates to his original screen or to the expected data.

His data screen starts with the header of $ M >.  With the size of 14 that is what you mention,  244D 3E0E.  In your display that does not appear at the beginning.

In any case, the offset of the roll is 4 and it is 4 bytes long, and the other engineering units follow. He should be able to extract and convert that.

I would probably look for the header in the data and extract one message into an array (according to the size).  Then I'd have standard code to interpret a message, extracting the appropriate subarrays and type casting them.  When finished, I'd go forward in the data stream according to the message size in its header, and start from there -- extract thaat message and interpret it.  Etc.  Before interpreting a message, always check that its header is correct, and have some kind of handling if it is not.

Batya

[GerdW]

Hi Batya,

when creating that screenshot I edited to content of the string control to start with then actual data bytes to demonstrate to type conversion…

[deceased]

My general method for this would be (assuming no termination character on serial).

Serial read 4 bytes.

Check if 1st 3 bytes are correct header - discard if bad.

Use 4th byte as input to another serial read to grab the remainder of the packet.

Checkedy check the checksum - discard packet if bad. (probably a 1 byte XOR checksum but I cant open the VI to verify.

Split the data into subarrays and typecast into correct datatypes (check endianness 1st incase byte order is out).

[makewayforkhairil]

Hi deceased, I've attached the VI in ver 2011 🙂

Thank you, GerdW and Batya for your advices! However, I do not know how to implement your suggestions. Would you mind showing me?

[BPerlman]

Did you follow the link in my message 18?  That shows how to extract a subarray and how to typecast, with links to the help for the relevant functions.  That is exactly how I learned to do this!

Batya

[GerdW]

Hi make...,

did you notice message #5? It shows how to use TypeCast.

Did you notice the suggestion of ArraySubset? It's pretty straight-forward to use…

You may also use MatchPattern to search for your message header (using a string constant set to hex display mode and a value of "244D 3E0E" as described before) to find the data bytes in your stream…

All this is pretty basic and will be a good exercise for you to actually learn LabVIEW. Go on and attach your next version of the VI when any (real) problem occurs!

[deceased]

I had a quick look at the data this morning, it seems the packet structure is slightly different than I expected.

3 byte header

1 byte datafield length

1 byte response type

14 data bytes

1 byte checksum

The datafield length may vary for other response types (if they exist - i didnt see any in your vi)

The checksum is the 14 data bytes XORed together (ignores the 1st 5 bytes)

The byte order for the individual data byte elements is incorrect, so they need reversing before casting to correct type.

Do you send a specific command to the device for it to send these responses, or does the device just spew this data over serial?

If its just a spewer, you will need to sync to the data at the start.

[makewayforkhairil]

Hi deceased, yes it just spews out the data over the serial.

Batya:

In any case, the offset of the roll is 4 and it is 4 bytes long, and the other engineering units follow. He should be able to extract and convert that.
 
I would probably look for the header in the data and extract one message into an array (according to the size).  Then I'd have standard code to interpret a message, extracting the appropriate subarrays and type casting them.  When finished, I'd go forward in the data stream according to the message size in its header, and start from there -- extract thaat message and interpret it.  Etc.  Before interpreting a message, always check that its header is correct, and have some kind of handling if it is not.

I just got access to Labview and I tried this. Use MatchPattern to find the header. Exctract array according to size and typecast it. Is there something else that should be in this? 

[BPerlman]

You will have to see if there are byte order issues.

I would tend to do some integrity checks too -- checksum for example, and checking that if you go forward to the end of the message you get to the header of the next one (that is how I personally would progress through the data stream rather than match pattern; using match pattern to realign if data was lost/corrupted and I had to find the next good message).

But you are on the right track.

Batya

[makewayforkhairil]

A lot of errors keep appearing.

VISA:  (Hex 0xBFFF006C) An overrun error occurred during transfer. A character was not read from the hardware before the next character arrived.

VISA:  (Hex 0xBFFF006B) A framing error occurred during transfer.

And my checksum shows weirddd numbers, like AF, B0, 50, 6.