Serial Communications - The long, boring, version.

The intent here is to help you get two boxes to communicate. We will look at this from two perspectives, software and hardware.

Software Perspective

Theoretically, communication via a serial connection is simple. In most cases, all you must do is get both ends to agree  on line speeds, flow control, protocols, and so on. The actual numbers and options aren't usually as important  as having both ends agree on what they are.

In practice, it's more complex since you often have incomplete information and don't know what values are being used.

Hello? Hello?

In a PC, some critical hardware options are reflected in the software. Usually these are line speed, number of data and stop bits, and parity. These settings are roughly analogous to setting frequencies or channels on two-way radios.

The line speed setting determines how fast characters are sent over the line. Usually, this will be a value between 110 and 115,200 bits per second - divide by 10 to get approximate characters per second - and is often called a Baud rate which for our purposes means the same thing. Both the PC and the CNC control need to agree on line speed. Obviously, the faster settings are the most desirable but there will be limiting factors. Either the PC or CNC may not be fast enough to support the higher speeds, or the line quality may not be good enough. Most lashups will handle at least 4800 bps so it's usually a good place to start - you can work upwards from there. You'll know when the limit has been exceeded because the software will start reporting errors or, worse yet, some data will get dropped and the machine tool will crash. (Rule #1 of DNC - the dropped character will never be a 10ths digit).

The parity option applies to an error checking method commonly used when storing or transmitting data. The value here will be "even", "odd",  "none", "space", or "mark". If set to even, the sender will make sure that all outgoing characters have an even number of "one" bits and the receiver will count the bits in each character and trigger an error if the count isn't even. The sender simply tacks an additional bit on the end of each character - a zero or a one - to make the count even or odd. This last bit is called a parity bit. (Rule #2 of DNC - a hardware problem that causes bits to be reversed will always reverse an even number of bits within a character, thus assuring that parity is maintained and the error masked). The none option means that there's no parity checking. This is fine as long as other methods are used. Most PC memory is not parity checked these days even if you buy "parity memory". Two other rare possibilities are space and mark. Space means that all parity bits are set to 0, mark means they're all set to 1. When setting up a system, the parity settings should agree.

Data bits. This is the number of bits representing data (a character) in the character code you are using. 5 through 8 are possible, 7 or 8 most likely. Both ends should agree.

Stop bits. This is the number of bits sent following transmission of a character and parity bit, if any. Valid numbers are 1, 1.5, or 2.  The most common value is 1. You will only see 1.5 if you are using 5 data bits which is unlikely. Both ends must agree on this value.

The most common character code setups are probably 8 data bits, 1 stop bit, no parity and 7 data bits, 1 stop bit, even parity.

Stop. Go - No, stop.

This section covers flow control (sometimes called handshaking) settings. Flow control is roughly analogous to railroad signal systems and can be implemented in hardware or via software. Although it's possible to use both, it is seldom done. While it is possible to avoid using any flow control at all for simple data transfers (PC to CNC memory, for example) it is not reasonable to avoid it when drip feeding a CNC. Flow control allows either end to control the rate at which it receives data and is needed when a data flow might need to be interrupted. If you are drip feeding a CNC and a block causes an X-axis move of 8 inches at 15 ipm for example, the CNC is likely to want to stop receiving data for a while.

Software flow control is usually called XOn/XOff flow control. It assigns special meaning to two characters that are called the "stop" character and the "start" character - usually the ASCII characters 19 and 17 which are called XOff and XOn. Whenever the sender receives an XOff, it stops sending data and waits for an XOn to resume. When the receiver needs to stop receiving data to empty a buffer or wait for a machine tool to complete a task, it sends an XOff. When it's ready again, it sends an XOn. Hence, a CNC being drip fed one block at a time might send an XOff after most of the motion related blocks it receives.

Some download procedures require the CNC operator to enter a control-Q (^Q) to start the download. Control-Q is an ASCII 17 character, an XOn. The operator can then interrupt data flow by manually entering a control-S which is an ASCII 19, or XOff. 

Using software flow control, only three lines are necessary in the serial cable - send, receive, and ground (or pins 2, 3 , and 7 on a 25 pin connector).

Hardware flow control is often called hardware handshaking, and uses lines in the serial cable rather than start and stop characters to control data flow. This is where RTS, CTS, DTR, and all that other mysterious stuff described in the RS-232 specification is used.

Pins 2, 3, 4, 5, 6, 7, 8, and 20 on a 25 pin connector are usually used if when using hardware flow control.

When the DNC program connects to a CNC, it will turn Data Terminal Ready (DTR) on to indicate that it is running. It will look for a corresponding Data Set Ready (DSR) from the CNC (which is called "DTR" at the CNC end. See the connection?) These two lines are not used for most hardware flow control and stay on for the duration.

The program and the CNC then use the Request to Send (RTS) and Clear to Send (CTS) lines to control data flow, much as they would use XOn and XOff in software flow control.

When setting up your software, it's important that both ends agree on how flow control will be done. Generally, some sort of control is required unless you are certain that the receiver can receive faster than the sender can possibly send. The only time this can happen is if you are NOT drip feeding, but are sending a program to CNC memory using a very slow line speed. In a pinch, you can usually use 300bps line speed and then check the program in the CNC itself very carefully. It is possible to lose data with no indication using this technique. A variation of this is to have the sender insert a short delay between blocks to allow the receiver time to do its processing. 

Protocols

A protocol is an agreement by the PC and the CNC on what format your data will have. Two common protocols used for DNC are "ASCII" and Xmodem. "ASCII" isn't really a defined protocol so much as it's the absence of one.

Most CNC's use ASCII which means that they may well make their own rules regarding things like how end-of-data is denoted. Some scan the incoming data to look for an M30 or a percent sign or some other characters, and some look for an ASCII control character like a control-Z.  When transmitting from the CNC to the PC, some DNC programs simply have to assume that when data stops coming - that's the end! There are generally no error checking methods available for ASCII transfers except for parity checking.

Another common problem is that controllers don't agree on how to end a block. Some use a carriage return character (CR), some use a line feed (LF), and some use the pair (CRLF). This goes way back to the days of punched tape and the typewriter-like devices used to create them. CR and LF did exactly what their names imply, so they came into common use as end of block characters so that a tape could be listed on the machine. If you have problems with blank lines being inserted during program transfers, try some other method of specifying the line ends - usually called end-of-block (EOB) characters. A dollar sign ($) was commonly used as an EOB character for years and you may encounter this also.

Xmodem is fairly well defined, and has been used since 1977 as a file transfer protocol between computers. Xmodem formats the data into blocks of 128 characters each and a basic error checking method using checksums. The receiver must respond after each block with a positive acknowledgement of receipt. Xmodem transfers are usually reliable but some problems can occur at the end of program transfers if the PC and CNC don't agree on what the last block should look like. Since all Xmodem blocks are 128 characters, unless your NC program size is a multiple of 128, the sender will fill the last block with "something" to make 128. Not all CNC's and DNC programs agree on what the "something" is, and this causes problems.

There are actually four versions of Xmodem in use. "Xmodem" is described above, "Xmodem CRC" is similar but with better error checking, and "Xmodem 1K" which uses blocks of 1024 characters and better error checking. "Xmodem 1KG" is not used without special error correcting hardware.

Tips regarding Xmodem

You can not use Xon / Xoff flow control with Xmodem transfers.

The receiver initiates the file transfer - the sender should be started first so that it's ready when needed. The receiver will retry for a limited number of times (usually 10) before abandoning the effort.

Vendors are often not specific on which version of Xmodem they are using. You can tell which method is in use using the DNC terminal function or a basic comm program. Open the terminal window and open the port. Then start an Xmodem receive operation at the machine tool controller. Watch the terminal window. If the PC receives a <NAK>, the controller is using Xmodem. If it receives a 'C', the control is using Xmodem CRC or Xmodem 1K.

You can tell if Xmodem CRC or Xmodem 1K is being used by trying to send data from the control to the PC. Start the controller and then send a 'C' in terminal mode from the PC. If the block of data that the PC receives starts with an <STX>, then the control is sending via Xmodem 1K.

In most cases, Xmodem transfers can be performed even if the receiver requested CRC or 1K.

Hardware Perspective

Good news, bad news, here. The good news is that there's not a lot to consider - you need two connectors with unbroken wires between them, and a plug on each device to connect to. The bad news is that, until you get this right, you can't even get started on getting the rest working.

The Plugs (aka Connectors)

Two types of connectors are commonly used - 9 pin and 25 pin. There are also hardened variations but functionally they are the same. Either the 9 or 25 pin versions support all hardware and software handshaking options. Officially, they're called DB25 and DB9 - guess which is which.

Sex

Not sex, gender. The serial ports on most devices usually have male plugs so it's likely that your cables will have female ends. You can get gender changers almost anywhere these days if necessary.

Eliminating what you don't have to start with

If your serial cable is wired straight through - pin 1 to pin 1, pin2 to pin 2, and so on, then you will probably need a "modem eliminator". The reason for this is simple - this whole "RS-232" business was designed to connect devices via analog phone lines. A computer would send a character out on pin 2 (the "send" line), it would go to a modem that converted it to an analog signal (basically a "beep"), another modem would hear it and pass it on using pin 3 which was the receiving device's receive line. If there's no modem involved, then you need another way to get the signal from pin 2 to pin 3. This also applies to some of the other signals. So, you either need a cable with its wires crossed, or you need a modem eliminator.

The wiring diagram below shows  common 25 and 9 pin cables used for DNC. The shaded area shows those pins that are needed for minimum function - and with no hardware handshaking. The outer numeric columns refer to pin numbers in DB9 connectors and the inner numeric columns to pin numbers in DB25 connectors. This configuration is used without a modem eliminator.

There are other possibilities depending on the specific hardware involved. Many controllers accommodate either straight through or crossed wire cable configurations based on settings within the controller - most controller manuals cover this. Many of us resist "looking it up" but you'll save lots of time in the case if you do.

If you have problems with cabling, you should - without delay - get a "Breakout box". They're not expensive, generally under $40, and are invaluable in solving problems in this area.