LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

convert data from serial port to real time plot

OK,

I have already looked at that doc too long.

What would be more helpful would be a VI with more than one "update" as read from the serial port in hex mode.

I suggest you srart with

examples >>> Hardwae I/O >>> Serial >>> Basic serial write read

Set your baud and parity

disable the term character

specify an extremely large time out value

Change the "Bytes Read" control to a control (after disconnecting from the bytes at port node)

Set the number of bytes to read to something extremely large.

Run the VI and just to do the "Read" part.

Right click the "Read String" indicator and look at the data as hex.

If you can adjust the size of the string indicator so that you can "collumns" that match-up...

It is probably fixed length

The collumns that match-up will show the byte values used to frame the data.

If you save the string indicator with recieved data as its default, you can post it and we can probably decypher the format for you.

I will watch for you to post the VI because I am now curious.

Have fun,

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 21 of 34
(2,431 Views)
A continued thanks to both JLS and Ben. I have learned some interesting things about labview and coding in general. I followed Ben's advice and here is the Vi. From the read string I have noticed that 2430 and 2423 are the repeating sequences in the sensor output and I believe 23=# and 24=$ in hex code! 
 
Here is the attached vi with the hex output of the sensor as you described in your previous post.
 
Frank.
0 Kudos
Message 22 of 34
(2,422 Views)

Hi Frank!

There is a phrase bieng used on LAVA alot these days that I'd like to paraphrase as "Talk is cheap, show me the [data]."

You data has no term character unless you want to call the "$" the term character.

The attached VI may help you get going. It Parse the data data stream into packets.

It first locates the first "#" then verifies the "@" and the "$" are in the right places relative to the "#". If all three can be found were they are supposed to be, it conciders it a valid mesage and pulls the message data out and puts it in an array.

I hope this helps,

Ben

Message Edited by Ben on 03-30-200607:54 AM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Download All
0 Kudos
Message 23 of 34
(2,415 Views)
Hi Ben,
 
Thanks for chiming in on this one - I'm not sure what you meant by "This does not make sense even if the protocol is fixed length." though.  Anyway, I'm sure your generous contribution here will help!
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
0 Kudos
Message 24 of 34
(2,403 Views)
On its surface, I do not see how the protocol prevents the possibility that the framing character sequence does not occur in the data stream.
 
If the numeric fields are allowed to take on any value, there is the possibility that that framing sequence can be missed.
 
Say you start the serial I/O when the widget was broadcasting an update such that you miss the initial #@ and see data followed the final character the $. Another packet comes in and you do catch the #@ plus some trailling data etc.
Within that character sequence you (ie in your read buffer) ...$#@....
 
But in Hex that would be ...24 23 40 ...
 
So if the update ever involved send the value ....24.23 40.X....(Hex) the process of faming the message could be falsely triggered.
 
That is the part that did not make sense.
 
I could always sit down and read the manual on that widget but that was too much like work (I only answer questions for fun)! Smiley Happy
 
Ben

Message Edited by Ben on 03-30-2006 05:58 PM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 25 of 34
(2,400 Views)

Frank,

Are you OK with your project?

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 26 of 34
(2,388 Views)

Hi

The error correction of ben's vi could prevent some possible missing or corrupted data being plotted incorrectly by JLS vi. I think keeping the sensor transmit its data in binary form allows ben's vi to check whether it is a valid piece of data. But how do I convert the parsed HEX data back into numeric values (x, y and z axis numbers) which can be plotted in JLS vi.

Any suggestions. Thanks for the continued interest in this project.

Frank.

0 Kudos
Message 27 of 34
(2,373 Views)

Hi Frank,

Try this code for example.

Its a mod of what I posted earlier. I corrected my byte offsets (that were wrong! I was missing half the messages) and added logic to track message fragments from call to call.

I also convert the strngs to numbers for you to plot.

Operation:

On the first call to this VI the "left over" shift register is cleared. There after, the bytes left over after parsing a string are saved and then prepended to the incoming data stream.

The data is then framed and the data packets extracted from the data stream and accumulated in an array of strings.

The strings are then type cast as an array of U16. The is one collumn for each value and one row for each update.

Try to adapt a version of hist in your application and post the complete app if you need to ask follow-up Q's.

Trying to help,

Ben

 

Message Edited by Ben on 04-02-2006 11:12 AM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Download All
Message 28 of 34
(2,358 Views)
Hi Frank,
 
I was under the impression that you were receiving ASCII data, in the format we conversed about early in the thread.  But indeed if you are receiving your data in raw binary form, it is entirely possible that one of the bytes representing your data could happen to have an ASCII representation of your termination character, which would prematurely terminate your read operation on a given iteration.  I will read Ben's newest post in just a moment (and I am sure it is fabulous as usual), and I hope your getting closer to your solution!
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
0 Kudos
Message 29 of 34
(2,337 Views)

Hi

Sorry JLS for the confusion from a newbie. The sensot has three ouput

ascii number of x y and z axis data

x= 1 y=0.4 z=0.32

Raw data format

X=0x01A2 Y=0x0255 Z=0x0340

and finally binary format

Byte     Description

0          Start Char- #

1          Data output designator- @

2          Sample No High Byte

3          Sample No Low Byte

4          X Hi Byte

5          X Lo Byte

6          Y Hi byte

7          Y Lo byte

8          Z Hi byte

9          Z Lo byte

10        End Char- $

The manual suggested that this format might be more suitable for pc processing. At the moment I trying to figure out how to wire in bens vi which check the data, converts it to numbers and then plot it.

The first set of no.s is the sample no.=0-65000 and then rolls back to zero. The other three no.s are x y and z axis data. I just need the x, y and z in the graphing format you previously recommended. I will continue to look at before i come asking for more help! Thank god I think we are nearly there 🙂 thanks to jls and ben

Frank

0 Kudos
Message 30 of 34
(2,315 Views)