Okuma America Corporation

The Complete Handbook

Of

Serial Communications

Author: Mike Breitkreutz (Okuma America Corporation.)

Pub. # ABC1000 April 1st, 1998
 Preface

This handbook will attempt to give the user a better understanding of Serial
Communications as it pertains to different Okuma controls on the market today, as well
as controls which are no longer being built but are abundant in the field. Currently, there
is no such existing document from Okuma that compiles such data in an accurate and
easy-to-follow instruction booklet available to the general public.

The data found in this booklet has been tested to the best of my abilities using many
different versions of Okuma NC software and different control types. The instructions
contained here are meant to help the Okuma user establish a serial data link between
many Okuma controls and the common PC. Due to the ever-changing PC-side
communication software and hardware, this booklet is only intended to be a guide for
establishing a link. It is impractical to state that the parameter settings, cable
configurations and other factors contained in the following text will always prove effective
while interfacing to such a wide variety of PC’s and other serial communication devices
on the market today.

I hope that this data will help our Okuma distributors and customers effectively link
several models of Okuma controls to PC’s, as well as other external serial devices on the
market today.

Mike Breitkreutz (OSP Software Service Engineer)

Okuma America Corporation

2
Section I. Understanding Serial Communications (RS-232C)

The RS-232 is a standard defined by the Electronic Industries

Association (EIA) in the U.S. for Serial data transfer. It is a data
Communication interface which specifies the connector, pin number
assignments, control signals and signal characteristics.

RS-232 was basically designed to allow computing devices, called DTE’s

(Data Terminal Equipment), to talk to communications devices, called
DCE’s (Data Circuit-terminating Equipment). RS-232 allows DTE’s to talk
to DCE’s by using a standardized DB-25 connector. Male DB-25’s go on the
DTE’s (PC Computer, etc.) and female DB-25’s go on the DCE’s (Okuma
controls).

Note: Today’s PC’s commonly incorporate a male 9-pin connector.

Pinouts and 25 to 9-pin conversions will be discussed in a later
section.

The OSP series controls contain a few slight differences from the
standard RS-232-C specification.

Individual Data Bits:

Serial Communications can be though of as a “stream” of data being sent on a single

data communication line. A “bit” is a logical “0” or “1” which equates to a
given voltage level. In the case of the data communications system referred to as “RS-
232-C”, 0 represents a voltage level of approximately +3 volts, and 1 represents a
voltage level of approximately -3 volts. The following example demonstrates a common
serial data structure:

Odd/Even Parity bit

0 1 2 3 4 5 6 7 P
Stop Bits (1 or 2)

Extra Parity Bit (Optional)

Data Bits (8)

Start Bit (1)

3
In the example above, each “data bit” is actually part of an 8-bit “word” referred to as a
“byte”. One byte, makes up a single ASCII character. The “start bit” and “stop bit(s)” are
used in serial communications to “enclose” an 8-bit character inside of two bits that tag
where the character starts and stops. This data structure from start bit to stop bit is
referred to as a character frame.

The “extra parity bit” shown above is seldom used in serial communications but the
Okuma control allows for this bit (changeable by parameter setting.) I have yet to see
any communication device that necessitates this 9th bit.

Parity:

The first real-world error correction system in general use is called parity.
The idea with parity is to add an extra bit that incorporates redundancy.
In the following example, I’ll use even parity on a seven-bit ASCII character
Code.

Example: In ASCII, the upper-case character “C” is equivalent to a HEX value

of 43. The following string of bits can represent this:

$ 43 = 1 1 0 0 0 0 1 Least Significant Bit (LSB) to Most Significant Bit

(MSB).

Applying even parity to this data bit stream, the communication device adds a
Logical 1 as the 8th bit, next to the MSB as shown below:

This binary sequence has an “odd” number of ones.

Start Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Stop
Bit Bit

1 1 0 0 0 0 1 1

Adding a “1” keeps the number of “1”s even in the 8-bit word.

Therefore, bit 7 in this 8-bit word becomes a logical “1”. This forces the hex value to
change from $ 43 to $ C3.

4
The idea of even parity is that the sending device looks at the seven bits
before putting them over the serial communication line, and adds the 8 th bit.
The value of the 8th bit is a one or a zero such that after the 8th bit is added,
the total number of bits in the 8-bit word will be even.

Now, the receiver must be expecting even parity and seven data bits. Assuming
that is does, the receiver then looks at the 8 data bits and checks to see if there
is an even number of ones. There is an even number of ones so the receiver
assumes that the data was received without error, and strips off the parity bit.

Note: It can be seen from the above example that parity checking only allows
for detecting an odd number of bit errors. An even number of bit errors
will restore parity and go undetected!

Baud Rate:

This term refers to the number of bits transmitted per second on the serial line.
Keep in mind that one character can be associated with a start bit, 8 data bits
And (1 or 2) stop bits. This equates to the following:

A baud rate of 9600 bits/sec. would equal approximately 960 ASCII characters being
sent per second on a given serial transmission line.
Data Transmission Range:

Be careful with extremely long and improperly shielded communication cables. The EIA
Standard was originally defined to require impedance parameters to allow accurate data
transfer over a 50-ft. cable. However, I have witnessed accurate communications
between PC’s and Okuma controls with an excess of 200-ft. cables. Okuma cannot be
responsible for such conditions when “noise” or extremely high impedance result in
inaccurate data transfer.

Section II. Protocol and Signal Description

Data Transfer Methods (Flow Control):

I. Software Handshake:

This method of data transfer uses control codes “sent out from the Okuma” control to
start and stop the transfer of serial data. Okuma refers to these control codes as DC-
Codes. Often, this type of data transfer is referred to as Xon/Xoff in the PC world. With
this type of serial communication, the control codes define the buffering of data. No
voltage signals are used for such buffering and the “null modem” cable is used to link the
Okuma control with external devices. This will be explained in detail later.

II. Hardware Handshake:

5
This method of data transfer uses voltage signals to control the start and stop of serial
data between two devices. A different cable is required to link the Okuma with external
devices as opposed to the “null modem” cable used with the Software Handshake
protocol. Again, this will be explained in a later section.

Signal Descriptions:

There are 10 important asynchronous signals in RS-232-C communications. Okuma

incorporates an 11th signal that is not a standard but is required in certain applications. It
is important to understand that either one side (Okuma) or another (PC) controls each
signal. Below is an explanation of these 11 signals:

Description Pin # (25-pin) Pin # (9-pin) From Abbreviation

Data Leads

Transmit Data 2 3 DTE TD or TxD

Receive Data 3 2 DCE RD or RxD

Power-On Indicator Leads

Data Set Ready 6 6 DCE DSR

Data Terminal Ready 20 4 DTE DTR

Leads that announce that an outside event has taken place

Data Carrier Detect 8 1 DCE CD

Ring Indicator 22 9 DCE RI

Ready to Send/Receive Handshake Leads

Request to Send 4 7 DTE RTS

Clear to Send 5 8 DCE CTS

Register 1 (OKUMA) 9 ---- DTE RG1

Ground Leads

Signal Ground 7 5 ---- SG

Protective Ground 1 ---- ---- FG

6
Sequence of Events for a Normal RS-232-C Session:

1. Both devices are powered up. The DTE powers up line 20 (DTR). The DCE
powers up line 6 (DSR). Most serial devices will not communicate further
until these lines are activated. The DTE waits to see a signal on line 6, and
the DCE wants to see a signal on line 20. Therefore, pins 6 and 20 are re-
referred to as “equipment check” signals. These lines are often “jumped”
together on each side (DTE and DCE) so that both devices will “always” be
ready on power up.

2. In the case of communications where modems are used, the modems must
exchange carriers (the high pitched whine you hear when modems connect.)
This is done when the modem (DCE) tells the terminal (DTE) to connect by
using pin 8 (CD). This signal is not necessary in Okuma-to-PC connections
since no modem is being used.

3. The DTE asks the DCE if it is ready by activating pin #4 (RTS). The DCE
responds by activating pin #5 (CTS). Now the handshake process is
complete. Pins #4 and #5 are “flow control” signals.

4. Data is exchanged by the DTE passing information “data bits” to the DCE
on pin#2 (TD). The DCE passes information back to the DTE on pin #3
(RD).

Flow Control (Software Handshake):

Back to the subject of flow control as mentioned briefly above. Flow control
can be implemented either in software or hardware. In the case of “software” flow
control, the handshaking signals (RTS and CTS) as described above are jumped
together. The “equipment check signals” (DTR and DSR) are also jumped together so
that both devices are “ready” at power up.

With this type of configuration, both devices are always satisfied by signal status.
Therefore, handshaking will be controlled by ASCII control codes sent from the Okuma
control to the PC.

Timing Chart: (Read Operation PC Okuma)

DSR

Xon Xoff

TxD (Data) DC1 DC3

RxD (receive data from PC) data data data data data data

7
The Okuma sends the DC1 ASCII control code (Xon) to the PC. The PC, in response to
the receipt of the DC1, begins transmitting serial data to the Okuma. As the Okuma
buffers this data, it sends the DC3 (Xoff) to the PC. Upon receipt of the DC3, the PC
interrupts transmission of the data to the Okuma.

As the Okuma processes this buffered data, it sends the DC1 again and the process is
repeated throughout the entire communication process.

Note #1: The Okuma can process 256 characters between sending DC codes.
Note #2: The PC must stop transmission within 100 characters
after receiving the DC3 from the Okuma. If this doesn’t happen, the
Okuma will receive a buffer overflow error.
Note #3: After the Okuma receives the last character of data, it sends the
DC3 code one last time to the PC, which concludes data transfer.

Timing Chart: (Punch Operation Okuma PC )

DSR

CTS

TxD DC2 Data Data Data Data Data Data Data

The Okuma sends the DC2 code preceding the first character of transmitted
data. When the CTS signal is high, the Okuma continuously sends this data.
This CTS signal is often jumped to the RTS on the Okuma side. Therefore, CTS is
always high and data transfer to the PC is not interrupted. Most PC’s can buffer this
data with no problem.

After transmitting all data, the Okuma sends the DC4 code.

Here is a good example of a cable configuration to use when connecting an

Okuma control to a PC while incorporating “software” flow control:

8
Cable Configuration (Software Handshake):

25-Pin DB-25 25-Pin DB-25

Connector (Okuma) Connector (PC)

FG 1 shielding
TD 2 3 RD
RD 3 2 TD
RTS 4 4 RTS
CTS 5 5 CTS
DSR 6 6 DSR
DTR 20 20 DTR
SG 7 7 SG

Notice that on this cable configuration, the only signals connected by the two
devices are the Transmit Data (TD), Receive Data (RD) and Signal Ground (SG).
These are the only required signals to allow effective data transfer to take
place. All other signals are jumped high which give both devices there required
status to allow communications.

Note: Pin #1 (FG) is not a necessary connection for effective communications.

However, this wire is often connected (grounded) to the Frame Ground of
one communicating device such as the Okuma control. It is also good
practice to connect this signal to the shielding which resides inside any
quality cable used in RS-232-C connections. This has the effect of
shielding the signal wires inside of this cable from any external noise
which may be introduced by various environmental factors.

Flow Control (Hardware Handshake):

As with the “software” handshake, the “equipment check signals” (DTR and DSR) are
jumped together so that both devices are “ready” at power up.

However, in the case of “hardware” flow control, the handshaking signals (RTS and CTS)
are normally used to communicate a ready status to send/receive data between the two
communicating devices. Under this condition, the DTE asks the DCE if it is ready by
activating pin #4 (RTS). The DCE responds by activating pin #5 (CTS). Now the
handshake process is complete. Pins #4 and #5 are “flow control” signals.

However, with the Okuma control, pin #4 (RTS) is not connected to the PC when
incorporating the “hardware” handshake. This signal is always turned “on” as soon as
transmission or reception of data is requested on the Okuma and remains on there after.
Therefore, we must jump this signal to pin #5 (CTS) on the Okuma side. CTS must be
“on” in order for the Okuma control to transmit data. The “handshake” is being controlled
by a different signal (RG1) which is Okuma’s answer to (RTS). The following example
shows how the RG1 signal is used to control data flow “to” the Okuma:

9
Timing Chart: (Read Operation PC Okuma)

DSR

RG1 (from Okuma)

RxD (receive data from PC) byte byte

start bit stop bit

The RG1 signal is turned “on” when the Okuma requests the external
device to send data. It is forced “off” by the start bit of the data sent
from the external device. This “handshaking” which is controlled by
the Okuma RG1 signal is carried out until all data is received by the
Okuma control.

Timing Chart: (Punch Operation Okuma PC )

DSR

CTS

TxD Data..Data..Data..Data.. Data..Data..Data..Data..

The Okuma control transmits data to the PC while the CTS

signal is “high”. Data transmission stops when this signal goes “low”.
Transmission resumes in response to the CTS signal, which again goes high.

This CTS signal should be connected to the RTS signal of the PC. The job
of the PC then is to toggle this signal high as the buffer is empty, and low when the
buffer becomes full.

As you can see from the above timing diagrams, the “handshaking” is being
controlled by device signals either on the Okuma control or on the PC.

10
Here is a good example of a cable configuration to use when connecting an
Okuma control to a PC while incorporating “hardware” flow control:

Cable Configuration (Hardware Handshake):

25-Pin DB-25 25-Pin DB-25

Connector (Okuma) Connector (PC)

FG 1 shielding
TD 2 3 RD
RD 3 2 TD
RG1 9 5 CTS
CTS 5 4 RTS
DSR 6 6 DSR
DTR 20 20 DTR
SG 7 7 SG

Section III. Okuma Control Types

Now that I’ve explained the RS232-C specification and how it relates to different cable
configurations and handshaking, I will now categorize how communication differs
between the several types of Okuma controls that support serial data transfer.

Okuma Controls Which Do Not Support Serial Communications:

Machining Centers:

OSP2300M Control No Serial Data Transfer available.

OSP3000M Control No Serial Data Transfer available.

Lathes:

OSP2200L No Serial Data Transfer available.

OSP3000L No Serial Data Transfer available.

These controls are sometimes “retrofitted” with BTR (Behind Tape Reader) devices.
Several products are available by different vendors. The BTR ties
in to the Tape Reader circuit which is a standard specification on the above controls.
Since Okuma circuit modification is often necessary, Okuma cannot be responsible for
such a retrofit offered by these BTR vendors.

Warning: If such BTR modification is carried out by our customers, it often

Becomes an issue when the Executive NC Software Tapes from
Okuma must be loaded for any reason. Know your BTR/Okuma
circuits and prepare to restore to original if necessary!

11
 Okuma Controls Which Do Support Serial Communications:

Machining Centers:

OSP5000M Hardware Handshake only.

OSP5000M-G Hardware & Software Handshake.
OSP5020M Hardware & Software Handshake.
OSP7000M Hardware & Software Handshake.
OSP700M Hardware & Software Handshake.

Lathes:

OSP5000L Hardware Handshake only.

OSP5000L-G Hardware & Software Handshake.
OSP5020L Hardware & Software Handshake.
OSP7000L Hardware & Software Handshake.
OSP700L Hardware & Software Handshake.

Grinders:

OSP5000G Hardware Handshake only.

OSP5000G-G Hardware & Software Handshake.
OSP5020G Hardware & Software Handshake.
OSP7000G Hardware & Software Handshake. ????
OSP700G Hardware & Software Handshake. ????

Note: At the time of this publication, there are plans to introduce a variety
of new Okuma controls to the market. All will support serial
communications. I cannot be responsible for any hardware/software
design changes on future controls that would make this handbook
material dated. I can only assume that perhaps only parameter data
related to communications would vary on these future Okuma products.

Section IV. Okuma Parameter Data

In order for any Serial Communications to take place, there are certain Okuma
parameters that must be established to match those of the PC. These parameters
define word length, parity, baud rate, etc.

12
The most frustrating part of establishing a serial link is based upon finding a “match”
between these parameters as they pertain to both the Okuma, and the PC side data
transfer protocol.

This section will provide a description of all Okuma-side parameters that pertain to
Serial Communications, as well as a recommended cable configuration to match a
particular parameter scheme.

OSP5000L Controls:

NC Optional Parameter Bits:

Stop Bit #3 bit 3 = 0 (Two Stop Bits)

= 1 (One Stop Bit)
Ready Signal #3 bit 4 = 0 (No Ready Signal)
= 1 (Ready Signal)
Parity Check #3 bit 6 = 0 (No 9th-bit parity check)
= 1 (9th-bit parity check performed)
Parity #3 bit 7 = 0 (Odd Parity)
= 1 (Even Parity)
8 Bit JIS #4 bit 7 = 0 (7-bit word)
= 1 (8-bit word)

NC Optional Parameter Word:

Baud Rate #10 = 4 (9600 bits/sec.)

= 8 (4800 bits/sec.)
= 16 (2400 bits/sec.)
= 32 (1200 bits/sec.)
= 64 (600 bits/sec.)
= 128 (300 bits/sec.)
= 256 (150 bits/sec.)

Busy Time #29 = 10 (10 second busy time before time out alarm.)

Note: Since this control does not support the DC-Code Control specification
(Software Handshake) the following cable must be used:

13
 25-Pin DB-25 25-Pin DB-25
Connector (Okuma) Connector (PC)

FG 1 shielding
TD 2 3 RD
RD 3 2 TD
RG1 9 5 CTS
CTS 5 4 RTS
DSR 6 6 DSR
DTR 20 20 DTR
SG 7 7 SG

OSP5000L-G & OSP5020L Controls:

NC Optional Parameter Bits:

Stop Bit #12 bit 0 = 0 (Two Stop Bits)

= 1 (One Stop Bit)
Ready Signal #12 bit 1 = 0 (No Ready Signal)
= 1 (Ready Signal)
Parity Check #12 bit 2 = 0 (No 9th-bit parity check)
= 1 (9th-bit parity check performed)
Parity #12 bit 3 = 0 (Odd Parity)
= 1 (Even Parity)
8 Bit JIS #12 bit 4 = 0 (7-bit word; 7 data bits + parity.)
= 1 (8-bit word)
DC Code Control #12 bit 5 = 0 (No DC codes output)
= 1 (DC codes output)
DC Code (Type 2) #12 bit 6 = 0 (No DC codes output)
= 1 (Type II DC codes output)
File name read #12 bit 7 = 0 (No file name read)
= 1 (File name read)

14
Tape Code ISO #1 bit 0
Tape Code Parity Recognition #1 bit 1

Bit 1 Bit 0 Operation Condition

1 1 In the READ and VERIFY modes, parity check is

automatically performed disregarding tape code (ISO/EIA).
In PUNCH mode, ISO code is always selected.

1 0 In the READ and VERIFY modes, parity check is

automatically performed disregarding tape code (ISO/EIA).
In PUNCH mode, EIA code is always selected.

0 1 The OSP control selects ISO code for READ and VERIFY.
Tape code nonconformity results in an alarm.
In PUNCH mode, ISO code is always selected.
0 0 The OSP control selects EIA code for READ and VERIFY.
Tape code nonconformity results in an alarm.
In PUNCH mode, EIA code is always selected.

Tape TV Check #1 bit 2

Bit 2 Operation Condition

0 No TV check performed in READ mode. In PUNCH mode,

the number of characters in one block is not adjusted.

1 In the READ mode, the number of characters in one block is

checked and if the number is odd, an alarm results.

15
End Code #1 bit 3

Bit 3 Operation Condition

0 The end of program (delimiter) should be “%” or “ER”.

1 The end of program code (delimiter) should be “null codes”

(HEX value of 00).

Tape Read Verify #1 bit 4

Bit 4 Operation Condition

0 After program is read into the control, VERIFY is not

performed.

1 VERIFY is performed after the program is read.

Tape Read Verify #1 bit 4

Bit 4 Operation Condition

0 After program is read into the control, VERIFY is not

performed.

1 VERIFY is performed after the program is read.

16
Tape Code ISO #1 bit 3
Tape Code ISO #1 bit 4
Tape Code ISO #1 bit 5
Tape Code ISO #1 bit 6
Tape Code ISO #1 bit 7

17