Hey,

I am really new to programming and only have basic C++ experience. My problem is that I am trying to connect a machine to my serial port and have the data from the machine put into a graph and displayed. Any ideas?

Btw the machine takes in currents and voltages from a battery. Thanks!

What distribution of Linux are you on ?

Your question can be split into two: how do I read from the port, and how do I graph it.

Very generally speaking (not knowing your setup) for the "read" part:

Most "flavours" of Linux should have support for the serial port built in, so you don't have to program it.
They can be read directly from /dev/ttyS0 , /dev/ttyS1 etc.

You can confirm this with

dmesg | grep ttyS

and you should see something informative.

There is lots of material on this. Do a search on 'read ttyS0'

For the second part of the question you may be interested in RRDTool which will graph just about anything:

oss.oetiker.ch/rrdtool/

Let us know how you are faring !

There are lots of ways you can get data from a serially attached device, and it depends on the behavior of the device.
The 3 most common scenarios:

• the device sends one 'record' whenever it wants, but typically on a periodic schedule
• the device sends one 'record' whenever it receives a request.
• the device sends one file/waveform/dataset when it receives a request.

The nature of the data is very often human-readable ASCII text, but this is by no means universally true.

The above is important because it will dictate a great deal about how you want your program to behave. You may have to prepare queries which get sent to the device, and you may have to parse the received data to extract the specific part you are interested in. The received data may be formatted in one or more of many different ways. Commonly, a 'record' will be a 'line of text', terminated by some end-of-line character(s), especially carriage-returns & linefeeds, either alone or in combination. Frequently, things like EOL types are configurable. Sometimes, the end-of-record is not explicit in the data, but can only be determined by a timeout period. Those types can be challenging.

In any case, pretty much all there is to know about Serial port programming in Linux can be learned from these links:

Serial-Howto
Serial Programming Howto
Serial Programming Guide for POSIX OS's

When you say 'put into a graph and displayed', this can also mean a few different things. Do you want to plot the data like a strip chart; updating the plot on receipt of each new data record in real time? Do you want the data to be displayed in real time at all? Do you want the data to be displayed as part of your program, or is it enough to simply export the data to a standard formatted data file for use by another program such as Gnuplot, or a spreadsheet?

Now that you have some ideas to think abut and more questions to answer, please respond with some more details about your project.

--- rod.

ceyx and theNbomr thanks alot for the quick help.

To answer some of your questions:

I am using Ubuntu 12.04, and will have to try out the RRDTool. Also, the data should be collected real time and displayed, but the ability to export to Gnuplot or spreadsheet would be desirable.

I've been doing some battery research and the "tester" that was loaned to us did not come with any software. So I'm trying to work out something a like LabView from NI...if that makes any sense.

Thanks again for all the help and the information!

Flying blind are you ? Sometimes that's more fun.

Do you have access to the specs of the device ?

In any case you might want to download Minicom, and set it up to interface with your serial port. That way you can SEE the data right now, perhaps after playing with the setup of Minicom. It may give you a better idea of what you are dealing with.

https://help.ubuntu.com/community/Minicom

and you can get some hints from here : ( Minicom setup for a cisco console )

https://help.ubuntu.com/community/CiscoConsole

regards

I agree that you want to use a serial comm's package to communicate directly and interactively with the device. In minicom's default configuration, it is set up to communicate with a modem that knows how to interpret the AT commands that minicom sends. If you understand what this means, then disable the initialization strings in minicom first. Otherwise, I suggest the use of a more versatile serial communications package such as C-Kermit, which allows for more fine tuning of your serial port, and is a better tool for communicating with things that are not modems.
Do you have a working cable and serial port on the host computer? Do you require help configuring a serial cable (not all serial cables and ports are created equal)? Don't bother writing any code until you've established that the hardware (serial ports, cable) and OS drivers are working. Until you know that bytes are travelling to and from the device, you will just be beating yourself up trying to debug your code. Once you have established that serial communications does work, you can start your coding by building one or more of the code samples from the links I posted previously.
If you are going to be using RRDtool, you can focus almost entirely on the communications aspect of the task. Is the device you are using also a controllable device that can be commanded to accept configuration commands? If so, since you've said you are trying to achieve something Labview-like, it sounds like you also may want a GUI to allow end users to operate the device. The three possibilities that come to mind there are:

• roll-your-own using something like QT or GTK
• build in a web server interface using something like libmicrohttpd
• write little or no code and use a SCADA system, either FOSS or commercial

The use of either of the first two choices does not preclude the other. Building in a web server is a fairly low-pain way to get something useful early on in such a project.
--- rod.

Without knowing anything about the tester's protocol it might be a bit difficult. Can you post the make and model number of the tester device? If the protocol is ASCII based your task is a bit easier and another terminal application suggestion is cutecom. It can also send and receive hex data as well as ASCII.

T&M instruments are usually quite sensible about the data format, if they send and receive ASCII data. Some of the complications that can make life more interesting are:

• the use of odd record and field delimiters
• the use of checksums attached to each transmission
• the use of non-ASCII data
• the use of flow control and/or handshaking that involves the hardware or driver
• interpreting off-normal and error related messaging, especially if such messages are sent unsolicited.

That last one can be quite an obstacle, especially if they are undocumented, or incorrectly documented. Some errors are difficult to handle gracefully, since the device may enter some off-normal state, requiring your program to behave differently. If the device is not well documented and you are forced to test and develop in-situ, you may be unable to reproduce error conditions that cause error messages to be emitted.
If the format of the retrieved data is inconsistent, your code may need to be quite smart about parsing the returned data, and a tool such as lex might be a useful aid in crafting a parser. In most cases, some rudimentary defensive programming against buffer overflows and such, plus scanf() oriented parsing is adequate.

--- rod.