I'm trying (unsuccessfully so far) to communicate with an antique CNC machine tool. It's a 1981 lathe, with an RS232 port. I have used the serial connection on the machine recently from a Windows laptop. That Windows machine has gone belly-up, and as I choose not to purchase any further Microsoft products, my best option right now for MANY off-topic reasons is to use ttyS0 on my (also antique) Thinkpad. The BIOS serial test comes back OK, and there IS a +10 volt signal on DTR (pin 4) during that test. (I'm pretty sure it was pin 4.) So..the laptop BIOS suggests to me that the serial port is present and functional, but after I boot into the system, there seems to be no actual connection to the port.
The output of 'dmesg | grep tty' is '00:03 ttyS0 at I/O 0x3f8 (irq = 4) is a 16550' which makes perfect sense, but neither minicom nor cutecom seem to be able to actually get any output to the physical pins. A command like 'cat foo.nc | /dev/ttyS0' also gives me no response.
The tutorials and FAQs I've read thus far are all intent on having me configure the serial port with a getty - so that I can log into the system from the outside through the serial port, OR set up some other communication protocol to allow two way communications. What I require is far simpler - I just need to put ASCII data on the serial port with real physical hardware flow control.
I'm pretty sure that what I am missing is some intermediate step - ie. enabling /dev/ttyS0 with setserial or ifconfig such that the port is actually available to the machine. Both minicom and cutecom ACT as if they are sending information to ttyS0 - but the multimeter shows that there are no voltages present on any pins (relative to signal ground) while they are doing their things.(Under hardware or software flow control.)
I've got nothing against configuring getty or minicom and using them, so long as they output pure RS232 compliant ASCII on the serial port...I'm just getting confused with their configuration, and that of the serial port itself.

The problem is not that I have a bogus null modem cable - I'm using a straight up DB9 cable, that will eventually be soldered up to the appropriate pins in the DB25 on the machine tool end. (When I get past this hurdle.)

Any help pointing me down the right path is greatly appreciated.

And, no, a USB to serial converter is NOT an option. Unless you can personally guarantee that the drivers and hardware will install without headaches, and survive in an electrically noisy environment. Trust me, a TIG welder with high frequency arc stabilization is pure murder on unshielded computer hardware.

Thanks.

I am really sure that you can do that with minicom, I have a couple Slackware 12.1 boxes that use minicom this very way. Unfortunately both of those at at a location inaccessible to me right now.

I also use a USB/serial converter with minicom on another Slackware 12.1 machine that has no RS-232 ports and it sets up and works perfectly. Not sure about the welding environment, but if you use a properly shielded cable on both ends (Computer to adapter and adapter to CNC) it should work as well as straight 232, maybe extend the shield from one end around the converter itself. As long as you don't hit the cable with the arc! ;-)

That said, if you have a functioning serial port there is no reason to use the USB adapter route.

It has been a couple of years since I actually configured minicom, but there should be no mystery to it as long as you identify the correct port. I'll see if I have archived any notes on doing that here.

Welcome to LQ --

Well, for a start, that command should be 'cat foo.nc > /dev/ttyS0'.

You should either be using root (have you tried it? does it work?) or you should have added your username to the correct group -- for Slackware 12.0 up to 12.2 this should be 'uucp' (usermod -a -G uucp <yourusername>). For reference, in Slackware 13.0 and later the correct group is 'dialout'.

There was a minicom config bug in Slackware 13.37 (see this thread) but this should not affect you. If you configure minicom right, and if you use root or the correct group, it should work.

Edit: By the way, if you are using hardware flow control, you do understand that the other end must be asserting CTS before your Slackware box can send anything? It can't send anything if you only have a multimeter on the port. Just checking...

The place to start. http://www.tldp.org/HOWTO/Serial-HOWTO.html

I'll say the the IBM's were very good and usable on some older linux for serial. I doubt you need a load or resistor to get a 16550 to drive.

It may be that the touchpad is serial and you have an external port as number 2(1).

Might look at this. http://www.cyberciti.biz/hardware/5-...erial-console/


I'd consider booting to an old Knoppix 3.x cd. I guess it could be that newer distro's may have some issue since serial is being phased out.

I'd test with a serial loopback and see if you can echo to terminal also.

I was able to locate some notes from when I configured my last minicom setup.

They only indicate an error free setup, which is my recollection.

The only new bit I can add is setserial, see the man page, but if you have not yet used it you can get and set the serial port parameters and state info which should let you tell whether the device is actually working. If you use it to set up the port you should then be able to dump a file to it.

For minicom, use minicom -s to set up the initial configuration. Select "Serial port setup" and take it from there. /dev/ttyS0 is probably the right device.

As mentioned by others, your user will need to be a member of the right group(s) - uucp sounds right. But if you have root access and are not afraid of an attack launched by the CNC machine, you might try to get it going as root then sort permissions.

Do you need to simply dump a file to the port, or will you need interactive communications with it?

A lesson I learned the hard way many years ago is that the cable must implement the DCD signal line. This is required on *nix systems, but is not required on Windows systems. Many RS232 cables supplied with Windows systems did not implement DCD.

1 members found this post helpful.

Wow! That is a loud bell ringer! I am suddenly having flashbacks of discovering that very fact, and soldering jumpers on DB9s to provide it! You are absolutely correct!

Foremost - thanks to all for taking the time to respond.

-55020
You are correct, I meant > not |. And, yes, I am trying everything as root. If I can make things work as root, then I will sort out the groups and permissions to allow me to use everything as a user. But that will be my next dumb question.

-allend and astrogeek
I understood in theory, but not in practice, that the serial port on the laptop needs to see the CTS signal before it will do anything. The documentation I have for the lathe suggests jumpering the DTR, DSR and DCD pins together, so that machine always sees an asserted state on DSR and DCD when trying to send or receive. This struck me as being a crude end run around the whole idea of 'hardware' control, but it worked for my Windows box. Now I know why. Thanks. When I get back to the shop I will get the cabling properly squared away. And, yes, I actually need two way communication, but it is implemented on the machine tool hardware as a VERY dumb terminal. All it can do is select a file, assert DTR, wait for DSR and then begin sending. There is no way to use any kind of terminal emulation program or select any kind of protocol on the machine tool side - hence my aversion to terminal emulation. Configuration makes perfect sense on the laptop side, but not on the machine side.

-jefro Thanks for the cyberciti.biz link. That will be helpful.

Thanks again - I'll let you know how everything works out.

Only 3 pins are actually needed to communicate, send, receive and ground.

All the other pins generally get in the way.

One way to start testing is to use a rs-232 loopback connector which is placed on the
end of the cable, the other end being plugged into the serial port.

It will mirror back all characters typed in giving a quick test of the serial port and the cable.

After the loopback test works on one machine, then if possible test the other machine with a loop back connector.


If two machines connected to each other try and send and receive on the exact same pins so it does not work. (If machine A sends on pin 2 and machine B sends on pin 2 then both machines are not listening to each other.)

In this case they need null modem connector in the middle to switch the send and receive pins.

So what happens when you have an intelligent port driver that checks whether the DCD line is asserted and refuses to send when it assumes that there is no device connected because DCD is not asserted?
In my experience the short answer is SFA.

I just installed Slackware on a brand new motherboard with serial port and decided to test it out.

I plugged in my cable and loopback, went into minicom, but could not get /dev/ttyS0 to work.

Until I did this:

1 members found this post helpful.

Good point comet.berkeley!

I had not remembered rc.serial was even there, but the kernel module must be loaded before you can use the ports!

So to the OP, before you start again, as root...

After that as long as it is executable it will load on future boots.

OK - I did the chmod on rc.serial - it's properly executable now, I rebooted and rechecked; it's still executable. So far, so good. The command ' sh /etc/rs.d/rc.serial start ' responds with the same message as setserial -g /dev/ttyS0.

Then I proceeded to try the serial loopback test per http://www.ni.com/white-paper/3450/en/ . Still no echo of typed characters, and both minicom and cutecom seem to be sending data into the void. I'm testing on two laptops - a TP600 and a 770Z.

Just made the quick check of trying the loopback on my desktop, and seems to work just fine.

Seriously, everyone, I really appreciate the effort.

Please compare the wiring of the DB9 loopback test plug shown in your link http://www.ni.com/white-paper/3450/en/ with that shown at this link http://airborn.com.au/serial/rs232.html
Notice how pins 1,4 and 6 are tied in the latter where as only pins 4 and 6 are tied in the former. And what is pin 1? Isn't that the DCD I keep banging on about?

Hey guys,

This is off topic a bit, but I figured since everyone I need to talk to has already chimed in on this one... I'm trying to replace Windows XP (which is EOL on a Dell Latitude c600) with Slackware 14.1. Literally the only 4 things I care about are : Ability to connect to Cisco IOS via Serial (hyperterminal for M$), Java, Firefox, and Teamviewer.

Is all serial activity this difficult on Linux? I have previous experience with Slackware, I like it because it's essentially unbreakable from an EU's position. Please feel free to PM me with responses so as not to hijack the OP's thread. Also does anyone know for sure if Cisco supplied RJ-45 (console) to RS-232 has the special connectors required for *nix you guys were mentioning?

Thank you,

EvilWoodchuck