Tech problem: RS232 serial communication.

[RobbieThe1st]

My problem is this:
I need a program which will take an ASCII text file and send it over an RS232 serial port at a settable baud rate, parity type, and handshaking type(I need XON/XOFF support).

All the characters that need to be sent are in the text file, so it *should* be simple enough to do.

In case you are wondering, this is for a CNC application - I need to be able to send a text file of G-code over an RS232 port(Note: its going to be a usb->serial adapter, but that shouldn't matter too much with what I am doing here).

Any suggestions?


-RobbieThe1st

[llearch n'n'daCorna]

... what's wrong with the tried and trusted zmodem or kermit applications?

[Tapewolf]

What platform?  Under win32, Hyperterminal is pretty good for that kind of thing.

[Alondro]

*Charles attempts to be helpful*   

*Charles reads problem*   

*Charles dies from his lack of computer skills*   

[Cogidubnus]

What Alondro said, yeah.

What scares me more is that we have people on this forum who can answer such arcane queries off the cuff.

[llearch n'n'daCorna]

What scares me more is that we have people on this forum who can answer such arcane queries off the cuff.

Heh. I hope you're not talking about me - I just provided some obvious solutions that he should already know about, but didn't provide enough information to discount...

[Cogidubnus]

What scares me more is that we have people on this forum who can answer such arcane queries off the cuff.

Heh. I hope you're not talking about me - I just provided some obvious solutions that he should already know about, but didn't provide enough information to discount...

The only Kermit I am aware of sings songs about rainbows. I am similarly unaware of hyperterminal or zmodem, although likely this speaks more to my ignorance than anything else.

[llearch n'n'daCorna]

Heh. Kermit is a file transfer program that was named after the green frog. zmodem is a protocol, one of several that kermit speaks, but also an application that speaks, obviously, that protocol.

Other than that, there's a multitude of ways you can send the data. If nothing else, you could cat it into the serial port on one end, and dump it out of the other end, although not quite in that order, and it wouldn't do anything about making sure that what you put in was what you got out...

[Cogidubnus]

Heh. Kermit is a file transfer program that was named after the green frog. zmodem is a protocol, one of several that kermit speaks, but also an application that speaks, obviously, that protocol.

Other than that, there's a multitude of ways you can send the data. If nothing else, you could cat it into the serial port on one end, and dump it out of the other end, although not quite in that order, and it wouldn't do anything about making sure that what you put in was what you got out...

I'm beginning to suspect my problem was reading a thread that started with "Serial Ports".

Although I do understand what you're saying about Kermit and its file-transferring properties. I learned something besides how to tell different rocks apart today, hooray!

[Tapewolf]

What scares me more is that we have people on this forum who can answer such arcane queries off the cuff.

If you wrote serial printer and GPS driver modules as part of your job, you'd know the answers too 

[Ryudo Lee]

If it's straight machine to machine, I remember there was an old DOS program that I used to use back in the days of Win3.1 called FastLinx (abbreviated to FX) which did nothing but file transfers over serial ports.  I remember it working with Win98, so I'm not 100% sure it would work with XP or Vista, but it wouldn't hurt to try.

[Azlan]

I just thought I would chime in and say I had much of the same to say as those above, but I only noticed this thread at this very moment... really.

[RobbieThe1st]

First off, I want to thank you all for your help.

I hesitated until now to post because I wanted to try out some of this help, and that can only be done at cirtain times during the week when I am in class, and not during lecture times, and such, so until Today I didn't have much chance to do anything.

To explain:
The machine in question is a $30,000 Haas CNC Toolroom Milling Machine, and fairly new(last couple of years). With the current set of options, the only way to get data to and from this machine is by the use of a serial port. On the machine side we have a DB25(why DB25? I dunno - I don't think any of the pins not in the DB9 connector are even connected internally) female port. I currently have my laptop connected to it via the use of a RadioShack $20 USB-Serial adapter cable, which has a DB9 male connector, an adapter from DB9 female to DB25 male, and a DB25 female to DB25 male "Null-modem" adapter.

With this setup, I am running 115200 baud, even parity, 1 stop bits, and software(Xon/Xoff) flow control.

I have a piece of shareware currently on my laptop called "DNC Precision" which... works. At least, from a serial perspective.

I tried HyperTerminal, and got it set up properly, but the data isn't getting sent properly - The machine isn't seeing the start transmission character, and perhaps nothing else either. I figure its a settings issue.

I also installed Kermit, and it looks promising, but I haven't actually tried it yet.

Thats just where things stand for me now.
Thanks again for your input.


-RobbieThe1st

[Tapewolf]

With this setup, I am running 115200 baud, even parity, 1 stop bits, and software(Xon/Xoff) flow control.

You're absolutely sure this is what it's expecting?  With the printers, this is always the hard bit and the correct settings are never bloody documented.  I'd try 9600 to start with if you're not sure.

[Tezkat]

The thing about kermit, zmodem, etc... they're all protocols designed to tranfer data to and from a terminal server. I doubt you need any of those. Pretty much any terminal program should work here, but what you probably want is DNC software designed to talk to the CNC on your mill. It might help to look up the documentation to see what the settings are supposed to be.

[RobbieThe1st]

First off, I *did* get it working with X settings an Y software. I just couldn't get Z software working with it.

@Tape: This CNC machine can be set in software from 9800-115200 baud, multiple types of flow control, settings for parity - Its very nice.

I just got HyperTerminal working with it - What fixed it was checking "Send line ends with line feeds" under File>Properties, Settings tab, ASCII Setup dialog.
It *should* have worked without it because my input text file had line breaks of 13h,10h, and that was what the machine is set to look for(Yea, you can set that too! )

So, everything is working now. Thanks, all.

[superluser]

I just got HyperTerminal working with it - What fixed it was checking "Send line ends with line feeds" under File>Properties, Settings tab, ASCII Setup dialog.
It *should* have worked without it because my input text file had line breaks of 13h,10h, and that was what the machine is set to look for(Yea, you can set that too! )

Ah.  That's UNIX file format, not DOS.

[llearch n'n'daCorna]

... And translating on the fly to DOS in transit.

[RobbieThe1st]

*blink* Huh?

Last I heard, Windows/DOS line ends were CR & LF, Macintosh ones were only CR, and Unix ones were LF only.

Now, I looked in a hex editor and indeed, at the end of each file-line were the characters 13d and 10d(or 0Dh 0Ah). This appears correct, so was HyperTerminal stripping the line-end characters? Or, am I completely off here?


-RobbieThe1st

[superluser]

Now, I looked in a hex editor and indeed, at the end of each file-line were the characters 13d and 10d(or 0Dh 0Ah). This appears correct, so was HyperTerminal stripping the line-end characters? Or, am I completely off here?

It's working; don't mess with it.

[RobbieThe1st]

Now, I looked in a hex editor and indeed, at the end of each file-line were the characters 13d and 10d(or 0Dh 0Ah). This appears correct, so was HyperTerminal stripping the line-end characters? Or, am I completely off here?

It's working; don't mess with it.

But... But... 

Yea, it works, and fine... so, I have a good, solid, fallback point. Now, I want to know why - Because that's how I do things.


-RobbieThe1st

[superluser]

But... But... 

Yea, it works, and fine... so, I have a good, solid, fallback point. Now, I want to know why - Because that's how I do things.

Depending on how the protocol works, it's pretty common to convert from DOS to UNIX or Mac or the other way around, even if the program in question is being run on a DOS-format based system.

FTP works this way, for example.  If you send in ASCII mode, it expects lines to be terminated with CRLF, in accordance with prophecy (or, in some areas, with the NVT standard).  In EBCDIC format, it expects NL (*PLEASE* tell me you're not using EBCDIC).  When it is retrieved for use on a UNIX system, however, the FTP program will strip all the CR characters.

The NVT standard requires CRLF, but Hyperterminal probably keeps that option in order to be compatible with other standards.  Why it isn't checked by default, I can't say.  Maybe the person who was using it before you needed a protocol which uses bare LFs and left the configuration that way.  In which case, I might leave a note that you changed the configuration.

[RobbieThe1st]

That makes sense. Thank you very much.

Actually, I am pretty sure its unchecked by default - My computer had it unchecked, and this was the first time HyperTerminal had ever been run. Same with every single computer I have checked, so I figure that its unchecked by default(And, judging by the "enter area code" dialog coming up the first time I ran it, none of these have ever had HyperTerminal run on them before).


-RobbieThe1st