Serial Port Comms, Java & Minicom

[savage]

In my quest for doing as little work as possible, I'm making an application to "monitor" our machine at work.

What the app will do is:

• Count the number of bags generated by the machine
• Send images of the bagger (incase it stops sealing)

To know how many bags are being generated, I have made a simple serial port loopback plug, which is wired to a tilt sensor, when the machine is idle, the connection is made, and whatever is sent, is received. When a bag is being dropped, the signal is cut, and nothing is returned. Simple.

I've had no end of crashes when using the Java RXTX libraries, and to be honest, they are totally overkill for what I need. Even if I do get them working on the development PCs, I can see another mission to get them working on the final PC.

I've got it so that it is reciting the alphabet over the serial port, literally by using a FileOutputStream to /dev/ttyS0, and reading it back in with a FileInputStream, code below.

The application works fine, provided I load minicom before it runs, if I exit minicom, the app fails to read /dev/ttyS0 again. If I run the application without minicom, and load minicom afterwards, minicom receives the alphabet, so sending is working, but the application can't read it. If I kill -9 minicom onces it's running, the application continues to receive input.

My question is this: What is Minicom doing that's enabling the serial port for reading?

To answer my own question, I guess (since this will be a headless PC), I could just get it to load Minicom in the background and then 'kill -9' it, the problem with both running is they interfere with each other, one will receive one character, the other the next and so on.

Any help on this would be greatly appreciated.

Code for the test application:

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;

public class DirectRead {
	public static void main(String[] args)
	{
		FileInputStream in = null;
		try {
			in = new FileInputStream("/dev/ttyS0");
			(new Thread(new WriteData())).start();

			int c = 0;
			while ((c = in.read()) != -1)
			{
				System.out.print((char) c);
			}
			in.close();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}

	public static class WriteData implements Runnable {
		public void run()
		{
			try
			{
				FileOutputStream out = null;
				out = new FileOutputStream("/dev/ttyS0");
				int c = 65;
				while (true)
				{
					out.write(c++);
					if (c >= (65 + 26))
					{
						c = 65;
					}
					try {
						Thread.sleep(1000);
					} catch (InterruptedException e) { }
				}
				//out.close();
			} catch (IOException e) {
			}
		}
	}
}

[savage]

Further info for guess work, when I load minicom, I get the following string printed back through the serial port: 'AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0' so I'm guessing minicom is sending this string to initialize the modem that doesn't exist.

I've modified the Java app to send that string, but when it does, I get 'AATSSLVXEQA' returned repeatedly.

By tinkering I've found that if I send a carriage return or new line char, this kick starts the serial port, but it constantly sends the first character sent back. i.e. If I send '\r', then 'A', then 'B', I will receive loads of '\r' back, followed by a 'A' or 'B' and then more '\r' characters.

Still when run with minicom loaded, everything works as expected.

[RupertPupkin]

This guide may help you, especially the Accessing Serial Ports section in Chapter 1: http://www.easysw.com/~mike/serial/serial.html
The examples use C but they shouldn't be too hard to port to Java.

[stevea]

Almost certaily the issue is that minicom is setting up the serial port "stty" configuration. This sets things like baud rate and flow control and ... So long as you hold the serial port open with the Java app, everything is fine. Once it's closed the configuration is lost.

Read & understand the output of "stty -a </dev/ttyS0" while minicom is running.
You need to use stty or more likely the driver ioctl calls to set the params to a similar state.
See
man 4 tty
man 3 termios
Also review 'man 8 setserial' which might solve your problem without much trouble.

[savage]

I should have checked back sooner, I'd just finished the final touches to the ultimate blu-tac code ever:

try {
	System.out.println("Launching minicom...");
	Launcher.launchApp("minicom", "");
	System.out.println("Waiting 10 seconds for it to fully load & set COM port...");
	Thread.sleep(10000);
	System.out.println("Terminating minicom...");
	Launcher.launchApp("pkill", "-9 minicom");
} catch (Exception e) { /* Do nowt */ }

I was proud of that, but anyway, better ways await.

Rupert, thanks for the link, I did brush across a few C samples on my searches. I don't know Java inside out, but better than I know C/C++. From what I could tell (I could be totally wrong), the flags in C, 0_NDELAY (the signal line), don't exist in Java except for with that RXTXComms package (which crashes a lot (for me)).

Steve, thanks for the info, a lot of what I saw in those man pages scared me, but one day I will conquer this programming world. It did lead me to the command 'stty -g -F /dev/ttyS0', which prints a string you can then send back to stty on the CLI. So I ran that while minicom was running, and have taken the string, I'll add it to a script to set the serial port before loading the Java program.

So problem solved, thanks guys. When I'm all done and dusted (end of the week I hope), I'll post back some screenies and pics of the finished "product"

[savage]

As promised, screenies. I've done it as a kind of "data sheet" to show others who've also helped with other aspects of it.

The Machine

Before you view it, the "machine" being referenced is an automated counting and packaging machine, it has bowls, which counts and vibrates screws into a conveyor where they travel to the bagger. They drop into a bag sealed on 3 sides, when that bag is done, the jaws close, heat sealing the bag, and cutting it, the jaws then drop to pull the plastic through for the next bag, release the bag and return to the top, waiting for the next drop from the conveyor.

The Problem

The problem with this "automated" machine is it's vertical seal sometimes rolls off, and the contents of each bag are thrown onto the floor, so we have to sit and watch it, not fun, and it's costing us money.

The Solution

Fedora + Serial Cable + Tilt Sensor + Webcam + (ducks) Windows Mobile PDA

Screen shots and more detailed explanation:
See here, somethings up with image tags!

Thanks again for your help guys.