Serial Read Write & Graph/Chart double/float type values

[bk2001050]

Hi Guys, I am working on a final year engineering project that involve streaming live data from a micro controller via serial to labview and hopefully saving it/applying filters etc.

I have modified the basic serial read write vi to give continuous data and change the string to a float with one of the recommendations on this forum. 

The microncontroller is simply programmed to serial write a value between -5 and 5 in increments of 0.1 increments. Please attached code, basically just 4 for loops. The variable is a double i.e 8 byte.

I get stuck with graphing, there is a distinct pattern in the graph which corresponds to what my micro controller is outputting but whats happening is Labview reads 4.89 as a 4, and an 89 and graphs those values on the chart.

Thus the charts jumps rapidly but a pattern emerges.

My question is how to read a double properly and graph it as one value. Any reference or thoughts would be appreciated. Thank you!

[Gprogrammer]

Hi,

you should read input data up to a CR/LF is comming

and then read in the numbers. Otherwise you may

have lost sync of yor data stream.

Maybe you do this in a little state machine that will process

input data with two states one that waits for the CR/LF

and another taking the number.

[Bob_Schor]

I suspect that you do not understand your microcontroller, do not understand how (most, but not all) Serial Devices that use VISA communicate, and do not really understand LabVIEW and how to utilize the Principle of Data Flow to make your (programming) life simpler.

Know your Device.

• In addition to Reading (and understanding) the Manual for your micro-controller, you should plug it into your Computer and "play with it" using MAX.  It should show up in Devices and Interfaces as a VISA or COM device.
• Try to configure a Test Panel for it.  It should have a section for setting up Serial Parameters.  Modern micro-controllers can have pretty high Baud rates, and almost everything will use N-8-1 (No Parity, 8 data bits,1 stop bit).  Also, almost everything puts <CR><LF> at the end of data it sends to you (and probably expects at least <LF> or \n at the end of commands you send to it).  This is called a Termination Character (it is really the <LF> that's the character, 0xA).
• Once you have MAX set up properly to talk to your device, send it the "Initialization" command.  Don't forget the Termination Character (read the Manual to be sure I'm right about this).
• Most devices return an acknowledgement following a command.  For "Initialization", it might be an identifier of unspecified string length.  Go ahead and request a read of 1000 characters (way more than you ever expect) -- you should get a short string.  Why did it stop before reading 1000 characters?  Because you specified a Termination Character when you set up the VISA port.
• Now give it the command to send some data.  Read the data.  Look at the data.  Take note of its formatting, paying special attention to how you might parse the data.  Are multiple entries separated by commas, by tabs, by spaces?  Is the "decimal" character a period or a comma?

Understand LabVIEW and what you want to do.

• Now translate what you did, manually using MAX, to LabVIEW.
• Start by (once!) initializing the VISA port.  What value should you use for "Enable Termination Character"?  Does it make sense to use Front Panel Variables (as opposed to Constants, which correspond to "Values you Know" (from the Manual and from your experiments with MAX), creating less chance of failure because someone entered the "wrong number" or value?
• Is there an initialization sequence/response that you need to do?  Once or every time you need data?
• How does the system really function when it is all initialized and "doing its thing"?  What is the format of the Data String?  Can you come up with some Parsing Rules?  Can you take advantage of some "parsers" built into LabVIEW?  [Take a look at the Spreadsheet String functions on the Array Palette, and on the Scan from String function on the String Palette].
• What LabVIEW Structures make sense when dealing with parsing Strings?  With the entire flow of your Program and what you want to do (not how you want to do it -- the "What" comes first)?
• Are there "sub-tasks" that are repetetive and filled with "details" (parsing comes to mind) that might benefit from being "encapsulated" in a 32x32 pixel "box" on your Block Diagram with wires going in and coming out, rather than a mess of LabVIEW functions that tend to create a bloated Block Diagram where you can't "see the Forest for the Trees" (meaning there is so much picky detail that the overall goal gets lost)?  That's a great time to create a sub-VI.

Sub-VIs are (or should be) your Friend

• Try to build all your sub-VIs using the default 4-2-2-4 Connector Pane.
• Wire Error In and Error Out to the lower corners.  Use the Error Wire to connect (almost) all the functions inside the sub-VI (there are, of course, exceptions to this principle, but it probably applies 95% of the time).
• Replace the LabVIEW-generated Icon with your own.  Start with a White Box with a Black 1-pixel Frame, and put a 2-3 Word "Description" saying What It Does ("Init uCtrlr", "Parse Wgts", "Turn On Motor").

Bob Schor