WordPress.com · Author Dario Toncich was born in Melbourne Australia in 1960. He graduated (with...

Data Communications

and

Networking

for

Manufacturing Industries

Second Edition

by

Dario J. Toncich

B.E.E. (Hons), M Eng, MIE Aust, CP Eng

Chrystobel

Published by...

7 Wrixon Avenue Brighton Australia 3187

Engineering

ISBN 0 646 10522 1

Copyright D.J. Toncich, 1991, 1993

Layout and artwork by Chrystobel Engineering of Brighton Australia. Printed and

Bound in Australia for Chrystobel Engineering.

First Printed in Australia, 1992. Second Edition printed in Australia, 1993 (Hard-

Cover), 1994 (Soft-Cover). Additional copies of this text may be obtained by

directing purchase enquiries directly to Chrystobel Engineering. Subject conveners

and lecturers prescribing this text as a course reference may be eligible for

complimentary copies.

Author

Dario Toncich was born in Melbourne Australia in 1960. He

graduated (with honours) in Electrical Engineering from the

University of Melbourne in 1983. Since that time he has held both

industry and academic positions and has experience in the fields of

data communications, computer architecture, FMS and simulation.

During his time in industry, Dario Toncich spent a number of years

developing computer control, simulation and communications

equipment for FMS at an Australian-based Advanced

Manufacturing Technology (AMT) Company. In 1988, Dario

Toncich was appointed as Manager of Research Activity for the

CIM Centre at the Swinburne University in Hawthorn, Victoria,

Australia. As the manager of the Centre he has led research into

AMT fields including FMS control and simulation and industrial

data communications. Dario Toncich is also a professional

consulting engineer to industry in the fields of FMS and data

communications and has a Master of Engineering (by Research)

degree from the Swinburne University. The CIM Centre is

internationally renowned for its applied, industry-oriented research

programs in factory communications, non-contact inspection,

robotics, FMS, machine control systems, and systems integration.

The Centre is comprised of over 55 engineers and researchers and

attracts Australia's highest ranked University engineering graduates

for its research programs. The CIM Centre has numerous

international collaborative links and is nationally recognised as a

Centre of Excellence in advanced manufacturing.

Dario Toncich is also a subject convener and lecturer in a range of

computer and CIM related subjects at postgraduate and

undergraduate level at the Swinburne University. His research

work has been published in international refereed journals and

conference proceedings and he has also authored a number of

guided learning programs in computer architecture and data

communications.

No portion of this text book may be reproduced in any form

whatsoever without the explicit, written consent of the author.

Notification of errors or omissions in this text book,

or suggestions for its improvement, can be directed to

Chrystobel Engineering

7 Wrixon Avenue Brighton Australia 3187.

(i)

Table of Contents

Introduction (iii)

How to Read and Use This Book (v)

1 Computer System Fundamentals and Internal Data Transfer 1

1.1 Microprocessor System Fundamentals 2

1.2 Number Systems, Conversion and Arithmetic 8

1.3 Representation of Alpha-numerics 14

1.4 Boolean Algebra 18

1.5 Microprocessor System Program Execution and Communication 23

1.6 Master-Slave Relationships and Interrupts 32

2 Computers and Control Systems Within Manufacturing 35

2.1 The Range and Scope of Computers within Manufacturing 36

2.2 Programmable Logic Controllers 40

2.3 Multiple Axis Motion Controllers (CNC and Robotics) 43

2.4 Linking Computer Aided Design to Manufacture 49

2.5 Manufacturing Systems

52

3. Principles Of Data Communications 59

3.1 Eight Fundamentals of Computer to Computer Communication 60

3.2 Resolution of Conflicts in Communication - Protocol

62

3.3 Modelling Conducting Communications Links 68

3.4 Electro-Magnetic Interference and Cross-Talk 74

3.5 Parallel Data Transmission and Communications Ports 78

3.6 The Centronics Parallel Port 82

3.7 Networked Parallel Data Transmission and IEEE-488 87

4. Serial Data Communications -Fundamentals 91

4.1 Serial Communications in Integrated Manufacturing 92

4.2 The Role of Parallel Communications in Manufacturing 95

4.3 Parallel to Serial Conversion 98

4.4 Synchronous Serial Data Communications 102

4.5 Asynchronous Serial Data Communications 107

4.6 Error Detection Techniques 111

4.7 Signal Modulation 121

4.8 DCE and DTE 136

4.9 UARTS and USRTS 138

(ii)

5. Serial Data Communications - Hardware Application 143

5.1 The RS-232C Standard 144

5.2 The RS-232C Connectors 146

5.3 Basic RS-232 Connections 149

5.4 Complex RS-232 Connections 154

5.5 A Summary of Points Related to RS-232 Links 161

5.6 Devices to Assist in Establishing Serial Links 162

5.7 Selecting RS-232 Cables and Line-Drivers 164

5.8 Configuring UART Parameters 169

5.9 Bit Rates and Baud Rates 172

5.10 RS-422 and RS-449 Hardware Links 173

5.11 The 20mA Current Loop 177

5.12 Summary of Key Factors in Point to Point Serial Links 178

6. Serial Data Communications - Software Application 181

6.1 Developing Software for Serial Communications 182

6.2 The XON/XOFF Protocol 184

6.3 ACK/NAK Protocols 187

6.4 Communications Software Layering 204

6.5 Terminal Emulation and the Kermit System 206

7. Local Area Networks - Fundamentals 211

7.1 Local Area Network Concepts 212

7.2 Network Topologies 216

7.3 Contention Schemes 221

7.4 ISO / OSI Seven Layer Model 225

7.5 A Summary of Key Points Related to Networks 231

7.6 Data Packet Forms on Networks - BSC, HDLC and SDLC 233

7.7 PSTN / PSDN / CSDN / ISDN 238

7.8 The Role of Networking in Manufacturing 242

8. Local Area Networks - Applications And Standards 247

8.1 Interfacing Computers to Networks 248

8.2 Network Performance - Transfer Rates 252

8.3 Networks Standards Activities - IEEE 802 Committee 257

8.4 Bridges, Routers and Gateways 262

8.5 The Ethernet System 266

8.6 The General Motors / Boeing MAP and TOP Networks 269

8.7 SNA 279

8.8 File Server and Office Networks 281

8.9 What Will Our Computers Say Once they are Networked? 285

(iii)

9. Real-Time Networks for Distributed Control 287

9.1 Introduction 288

9.2 Typical Control Applications for Real-Time Networks 292

9.3 Proprietary Real-Time LANs - CAN and LON 295

9.4 Conclusions 300

Appendix A - Industrial Data Communications Dictionary

Appendix B - References

Appendix C - Index

(v)

Introduction

The physical integration of industrial controllers with Computer Aided Design

(CAD) systems and manufacturing management systems has become one of the most

important issues in the field of Computer Integrated Manufacture (CIM).

Communications links between these intelligent, computer based systems are a vital

part of all modern, manufacturing organisations endeavouring to integrate

management systems and production systems into a more efficient, responsive and

cohesive unit.

Communications within a manufacturing organisation can take on many forms.

At a basic level it is often necessary to reliably transfer data or programs, developed

on a Computer, to a Computer Numerical Control (CNC) machine tool, robot or

Programmable Logic Controller (PLC). At a higher level it may be necessary to

integrate CAD workstations, industrial controllers (CNCs & PLCs) and

manufacturing management computer systems through a Local Area Network (LAN).

However, in order to establish links and networks that can function with industrial

equipment, there needs to be an understanding of the basic mechanisms and problems

of data communications and the special needs of the manufacturing environment.

Contrary to the (often misguided) industry faith in turn-key solutions, the

selection, installation and maintenance of a network requires a good deal of in-house

expertise. A large proportion of high-technology manufacturing systems fail simply

because companies place too much reliance on external consultants and vendors

instead of developing this vital, in-house expertise. Inevitably, manufacturers need to

realise that "all-embracing", "ever-lasting", "future-proofed", "turn-key" solutions

simply do not exist in the world of reality. This is particularly true for industrial

communications networks which live in an environment of widely differing,

incompatible and constantly changing computer technologies and standards.

In many disciplines of engineering, there are difficulties in finding standards

that cover a specific technology. This is certainly not the case in terms of industrial

networking. In fact there are an enormous number of standards that cover the area.

The bulk of these standards do not, in isolation, provide a mechanism for reliable

data communication in the factory. A range of cohesive standards needs to be

selected in order to realise a viable link or network. However, many standards are

incompatible with one another or unsuitable for the industrial environment. Some

communications standards are even irrelevant to the applications to which they are

now applied.

(vi)

In order to select communications equipment or develop communications

protocols for the manufacturing environment, one needs to understand both the

networking technology and the standards themselves.

This book is specifically designed to provide professionals in the field of

manufacturing with the knowledge required to understand the fundamentals,

applications and more importantly, the problems of industrial computer

communications and networking. It will allow you to intelligently take on the

challenge of integrating production equipment within a modern manufacturing

organisation.

(vii)

How to Read and Use This Book

"Data Communications and Networking for Manufacturing Industries" has

been written to provide you with a very readable text that remains relatively free of

complex mathematical analyses. Even if you are a beginner in the field of computer

communications, you will still find that the book is very straightforward in

addressing the complex issues of data communications. You will also find that the

book will help you come to terms with the "jargon" used in relation to computer

communications.

The book is structured as a complete handbook on industrial data

communications, and hence some chapters deal with fundamental issues related to

computers and communications. The more experienced readers may feel that a

particular chapter is beneath their dignity. Therefore the chapters have been written

as discrete (stand-alone) units which have been placed into a logical sequence. In

keeping with the philosophy of other engineering texts, a summary appears at the

beginning of every chapter and you may choose to leave out some chapters without

affecting the reading of subsequent chapters. However, be forewarned - be judicious

in omitting chapters. Many semi-experienced people have grave misconceptions

about data communications and networking.

If you are like the many professionals who have had to learn about computers

and communications through the "back-door", by listening to vendors and consultants

who spout acronyms and jargon, then you should probably read this book chapter and

verse, in sequential order. You may well find that on many occasions your back-door

knowledge has led you to put the numbers two and two together and come up with

the number five.

(viii)

1

Chapter 1

Computer System Fundamentals and Internal

Data Transfer

A Summary...

Principles of microprocessor based systems. The data bus. Number systems, binary

data representation, conversion and arithmetic. Boolean Algebra and laws. The bus

architecture and parallel data transmission. Alpha-numeric representation and the

ASCII / EBCDIC systems. The address bus system and addressing. Memory

structure, operation and mapping. Microprocessor system internal master-slave

relationships. Interrupt programming and internal system co-ordination and control.

Read This Chapter If...

♦ You are unfamiliar with the principles of modern computer architecture and

you would like to come to terms with the basic concepts

♦ You need to refresh your memory on computer topics, terminology and

acronyms that are in common use in data communications.

2 D.J. Toncich - Data Communications & Networking for Manufacturing Industries

1.1 Microprocessor System Fundamentals

Microprocessor chips are the basic building blocks for nearly all of the

"intelligent" control systems found in a modern manufacturing organisation. Smaller

systems have a single microprocessor chip acting as the entire Central Processing

Unit (CPU). This is typical of Personal Computers, Workstations and small

industrial controllers. Larger computer-based systems use microprocessors as

building blocks for entire boards, which may themselves act as CPUs or closed loop

controllers.

Regardless of the architecture of intelligent systems, the principles by which

communication occurs between a microprocessor chip and other associated

semiconductor devices are essentially the same. We shall examine communications

in a simple, single processor system to illustrate the key features involved.

Figure 1.1 shows a few of the fundamental elements in an intelligent system -

the microprocessor chip, the memory chips and the data (communications) bus.

MicroprocessorChip

Memory MemoryChip N

Data Bus

Chip 1...

d0d1

:

d7

Figure 1.1 - Some Basic Elements in an "Intelligent System"

The data bus is a cluster of parallel conductors, which run as a group around

the base-board (mother-board), on which the majority of chips (including the

microprocessor) are mounted. The number of conductors (size of the data bus)

depends upon the type of microprocessor chip on which the computer architecture is

based. Typical data bus sizes may be 8, 16 or 32 bits.

Computer System Fundamentals and Internal Data Transfer 3

The microprocessor chip can be envisaged as a machine that generates a

number of internal voltage levels which together define the internal "state" of that

machine. The internal state of the microprocessor changes at a rate determined by an

external clock chip. The internal "state" voltage levels are decoded (by appropriate

circuits) in order to:

• move data into or out of the microprocessor

• manipulate data within the microprocessor (add, subtract, etc.)

• move data from one internal storage location (register) to another.

Each cycle (tick) of the clock causes the microprocessor to jump from one

internal state to another. The "next state" of the microprocessor is determined by a

logical combination of its current internal state, together with the condition of all the

various input lines connected to it. This is shown schematically in Figure 1.2. At each

cycle of the system clock, a microprocessor executes only a very simple operation -

read data in; write data out; store data in an internal register (storage location); add

data contained in two internal registers; compare data in internal registers and so on.

Sequential

State Machine

Decoding Logic

Register 1

Numerical

Circuits Register N

Next Internal State Determined

by current state combined with

data bus, registers, etc.

Data

Clock

Interrupt

feedback from current inputs

:

(+, -, etc.)

:Address

Bus

Bus

Internal State

Figure 1.2 - Schematic of Building Blocks and Data Flow

Within a Microprocessor Chip


Chips such as memory chips are considerably less sophisticated than the

microprocessor and essentially have only two functions - read data in and write data

out. Memory chips which perform both these functions are referred to as Random

Access Memory (RAM) and those which can only write data out are referred to as

Read Only Memory (ROM), because other devices can only read from them.

The architecture of semiconductor devices such as microprocessors, memory

chips, etc., is based upon the use of only two voltages - low (false / off) or high (true /

on). This is referred to as a "binary" or "base 2" system. Typically a voltage in the

order of five volts is treated as high, and voltages of approximately zero are treated as

low. The actual values depend upon the semiconductor technology used to fabricate

a particular set of chips.

At any one point within a microprocessor chip, only the numbers 0 or 1 can be

represented electronically at any instant in time. Similarly, the microprocessor's links

to its outside world, the conducting, bus lines can also only have either a high or low

voltage at any instant. Multiple conductors are therefore needed on a bus in order for

the microprocessor to handle realistic numbers. A system with "n" conductors can

therefore directly handle numbers ranging from:

0 to (2n - 1)

The voltage waveforms which appear, both on the bus lines of a system such as

that in Figure 1.1, and within the semiconductor chips themselves, are approximated

by square waves, as shown in Figure 1.3. Systems such as this are referred to as

"digital", since we are only concerned with two conditions, high and low, rather than

continuous (analogue) voltages.

In reality, few physical quantities such as voltage can switch from high to low

and vice-versa in zero time. There is a finite time required in order for this electronic

switching to occur and this transition period is in the order of pico-seconds. The

voltage waveform of Figure 1.4 is more typical of what actually takes place in digital

circuits.

Designers of digital hardware must take these transitions into account, but in

more general discussions of computer systems and digital circuits we deal only with

the idealised waveforms exemplified in Figure 1.3.


Time

Time

Time

Time

Time

Time

Time

Time

Voltage on d7

Voltage on d6

Voltage on d5

Voltage on d4

Voltage on d3

Voltage on d2

Voltage on d1

Voltage on d0

T

Figure 1.3 - Typical Data Bus Voltage Waveforms (approximate)


Time

Voltage

Approximate Waveform

Actual Waveform

Figure 1.4 - Actual Switching from High-Low and Low-High

If we use the voltage waveforms as shown in Figure 1.3 as a mechanism for

representation of the numbers 0 and 1, we can say that at a time "T", we have the

following, "binary" number:

1 0 1 1 1 1 0 1

At any instant in time (neglecting transition periods), each point in a digital

circuit represents one binary digit. This is abbreviated to the word "bit".

Since humans generally deal with the decimal (base 10) number system and

alphabetic characters it should be evident that it is necessary for an intelligent digital

system to continually convert data to and from the form used by humans. This is

shown in Figure 1.5.


Human UserBinary

Computation

Decimal to

Binary

Conversion

Binary to

Decimal

Conversion

Figure 1.5 - Conversion from Computer to Human Form


1.2 Number Systems, Conversion and Arithmetic

In order to understand how data is transferred within computer systems, it is

first necessary to understand how data is represented. We must therefore examine a

range of different number systems. Firstly, in the decimal (or base 10) number

system, the following is a count sequence:

0 1 2 3 4 5 6 7 8 9

10 11 12 13 14 15 16 17 18 19

20 21 22 23 24 25 26 27 28 29

.

.

90 91 92 93 94 95 96 97 98 99

100 101 102 103 104 105 106 107 108 109

Note the way in which we "carry" a digit each time we exceed the number "9".

These representations are symbolic of the quantities that we actually wish to

represent. For example, the decimal number 721 actually represents the following:

(7 x 102) + (2 x 101) + (1 x 100)

Since the electronic circuitry in computer systems is designed to handle only

two types of voltages (high and low), this representation is clearly inappropriate for

our needs. There are however other commonly used number systems, which more

closely relate to the needs of the computer, albeit indirectly. For example, the base 8,

or "Octal" number system arises regularly. A count sequence in base 8 takes on the

following form:

0 1 2 3 4 5 6 7

10 11 12 13 14 15 16 17

70 71 72 73 74 75 76 77

100 101 102 103 104 105 106 107

The octal number 721 actually represents the following:

(7 x 82) + (2 x 81) + (1 x 80)

which is equal to decimal 465 and not decimal 721.


When working with a range of different number systems, it is common practice

to subscript numbers with the base of the number system involved. For example, we

can validly write the following expression:

7218 = 46510

Another number system that is commonly used with computer systems is the

base 16 or hexadecimal number system. Since we do not have enough of the

ordinary numerals (0..9) to represent 16 different numbers with a single symbol, we

"borrow" the first six letters of the alphabet (A..F). A count sequence in base 16 then

takes on the following form:

0 1 2 3 4 5 6 7 8 9 A B C D E F

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

.

.

F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF

100 101 102 103 104 105 106 107 108 109 10A 10B 10C 10D 10E 10F

To similarly convert the hexadecimal number 721 to decimal:

72116 = (7 x 162) + (2 x 161) + (1 x 160)

= 182510

Finally we move on to the number system most closely related to the

architecture of computer systems themselves, the binary number system, in which we

can only count from 0 to 1 before performing a "shift" operation. The following is a

base 2 count sequence:

0 1

10 11

100 101 110 111

1000 1001 1010 1011 1100 1101 1110 1111

If we look again at Figure 1.3, we can now see that the number represented by

the voltage waveforms at time "T" is:

101111012 =

(1x27) + (0x26) + (1x25) + (1x24) + (1x23) + (1x22) + (0x21) + (1x20)

= 18910


We have now seen that it is a relatively straightforward task to convert numbers

from different bases to their decimal (base 10) equivalents. However it is also possible

to convert from base 10 numbers into different number systems through a process of

long division. In order to do this, the original decimal number is repeatedly divided by

the new base (to which we wish to convert) and the remainders of each division are

stored. The process is repeated until the original number is diminished to zero. The

remainders then form the representation of the decimal number in the new base. This

sounds complex, but in essence is relatively straightforward.

For example, if we wish to convert the decimal number 189 into its binary

representation, the following long division quickly achieves the result:

2 18994472311

5210

1 Low order Remainder0111101 High order Remainder

Therefore 18910 = 101111012 as proven earlier.

Conversion from the binary number system to the octal number system is a

simple task, since each group of three bits directly represents an octal number. Binary

numbers are partitioned into groups of 3 bits (binary digits), starting from the low

order bits. Then each group of three digits is individually converted into its octal

equivalent. For example, to convert the binary number 1011011110111 to its octal

equivalent, the following procedure is used:

1 011 011 110 111

1 3 3 6 7

Therefore 10110111101112 = 133678.


Conversion from the binary number system to the hexadecimal number system is

similar to the binary-octal conversion, except that binary digits are placed into groups

of four (since 4 bits represent 16 combinations). Each group of four is then

individually converted into its hexadecimal equivalent. For example, to convert the

binary number 1011011110111 to its hexadecimal equivalent, the following procedure

is used:

1 0110 1111 0111

1 6 F 7

Therefore 10110111101112 = 16F716.

Octal and hexadecimal numbers can also be readily transformed into their binary

representation, simply by converting each digit individually to its equivalent 3 or 4 bit

representation. This is the reverse operation to that shown in the previous two

examples.

You should now observe that we have a simple and direct mechanism for

converting from octal and hexadecimal numbers to binary, but that in order to convert

from decimal to binary we need to perform the long division calculation, shown

previously. In order to establish an analogous, direct relationship between binary and

decimal, another number representation is also in use. This is referred to as the Binary

Coded Decimal or BCD system.

In the BCD system, each decimal digit is represented in binary by four bits. For

example, the BCD equivalent of the number 721 is given by:

0111 0010 0001

This is similar to the relationship between hexadecimal and binary, except that certain

bit combinations can never occur, since the BCD system uses 4 digits (with 16

combinations) in order to represent the ten decimal digits, 0 to 9. Strictly speaking,

BCD should not be regarded as a number system, but rather as a mechanism for

directly converting human (decimal) input into an electronically usable binary form. It

is most commonly used at a human to computer interface. For example, if a person

pushes a number 7 (say) on a simple key-pad, then the appropriate voltages (low, high,

high, high) can be generated.

To summarise the various number representations, most commonly associated

with computers, Table 1.1 shows how each of the number systems represents the

decimal numbers from 0 to 20.


Decimal

Hexadecimal Octal Binary BCD

0 0 0 00000000 0000 0000

1 1 1 00000001 0000 0001

2 2 2 00000010 0000 0010

3 3 3 00000011 0000 0011

4 4 4 00000100 0000 0100

5 5 5 00000101 0000 0101

6 6 6 00000110 0000 0110

7 7 7 00000111 0000 0111

8 8 10 00001000 0000 1000

9 9 11 00001001 0000 1001

10 A 12 00001010 0001 0000

11 B 13 00001011 0001 0001

12 C 14 00001100 0001 0010

13 D 15 00001101 0001 0011

14 E 16 00001110 0001 0100

15 F 17 00001111 0001 0101

16 10 20 00010000 0001 0110

17 11 21 00010001 0001 0111

18 12 22 00010010 0001 1000

19 13 23 00010011 0001 1001

20 14 24 00010100 0010 0000

Table 1.1 - Representation of Decimal Numbers from 0 to 20


Numbers from different bases can be dealt with arithmetically in the same way

as decimal numbers, except that a "shift" or "carry" has to occur each time a digit

equals or exceeds the base value. The following are simple examples of addition,

subtraction, multiplication and division using the binary number system:

(i) Addition of 111012 and 10112

11101+ 1011

101000

11111 (Carry)

(ii) Subtraction of 10112 from 111012

11101- 1011

10010

(iii) Multiplication of 111012 by 10112

11101 x 1011

11101 111010 11101000

100111111

(iv) Division of 111012 by 10112

111011011

10.10100011


1.3 Representation of Alpha-numerics

It should be clear from the discussions of 1.1 and 1.2 that microprocessor based

systems (and indeed digital systems) can only understand voltage waveforms which

represent bit streams. They have no capacity for a direct interpretation of the alpha-

numeric characters which humans use for communication.

In section 1.2, the Binary Coded Decimal system was cited as a means by which

numbers, entered on a simple keypad, could be directly and electronically represented

in a computer. This is however very restrictive as only 16 different numeric characters

can be represented by a 4 bit scheme (and only 10 combinations are actually used in 4

bit BCD). In order to represent all the upper and lower case alphabetic characters on a

typical computer keyboard, plus symbols, carriage-returns, etc., it is necessary to use

strings of 7 or 8 bits, which then provide enough combinations for 128 or 256 alpha-

numeric characters.

Two specifications for the bit patterns representing alpha-numeric characters are

in common use. These are the 7 bit ASCII (American Standard Code for Information

Interchange) and the 8 bit EBCDIC (Extended Binary Coded Decimal Interchange

Code) systems. The ASCII system is by far the more prolific of the two specifications

and it is used on the majority of Personal Computers. The EBCDIC system is used

predominantly in a mainframe (notably IBM) computer environment.

The ASCII character set is listed in Table 1.2. This table shows each character

beside its hexadecimal ASCII value, which explicitly defines the bit pattern

representation for each character. For example, the character 'X' has the hexadecimal

ASCII value of "58" that translates to a bit pattern of:

5 8

0101 1000

The corresponding EBCDIC hexadecimal values are also provided beside each

character for comparison. Note that the EBCDIC system uses an 8 bit representation

and therefore provides a much larger character set than the ASCII system. However

some of the bit patterns in the EBCDIC system are unused.


CHAR ASCII

Value

EBCDIC

Value

CHAR ASCII

Value

EBCDIC

Value

CHAR ASCII

Value

EBCDIC

Value

NUL 00 00 + 2B 4E V 56 E5 SOH 01 01 , 2C 6B W 57 E6 STX 02 02 - 2D 60 X 58 E7 ETX 03 03 . 2E 4B Y 59 E8 EOT 04 37 / 2F 61 Z 5A E9 ENQ 05 2D 0 30 F0 [ 5B 4B ACK 06 2E 1 31 F1 \ 5C E0 BEL 07 2F 2 32 F2 ] 5D 5B BS 08 16 3 33 F3 ^ 5E -- HT 09 05 4 34 F4 _ 5F DF LF 0A 25 5 35 F5 ` 60 -- VT 0B 0B 6 36 F6 a 61 81 FF 0C 0C 7 37 F7 b 62 82 CR 0D 0D 8 38 F8 c 63 83 SO 0E 0E 9 39 F9 d 64 84 SI 0F 0F : 3A 7A e 65 85 DLE 10 10 ; 3B 5E f 66 86 DC1 11 11 < 3C 4C g 67 87 DC2 12 12 = 3D 7E h 68 88 DC3 13 13 > 3E 6E i 69 89 DC4 14 3C ? 3F 6F j 6A 91 NAK 15 3D @ 40 7C k 6B 92 SYN 16 32 A 41 C1 l 6C 93 ETB 17 26 B 42 C2 m 6D 94 CAN 18 18 C 43 C3 n 6E 95 EM 19 19 D 44 C4 o 6F 96 SUB 1A 3F E 45 C5 p 70 97 ESC 1B 27 F 46 C6 q 71 98 FS 1C 22 G 47 C7 r 72 99 GS 1D -- H 48 C8 s 73 A2 RS 1E 35 I 49 C9 t 74 A3 US 1F -- J 4A D1 u 75 A4 SP 20 40 K 4B D2 v 76 A5 ! 21 5A L 4C D3 w 77 A6 " 22 7F M 4D D4 x 78 A7 # 23 7B N 4E D5 y 79 A8 $ 24 5B O 4F D6 z 7A A9 % 25 6C P 50 D7 7B C0 & 26 50 Q 51 D8 | 7C 6A ' 27 7D R 52 D9 7D D0 ( 28 4D S 53 E2 ~ 7E A1 ) 29 5D T 54 E3 DEL 7F 07 * 2A 5C U 55 E4

Table 1.2 - ASCII and EBCDIC Character Representation


The ASCII system only uses 7 bits to represent characters with values from 0 to

7F (127) but most computers work with 8 bit units. In order to utilise the high order

bit, an extended ASCII character set, using all 8 bits, displays special symbols on

Personal Computers (PCs), but unfortunately there is no uniformity in definition.

Frequently, PC software packages (such as ASCII-based word-processors) take

advantage of the spare high-order bit to store additional character information such as

bolding, underlining, etc.

The choice of bit patterns to represent characters and numerics is essentially an

arbitrary one. For example, in both the ASCII and the EBCDIC system, the number

characters '0' to '9' are not represented by their equivalent binary values. In ASCII, the

character '0' is represented by hexadecimal 30, which has a bit pattern of 00110000 and

so on.

The first 32 ASCII characters in the set are not defined as "printable characters",

although they do display as symbols on some computers. These special characters are

predominantly used for communications purposes and will have relevance to our

discussions in later chapters. Table 1.3 lists the values, together with their names and

common abbreviations. Some of the characters in this set (such as carriage return) can

be generated by a single key-stroke on an ASCII keyboard. Others can be generated by

holding down the control (CTRL) key and hitting the corresponding letter listed in the

table.

We summarise our discussions by saying that within the computer system itself,

there is no direct recognition of alpha-numeric characters, but only of the bit strings

(patterns) which are chosen to represent them. These bit patterns are arbitrarily

defined, with the most common definition being the ASCII code system.


HEX VALUE

(ASCII)

NAME ABBREVIATED NAME KEY CODE

00 NULL NULL CTRL @ 01 START OF HEADER SOH CTRL A 02 START OF TEXT STX CTRL B 03 END OF TEXT ETX CTRL C 04 END OF TRANSMISSION EOT CTRL D 05 ENQUIRY ENQ CTRL E 06 ACKNOWLEDGE ACK CTRL F 07 BELL BEL CTRL G 08 BACK SPACE BS CTRL H 09 HORIZONTAL TAB HT CTRL I 0A LINE FEED LF CTRL J 0B VERTICAL TAB VT CTRL K 0C FORM FEED FF CTRL L 0D CARRIAGE RETURN CR CTRL M 0E SHIFT OUT SO CTRL N 0F SHIFT IN SI CTRL O 10 DATA LINE (LINK) ESCAPE DLE CTRL P 11 DEVICE CONTROL 1 (XON) DC1 CTRL Q 12 DEVICE CONTROL 2 DC2 CTRL R 13 DEVICE CONTROL 3 (XOFF) DC3 CTRL S 14 DEVICE CONTROL 4 DC4 CTRL T 15 NEGATIVE ACKNOWLEDGE NAK CTRL U 16 SYNCHRONOUS IDLE SYN CTRL V 17 END OF TRANSMIT BLOCK ETB CTRL W 18 CANCEL CAN CTRL X 19 END OF MEDIUM EM CTRL Y 1A SUBSTITUTE SUB CTRL Z 1B ESCAPE (ESC) ESC CTRL [ 1C FILE SEPARATOR FS CTRL \ 1D GROUP SEPARATOR GS CTRL ] 1E RECORD SEPARATOR RS CTRL ^ 1F UNIT SEPARATOR US CTRL _

Table 1.3 - Special Functions of the first 32 ASCII Characters


1.4 Boolean Algebra

Boolean Algebra was named after the mathematician George Boole (1815-64)

and is the simplest means by which we can convert human reasoning and tautology

into a mathematical and electronic form for computation. Boolean Algebra deals with

the logic of the binary numbers, "0" and "1" or the states "TRUE" and "FALSE".

The means by which we now generate electronic circuits on Small Scale

Integrated (SSI), Medium Scale Integrated (MSI), Large Scale Integrated (LSI) and

Very Large Scale Integrated (VLSI) semiconductors, to provide Boolean logic is

beyond the scope of this book. Suffice to say that these are well-established

technologies, which are in principle based on semiconductor switching of voltages

from high to low and vice versa. The basic circuits used to provide Boolean logic

within computer systems are referred to as "logic gates".

Table 1.4 shows the symbols for some common Boolean gates, together with

their Boolean Algebra functions. Beside each gate is a table, generally referred to as a

"truth table", which illustrates how the outputs from each logic circuit are related to the

inputs. Note that the Boolean Operators "." and "+" do not represent multiplication

and addition. Rather, they represent the logical functions "AND" and "OR"

respectively. This can become a very confusing point, particularly where we use

Boolean Algebra to make circuits that add or multiply binary numbers together. Note

also that the symbolic circuit representation for logic gates, shown in table 1.4, is one

of the commonest forms in use. However, it is not a universal standard and the

symbolic representation of logic gates varies from country to country.

Using Boolean logic, we can convert statements such as:

"If both A and B are true or if C is true while D is false, then E will be

true,"

into Boolean expressions, which can be handled by computers. Using gates such as

those shown in table 1.4, we can effectively build simple circuits to provide the kind of

logic that we require. The following is the Boolean representation of the above

tautology:

_

E = (A.B) + (C.D)


In computer-based systems, Boolean Algebra is used at a number of different

levels, ranging from hardware design right through to software design (programming).

For example, in a Pascal computer program, we could implement the previous

expression with the following syntax:

IF (A AND B) OR (C AND NOT D) THEN

E := TRUE

ELSE

E := FALSE

At a hardware level, microprocessor chips have built-in Boolean logic and can

directly handle logical expressions internally. We therefore have a mechanism that can

provide computers with a small measure of "human" reasoning.


LOGIC GATE BOOLEAN

LOGIC

TRUTH TABLE

FUNCTION

X Y Z

Inverter

Z is NOT X

0 1

1

0

Z = X

AND

Z is X AND Y

0 0 1 1

0

1

0

1

0

0

0

1

Z = X.Y

NAND

Z is NOT (X AND Y)

0 0 1 1

0

1

0

1

1

1

1

0

Z = X.Y

OR

Z is X OR Y (Inclusive OR)

0 0 1 1

0

1

0

1

0

1

1

1

Z = X + Y

NOR

Z is NOT (X OR Y)

0 0 1 1

0

1

0

1

1

0

0

0

Z = X + Y

XOR

Z is either X OR Y but not both (Exclusive OR)

0 0 1 1

0

1

0

1

0

1

1

0

Z = X + Y

Table 1.4 - Common Boolean Logic Gates and Representation


Boolean expressions can often be unnecessarily complex. In situations where we

are designing electronic circuits, from gate chips, to provide Boolean logic, we clearly

need to minimise the number of chips and gates required. When we generate computer

programs, unnecessarily complex expressions can slow down the operation of

programs and decrease the legibility of the program code. For these reasons we need

to establish the simplest form of a Boolean expression before committing it to an

implementation phase.

There are a number of laws and postulates associated with Boolean Algebra.

These are listed in Table 1.5. They are used as the basis for the simplification of

Boolean expressions. A truth table can be constructed for each of the laws shown in

Table 1.5 in order to verify that they are correct. Using these laws and postulates, we

can now take a complex expression such as:

Z A B C A B D . .( ).

and simplify it in the following manner:

Z A B C A B D

A B C A B D

D A B

D A A B C D B

A A B CD A B B C D

A B C D A B CD

A B C D

A B C D

. .( ).

. . .( ).

.( )

. . . . . .

. . . . . . .

. . . . .

. . .

(By De Morgan's Theorem)

= A.B.C (By law of commutation)

= A.B.C (By law of association)

= (By law of commutation)

(By law of tautology)

(By law of tautology)

(By De Morgan's theorem)

If we were designing a circuit or piece of software to achieve a given Boolean

logic, then reduction techniques based on Boolean laws have the potential to simplify a

design. However, not all complex expressions can be simplified and the technique

shown above doesn't tell us when we have achieved the simplest form of an

expression. For this reason a number of more systematic techniques (such as

Karnaugh mapping) are also in use, but these are beyond the scope of this book.

Boolean algebra is introduced at this point because Boolean logic is the corner-

stone of digital circuitry and structured program development. These elements will be

of importance in later chapters, in the sense that they relate to data communications.


Postulates of Boolean Algebra

All variables must have either the value 0 or 1. If the value of a variable is not

zero then it must be one and vice-versa. The following rules apply:

OR AND NOT

1 + 1 = 1 1 . 1 = 1 1 0 1 + 0 = 1 1 . 0 = 0

0 + 0 = 0 0 . 0 = 0 0 1=

Boolean Laws of Combination

A B B A

A B B A

A B C A B C

A B C A B C

A B C A B A C

A A A

A A A

A

A A

A A

A

A A

A A

A A B A B

A A

A B

A B A B

A B A B

. .

( )

( . ). .( . )

.( ) . .

.

.

.

.

.

. .

.

=

+ = +

+ + = + +

=

+ = +

+ =

=

+ =

=

+ =

=

+ =

=

+ = +

=

= +

=

= +

(Laws of Commutation )

(Laws of Association )

(Laws of Distribution )

(Laws of Tautology - Idempotent Rule )

(Laws of Double Complementation )

A + B

(DeMorgan 's Theorems)

A + B

1 1

1

0

0 0

1

0

= A B.

Table 1.5 - Fundamental Principles of Boolean Algebra


1.5 Microprocessor System Program Execution & Communication

Now that we have examined how data is represented within a digital computer

system, we can examine the mechanism for program execution within a

microprocessor based system. We can also examine the communication that occurs

between the various elements of the system.

A microprocessor chip responds to certain bit patterns entering through its data

bus port as "instructions", which will cause it to perform some simple task. The

definition of the bit patterns, corresponding to instructions, depends entirely on the

particular microprocessor chip in use and is referred to as the "instruction set" of the

microprocessor. Instruction sets for microprocessors may vary significantly from one

processor to another but the basic instructions are essentially similar. Let us examine a

few such instructions from a hypothetical processor. We will assume that we have an

"8-bit" microprocessor, which means that its basic unit for data and instructions

consists of 8 bits (ie: 1 byte). Table 1.6 lists the bit patterns corresponding to

instructions for the hypothetical system.

Binary Machine

Code

Instruction Abbreviation

(Mnemonic)

0000 0001 Load internal microprocessor register

"A" with the number represented by

the next byte appearing on the data

bus.

LDA

0000 0010 Load internal microprocessor register

"B" with the number represented by

the next byte appearing on the data bus

LDB

0000 0011 Add the contents of register "A" to the

contents of register "B" and store the

sum in register "A"

ADD

0000 0100 Take each bit in register "B" and "OR"

it with the corresponding bit which

comes from the next byte appearing on

the data bus

ORB

0000 0101 If the contents of register "A" are not

zero then jump to the program

instruction in memory specified by the

next two bytes appearing on the data

bus

JNZA

Table 1.6 - Some Basic Instructions for a Hypothetical Processor


Note the word "MNEMONIC", used in regard to low level programming, is an

abbreviated means by which we can remember what each instruction (bit pattern) does.

If we wanted our hypothetical microprocessor to add the numbers 3 and 7 together,

then the following code might be used:

00000001 (LDA)

00000011 (3)

00000010 (LDB)

00000111 (7)

00000011 (ADD)

There are several questions that need to be examined at this point. Firstly, where

does the program reside before it is executed by the microprocessor? Secondly, how

does the microprocessor fetch these instructions? Thirdly, how can a microprocessor

differentiate between the bit pattern corresponding to the ADD instruction and that

corresponding to the number 3 (since they clearly have the same bit patterns)?

The third question is perhaps the easiest to answer. The microprocessor cannot

differentiate between data and instructions by any means other than the order in which

they arrive. Each instruction within the microprocessor's set, must be accompanied by

an "argument" (qualifier) of a pre-defined length. For example, the LDA command

must be qualified by an 8 bit number. The ADD command on the other hand, has a

qualifier of 0 bits in length (ie: no qualifier). Therefore, the microprocessor will treat

the second line of the above program as data (3) for the LDA instruction and NOT as

the ADD command.

The first and second questions are somewhat interrelated. In order to understand

the answer to these questions and thereby, the mechanism by which program execution

in a microprocessor based system occurs, we need to understand the principles by

which memory chips operate. We also need to examine the concept of "addressing",

which will also arise in our subsequent discussions of external data communications.

As a first step towards understanding program execution and internal data

transfer, we need to look at a more detailed picture of a microprocessor based system

than the one that we started out with in Figure 1.1. Figure 1.6 shows the same basic

elements as Figure 1.1, but this time we have added another cluster of 16 conductors,

which we term the "address bus". As with the data bus, the number of lines in the

address bus depends entirely on the architecture of the microprocessor system. Typical

address bus sizes may be 16, 32 or 64 bits. We have also added two other blocks to

the system, which are shown as "address decoders". We shall properly introduce these

a little later.


Microprocessor Memory Chip 1 ... Memory Chip N

Address Bus DecoderLogic N

Address Bus

A0

.

.

A15

.

Address Bus DecoderLogic 1

... ...

D0

D7

Data Bus

Program Instruction Flow

Figure 1.6 - Microprocessor System Data and Address Bus

To help us understand the role of the address bus, we look more closely at the

memory chips themselves. Figure 1.7 schematically shows a hypothetical memory

chip, which has storage for 16 bytes of information. Actual memory chips typically

store many hundreds of kilobytes and a correspondingly larger number of memory

access pins. You should observe that in our hypothetical chip of Figure 1.7, the bit

patterns we have shown inside are the same as our addition program from earlier

discussions.


Boolean

Circuits

for Address

Decoding

D7 D6 D5 D4 D3 D2 D1 D0

Memory

Internal

0000

00010010

00110100

.

.

1111

Addresses

Relative to

Chip

Selected Row of Data Switched to System Data Bus

MA3MA2

MA1

MA0

Chip Enable

Read/Write

0 0 0 0 0 0 0 1

110000000 0 0 0 0 0 01

0 0 0 0 0 1 1 1

0 0 0 0 0 0 1 1

.

Logic

Figure 1.7 - Schematics of Memory Chip Operation

The memory chip is composed of two functional sections - the Boolean decoding

logic section and the actual storage section.

The decoding section is responsible for controlling the transfer of data to/from

the computer data bus from/to a storage address in the chip. This access control is

based upon the status of the memory address pins (MA3..MA0), the Read/Write pin

and the Chip Enable pin.

The Chip Enable pin can be thought of as a locking device for the chip. In

order to use the chip, the Chip Enable pin must be set either high or low (depending

on the manufacturer's design). The Read/Write pin is used on RAM chips to define

whether data should flow into or out of the chip. Depending upon the high or low state

of this pin, data will be written to or read from the appropriate address location in the

chip. As an example, if the microprocessor in our hypothetical system is to force the

memory chip to place its third row of storage onto the data bus, then it would have to

set:

MA3 = 0

MA2 = 0

MA1 = 1

MA0 = 1

Read/Write = 1

Chip Enable = 1

thus accessing the third row in the memory chip.


The microprocessor controls the memory chip address pins and chip enable

pin/s, by setting appropriate lines on the address bus high or low. In other words, a

selection of address lines from the microprocessor is connected to pins on the memory

chips. These lines are selectively set or reset by the microprocessor in order to make

the memory chips respond in the desired manner. The Read/Write line of the memory

chip is tied to a corresponding driver line on the microprocessor.

The dilemma that immediately arises, is that if there are many identical memory

chips, connected to the address bus of a microprocessor system in an identical manner,

then all the chips will respond simultaneously to each request from the microprocessor.

This is clearly ridiculous, since it would imply that no matter how many memory chips

we have, we would only effectively have the storage capacity of one chip. Since it

would be equally ridiculous to have scores of specially designed memory chips, the

problem is overcome through the use of "memory mapping" techniques.

Each memory chip in a microprocessor system must have a unique connection to

the microprocessor address bus, otherwise a conflict occurs. This unique addressing is

achieved through address bus decoding logic, as shown in Figure 1.6. This logic can

be implemented through Boolean logic gates, as discussed earlier.

Let us now assume that two of the memory chips in the system shown in Figure

1.6 are like the hypothetical one shown in Figure 1.7. The following Boolean logic

could be used to decode the address lines for chip 1:

MA0 = A0

MA1 = A1

MA2 = A2

MA3 = A3

Chip Enable = X1

where:

X A A A A A A A A A A A A1 4 5 6 7 8 9 10 11 12 13 14 15= + + + + + + + + + + +


Memory chip number 2 in the system could have the following Boolean logic

gates for address bus decoding:

MA0 = A0

MA1 = A1

MA2 = A2

MA3 = A3

Chip Enable = A4 . X2

where:

X A A A A A A A A A A A2 5 6 7 8 9 10 11 12 13 14 15= + + + + + + + + + +

This arrangement implies that memory chip 1 can only be accessed (enabled)

when all microprocessor address lines A4 through to A15 are low. Otherwise chip 1

remains locked. Memory chip 2 can only be accessed when address line A4 is high

and lines A5 to A15 are low. Otherwise chip 2 remains locked. Table 1.7 shows the

effect that this has from the microprocessor's point of view. A number of such chips

could be selectively "mapped" so that to the microprocessor, all address locations from

0000 0000 0000 0000 to 1111 1111 1111 1111 can be accessed, with no two chips

responding to the same address.

Address Bus Value Memory Chip Accessed Memory Chip

Internal Address

0000 0000 0000 1 0000

0000 0000 0001 1 0001

0000 0000 0010 1 0010

0000 0000 0011 1 0011

.

.

.

.

.

.

0000 0000 1111 1 1111

0000 0001 0000 2 0000

0000 0001 0001 2 0001

0000 0001 0010 2 0010

0000 0001 0011 2 0011

.

.

.

.

.

.

0000 0001 1111 2 1111

Table 1.7 - Memory Map for Example System of Figure 1.6


The address bus differs from the data bus in the sense that data flow is

essentially uni-directional. Generally, the microprocessor is the master which sets or

resets selective lines on the address bus, and the other connected devices respond

accordingly as slaves. This is an important point. Also note that memory chips are not

the only devices that are "mapped" in microprocessor based systems. A number of

different chips and devices are controlled through the same mapping mechanism and

appear, to the microprocessor, as though they were nothing more than memory

locations.

In some microprocessor based systems, the same conductors are used for the

address bus and the data bus. The microprocessor multiplexes (switches) the lines

from one application to another. This saves considerable space on the system board.

Most realistic systems also have quasi-intelligent chips known as "bus controllers" that

are responsible for switching and resolving contentions on the bus system.

Now that we have seen how data is stored and transferred within a

microprocessor based system, we can examine what happens when our addition

program, from above, executes on such a system.

In order to run a program, a microprocessor must be primed with the starting

address of the first instruction. Let us assume that our program is stored in chip

number 2 of the hypothetical system, and that the first instruction is stored in the first

memory slot within this chip. A register within the microprocessor is used to store the

address of the current instruction to be executed. This is updated (incremented) as

each instruction is executed. The first instruction, according to our memory map, will

be at address 0000 0001 0000.

The microprocessor uses the address bus, and asserts the READ mode on

memory chips to force them to place their contents on the data bus. Both instructions

and data flow through the data bus into the microprocessor, where they are processed.

This is all "time-governed" by the microprocessor system clock input. Figure 1.8

shows the voltage waveforms on the data bus (which enter into the microprocessor's

data port) that make up our simple addition program.

The following is the logical sequence for the execution of the addition program

cited as an earlier example:

(i) Microprocessor sets address bus to 0000 0000 0001 0000 and asserts

READ line

(ii) Memory chip 2 sets data bus to 0000 0001(LDA)

(iii) Microprocessor sets address bus to 0000 0000 0001 0001


(iv) Memory chip 2 sets data bus to 0000 0011 (3)

(v) Microprocessor sets address bus to 0000 0000 0001 0010

(vi) Memory chip 2 sets data bus to 0000 0010(LDB)

(vii) Microprocessor sets address bus to 0000 0000 0001 0011

(viii) Memory chip 2 sets data bus to 0000 0111 (7)

(ix) Microprocessor sets address bus to 0000 0000 0001 0100

(x) Memory chip 2 sets data bus to 0000 0011(ADD)

The timing diagram of Figure 1.8 shows that information transfer along the data

bus is essentially parallel, with all 8 bits issued and arriving simultaneously at their

destination. Addressing information is also transferred in this parallel manner. The

actual mechanism for data flow in realistic systems is complicated by the fact that the

design needs to account for differences in chip speeds. This is generally achieved

through the insertion of "idle" or "wait" states.


Time

Time

Time

Time

Time

Time

Time

Time

LDA 3 LDB 7 ADD

Voltage on D7

Voltage on D6

Voltage on D5

Voltage on D4

Voltage on D3

Voltage on D2

Voltage on D1

Voltage on D0

Figure 1.8 - Data Bus Voltages as Addition Program Executes


1.6 Master-Slave Relationships and Interrupts

We have now seen how data is both represented and transferred, in parallel,

within microprocessor based systems, through the data bus. We have seen how the

microprocessor exerts control over other chips within the system, by selectively

enabling and disabling "Chip Enable" pins, through the system address bus. Up to

this point, we have assumed that all devices connected to such a system are passive,

and incapable of performing complex functions akin to those of the microprocessor.

This is in fact not the case.

Many devices that are mapped into the microprocessor system are semi-

intelligent in their own right. The chip devices that control the serial communications

port are a good example. These are called Universal Asynchronous Receiver

Transmitter (UART) chips and are used to transmit and receive data from equipment

that is external to the microprocessor system. Such devices require a degree of

autonomy in order to unload work from the microprocessor.

For example, the microprocessor may require data entering the UART from an

external system. There may be long and varying time intervals between the arrival of

data. If the microprocessor has to spend all its time interrogating (polling) such a

device to determine whether data has arrived, then there is little scope for the processor

to carry out normal program execution. This problem is overcome through the use of

"interrupts" and "interrupt programming". This is shown schematically in Figure 1.9.

Microprocessor System

Microprocessor Chip

InterruptPin

UART

Data Ready

DATA

External System

Figure 1.9 - Interrupt Methods for UART Control


Microprocessors generally have one or more interrupt pins that enable them to

provide other devices within the system a degree of autonomy. The microprocessor

can issue a task to another intelligent device and then continue with normal program

execution. When the intelligent device has completed the set task, it sets the interrupt

pin on the microprocessor either high or low(depending upon the processor).

When an interrupt occurs, the microprocessor can temporarily halt normal

program execution and save all relevant parameters, such as the address of the current

instruction, etc. The microprocessor then jumps to a new location in memory to

execute a special program (routine) which has been written to handle the situation that

has led to the interruption. Once the processor completes the execution of the interrupt

routine, it restores the parameters from its original program and reverts to normal

program execution as though nothing had happened.

This form of interrupt programming enables other intelligent devices, within the

microprocessor based system, to perform tasks without the constant supervision of the

processor.

It is important to note however that despite the additional degree of freedom

granted to devices, through interrupt programming, the "closed" computer system is

still very stable and free of conflicts. The microprocessor essentially co-ordinates,

enables and disables all the other devices in the system through its master to slave

relationship.

Under normal circumstances there is no possibility of a slave chip attempting to

place data onto the data bus at the same time as the microprocessor. Similarly,

conflicts on the address bus are not possible, since the microprocessor uses this as the

controlling mechanism for the slave chips and not vice versa.

This well controlled, conflict free, master-slave situation only exists because

individual systems are generally designed by a single, co-ordinating manufacturer.

However as we shall see in later chapters, when dealing with more than one system

and manufacturer, the problems of resolving conflicts during communication are

greatly increased.

35

Chapter 2

Computers And Control Systems Within

Manufacturing

A Summary...

Multiple-axis motion controllers. Computer Numerical Control Systems. Robotic

Control Systems. Programmable Logic Controllers. Computer Control of

Manufacturing Systems. Flexible Manufacturing Systems. Integration of Computer

Aided Design, Manufacture and Management Information Systems and Inventory

Control Systems (MRP).


♦ You need to understand about the manufacturing equipment, computers and

systems that need to be integrated through data communications.

♦ You would like to come to terms with the "intelligence level" of the various

devices that have to be integrated through data communications and

networking.

36 D.J. Toncich - Data Communications and Networking for Manufacturing Industries

2.1 The Range and Scope of Computers within

Manufacturing

Within any modern manufacturing organisation, computers may be used at a

number of different levels, including:

• Management / Financial Information Systems

• Production and Inventory Control / MRP / MRPII

• Software Simulation

• Computer Aided Process Planning

• Computer Aided Design and Drafting

• Control of Automated Mechanisms (Programmable Logic)

• Data-acquisition

• Machine Control Systems (Computer Numerical Control)

• Robot Control

• Continuous Chemical Process Control

• Production Line Control (In-line Transfer Machines)

• Flexible Manufacturing System Control.

Perhaps, in an ideal world, it may be reasonable to suggest that a single,

powerful, computer could perform all these tasks simultaneously. In such a system,

all the meaningful operating data about an entire factory could be centralised and

quickly accessed by any one of the active tasks. Since the entire manufacturing

system is encased in a single (closed) computer, software and data retrieval could

readily be standardised and optimised. Errors from external sources could be

reduced to a manageable level. Of course in an ideal world we could probably find a

computer flexible enough to perform all these functions efficiently. It would

naturally also come with an "iron-clad" lifetime guarantee that clearly stated that the

computer would never break down.

As the real world would have it, computers are only designed with a limited

range of applications in mind. The scope of activities that take place within a

manufacturing organisation is so diverse that it cannot, realistically, be implemented

through a single computer. Therefore, through the years of computerisation in

manufacturing, we have been endowed with an enormous and diverse range of

computers and computer controls. The architecture of these systems is often as

diverse as the functions that they perform. However, we have now come to realise

that the ability of all these computer applications to share data (or databases) is of

crucial importance to manufacturing, in order to:

Computers and Control Systems Within Manufacturing 37

• minimise times between work orders and production

• minimise inventory and stock levels

• minimise bottle-necking of parts / products in plant

• minimise production / product costs

• minimise design errors and transmission of design errors

• minimise overall response times to changing market demands

• maximise equipment utilisation

• maximise product consistency and quality

• maximise flexibility of production equipment

• prevent unnecessary (repetitive) human entry of data.

The solution then would be to somehow interconnect all of the diverse

computer systems within a manufacturing organisation through an "ether" that would

allow a wide range of applications to share information. In computer terms the

"ether" is referred to as a data communications network. When a network exists

within a relatively small area (under 1 kilometre say), then it is more specifically

referred to as a Local Area Network or LAN.

The ideal solution would be something like the one shown in Figure 2.1. It

illustrates a concept, referred to in data communications, as "Plug-in Compatibility".

In other words, a wide range of different (computer-based) devices that can all plug

into a central network or "ether".


CNC Machine 3 Robot 2 CNC Machine N

CNC Machine 1 Robot 1 CNC Machine 2

Communications Medium

Production Cell

Controller 1

Production Line

Controller

Production Cell

Controller N

Building 1

Supervisor

Building N

Supervisor

Workstation N

Process

Planning System

Inventory

ControlWorkstation 2

Financial

Computer

Computer Aided

Design System

Workstation 1

Figure 2.1 - An All-embracing LAN in Manufacturing


Plug-in Compatibility can best be compared to the power supply used in the

home. Power supply lines of fixed voltage and frequency (the bus) run throughout a

house, with a number of outlets (tapping points) located at convenient locations.

Ideally we choose to have more outlets than equipment in order to provide for future

expansion and flexibility.

Electrical appliances are designed with an "interface" to the domestic power

system. That is, their power supplies and plugs conform to a fixed standard of

voltage, frequency and plug design. We can then plug-in appliances to any outlet,

provided that they are compatible with the standard.

The obvious problem with the practice of designing systems that are "Plug-in

Compatible" is that in order for appliance manufacturers to produce products with a

given interface, the bus system must be standard and widely accepted. If every home

ran a different voltage and frequency power supply, then appliance manufacturers

would simply not find it profitable to produce interfaces for every possible

combination.

The power supply system requires only a very simple standardisation (voltage,

frequency and plug design) in order to make equipment manufacturers conform. And

yet, as we are all aware there is no worldwide standard for general purpose power

outlets. Every country has its own standard. However, the problems of non-

standard, power supply systems, within a given country, were addressed at a very

early stage by government bodies, so that "Plug-in Compatibility" could be achieved.

The numbers of parameters that have to be defined and standardised in terms of

data communication and computer networking, between intelligent devices, are

enormous in comparison to those associated with power supply. Additionally, we

have a situation where data communications and networking have arisen in an ad-hoc

manner, largely driven by computer equipment manufacturers with little or no

Government intervention in the standardisation process.

We will make a detailed examination of the problems associated with

achieving "Plug-in Compatibility" for manufacturing in subsequent chapters. For the

moment however, it is necessary to accept that it is desirable, in principle, for all

intelligent devices in a factory to be able to exchange information with all other

intelligent devices. The practicality of this goal depends largely upon the

architecture and flexibility of the intelligent devices within the system. We shall

now examine some of the most commonly used devices and systems within

manufacturing and assess their communications capabilities and requirements.


2.2 Programmable Logic Controllers

Programmable Logic Controllers (PLCs) are perhaps the most prolific of all

modern industrial control systems. They are used for a wide range of applications

and are very diverse in their capabilities. A PLC is shown schematically at its

simplest level in Figure 2.2.

Current

Inputs

Voltage

Inputs

Voltage

Outputs

Current

Outputs

Power

Transistor

Front-End

Micro-Processor

& Digital

Circuitry

Power

Transistor

Back-End

Figure 2.2 - Schematics of a Programmable Logic Controller

PLCs use power-transistor technology, in combination with microprocessors

and digital circuitry, in order to produce a specialised computer system for high

power switching and control. The power transistor front and back ends, are used to

buffer the low-voltage microprocessor computer circuitry from high power industrial

inputs and outputs. PLCs therefore provide the ideal combination of a small

computer system together with interfacing to the industrial environment.

Initially, PLCs were introduced to simply replace the dated relay-ladder logic

systems used to implement Boolean functions on industrial control signals. The

following is a typical PLC function:

"If Input A is high and Input B is greater than 50 volts, then delay 10 seconds

and then set Output C to High."

The inherent ability of PLCs to perform such functions makes them ideal for

sequential control functions where (say) a number of hydraulic and pneumatic

actuators and sensors have to be governed. For example, the opening and closing of

safety doors or the switching of fluid pumps in a production system.


Modern PLCs are relatively inexpensive items, which are industrially rugged in

design and extremely modular in structure. It is commonplace to buy a Central

Processing Unit PLC, together with any number of bus-connected Input/Output (I/O)

modules. This allows both simple and complex machines to be based upon the same,

basic PLC unit. An Original Equipment Manufacturer (OEM) may choose to design a

machine using a basic PLC system (with say 10 to 20 inputs and outputs) and then

purchase expansion I/O modules as customer, design requirements change.

Programming languages for Programmable Logic Controllers are as diverse as

the controllers themselves. Originally, PLCs were only programmable in "ladder-

logic diagrams" that are a pictorial representation of Boolean circuits coupled with

delay and timer elements. This seemed to be a logical step, since it meant that

designers, who were used to designing relay circuits, could simply transfer to design

using PLCs. However, as people grew to realise the enormous range of design

applications for these programmable devices, it became less and less attractive to use

the now dated, ladder-logic, diagrams.

Many PLCs were sold with specialised implementations of the BASIC

programming language as a built-in feature. This allowed a much more sensible and

structured approach to system design to be used. It was also a logical step, since the

proliferation of Personal Computers meant that more and more people were

comfortable with the concept of programming in a language, rather than using

diagrams. As with most technology items, the power and flexibility of the PLCs has

grown to meet the ever-increasing range of activities for which they are used. PLCs

are now available with specialised "C" or "PASCAL" compilers, that allow complex

program development for control applications.

High-resolution, graphic display screens (akin to those available with PCs and

Workstations) are now commonplace on Programmable Logic Controllers. Some

PLCs have also bridged the gap between computer systems and industrial controllers,

through direct connections into the internal bus of some mini-computer systems.

This is referred to as "back-plane connection" and is important because older PLCs

had to be connected to other computer systems through relatively slow serial

communications links.

Traditional workstations, PCs and mini-computers are still a more suitable

platform on which to perform large calculations than the PLCs themselves.

Therefore it is often necessary for a process control computer to do the "number-

crunching" while a PLC does the data-acquisition. In continuous process control

applications, serial communications links between a PLC and host computer are too

slow to enable closed-loop response times to be achieved. Until the advent of back-

plane (bus) connected PLCs, this meant that either a powerful PLC had to do both the

number-crunching and data-acquisition or, that a mini-computer had to perform both

tasks. Neither was an optimal solution.


Many PLCs however, do not require a high-speed, back-plane connection to

the outside world, and can be remotely linked to other computers through a serial

communication link. A number of PLCs have a communications task (program),

running concurrently with other control programs, so that a remote device can

supervise the PLC through the serial link.

The programming languages on some of the more sophisticated PLCs will

allow a user to develop serial communications programs, which can link the PLC to

the outside world. A wide range of PLCs can also be purchased with special network

interface cards and modules that will allow them to be linked into a variety of

industrial Local Area Networks. Simple PLCs on the other hand, may be equipped

only with specialised development languages and have minimal access to the outside

world, through data communications links.

The criteria typically used to select a PLC for a particular application include

the following:

• PLC Programming Language

• Number of Inputs and Outputs (I/O capability)

• Expansion Capability

• Processor Execution Speed

• Modularity of Design

• Ruggedness of Design

• Capacity for Integration with other systems through:

• Serial Communication

• Back-plane (Bus) Communication

• Local Area Network Communication.

Overriding these technical factors are always the considerable political (social)

factors, which cause a company to choose a PLC vendor based upon conformance

with other systems already installed in a plant. This reduces the need for

maintenance personnel to become familiar with a wide range of programming and

implementation techniques.


2.3 Multiple Axis Motion Controllers (CNC and Robotics)

Many machines and devices within manufacturing consist of little more than a

number of servo-motor driven axes, which are used to either position an end-effector

(tool) or a work-piece so that the work-piece can be either moved, machined or

processed. The most common examples of this are Computer Numerical Control

(CNC) machine tools and robots.

Despite the obvious physical differences between, say, an articulated welding

robot and a CNC milling machine, the principles behind the control systems are

essentially similar. The schematics of CNC and robot control systems are shown in

Figure 2.3.

Supervisory Controller

(Executing Program)

Axis Controller

Servo-Drive

Controller

Servo

Motor

End

Effector

Position Feedback

Velocity Feedback

Voltage

or Current

ReferenceVelocity

ReferencePosition

Position Transducer

MechanicalCoupling

Figure 2.3 - Schematics of an Axis Control System

The supervisory (co-ordinating) controller (processor) in robotic and CNC

systems is responsible for a number of simultaneous activities including the user

(system) interface and part program parsing and execution. As each step (block) of a

part program executes, the supervisory controller passes down positioning

information to the axis control computer.


The axis control computer is responsible for achieving the desired position,

using appropriate acceleration and deceleration curves. It does this by sending

reference velocities to the servo-drive controller, on the basis of the actual position

that has been achieved (a negative feedback loop).

The relationship between the servo-drive controller and the servo-motor is

dependent upon the type of motor in use. In d.c. systems, the servo-controller varies

the current to the field windings of the motor. In both synchronous and

asynchronous (induction) motor, variable speed a.c. systems, the servo controller

supplies the armature of the motor with a variable frequency supply voltage.

The transducers used to provide velocity and position feedback vary according

to the application. Commonly, shaft-mounted tacho-generators are used to provide

velocity feedback and linear resolvers or pulse-code transducers provide position

feedback.

The processors used in such control systems are relatively powerful devices,

capable of running multiple programs simultaneously (multi-tasking). For example,

the processor acting as the axis controller, may be capable of co-ordinating 5 or 6

axes simultaneously. Depending upon the complexity of the system, the axis

controller and supervisory functions can even be individual tasks running on a single

processor.

Both CNC and robot control systems tend to be very specialised in their design.

They are optimised to achieve multi-axis control, with minimum user programming

and hence the languages that they use tend to be somewhat restrictive.

For historical reasons, related to early hardware limitations, CNC machines are

traditionally programmed in a "G-Code" language. This dated system provides a user

with a number of sub-programs, commonly prefaced with either a "G", "F", "S", or

"T" and suffixed with a subroutine number or parameter. These facilitate the

movement of a cutting tool through a predefined path; the selection of a cutting tool

and so on. However, few (if any) of these languages will allow a programmer to do

more than this.

G-Code languages were never intended to provide the user with routines for

accessing various aspects of the machine controller itself and for interfacing it to the

outside world. These features, which are now both desirable and important, are

difficult or impractical to implement on CNCs. For example, with traditional CNC,

it is often difficult to display user programmed screens as a part program executes.

Further, it is generally not possible to access the serial communications facilities of a

CNC through the G-Code language itself.


CNC designers often attempt to augment the limited features of the G-Code

languages by running additional (concurrent) tasks on the CNC. For example, many

CNCs have programs, designed to handle serial communications and remote

commands, running as tasks, while a part program executes. This type of task is

referred to as a Direct Numerical Control or DNC task/facility. It generally enables a

host computer to remotely control a CNC machine through a serial link. There are

other tasks, such as concurrent, graphic information displays, which are also added

by a number of manufacturers.

The deficiency with this form of controller architecture is that it provides a

closed (black) box to the end-user. There is normally no mechanism by which an

end-user company can re-program it in order to change the graphics displays, or the

way in which serial communication occurs. So, while CNCs provide great flexibility

in terms of cutting and shaping materials, they generally provide very little flexibility

in terms of tailoring the user environment. This is an important point to note in

regard to the ability of CNC systems to be linked up to other devices.

Robot controllers are often better than traditional CNC systems in terms of

their programming flexibility. Robot controller technology evolved at a later (more

opportune) stage of computer development than CNC. Unlike CNC machines,

robots seldom, if ever, work as devices in total isolation from other systems. They

are generally linked to other computer controlled or logic controlled mechanical

systems. For example, a spray-painting robot must be linked to the production line

that feeds it with work-pieces for painting - otherwise there can be no inter-locking

between line movement and robot cycles.

It is far more difficult to categorise the capabilities of robot controllers,

because they are far more diverse in architecture than CNC systems. Some robot-

controllers can be programmed in PASCAL or "C" in the same manner as any normal

computer system. These systems provide users with a high level of access to the

internal hardware of the controller itself. This makes such controllers more

amenable to interfacing with the outside world.

Some, "less sophisticated" robot controllers are analogous to CNCs and can

only be programmed in restrictive, specialised, movement languages (similar to

proprietary G-Codes). These systems suffer from the same interfacing disadvantages

as CNC systems. That is, unless a remote-control communications task is available

to run on the controller, then it is not possible to provide an intelligent interface to the

outside world.


CNC systems and robot controllers generally come with built-in Programmable

Logic Controllers, usually of specialised and complementary design. The PLCs are

integrated into the CNC or robot control system, under the control of the main

processor. They are used to control a range of sundry functions requiring high

voltage or current switching. For example, on a CNC machine, the internal PLC may

control the switching of coolant pumps, the opening and closing of doors, etc. On a

robot, the PLC may control the opening and closing of grippers and the switching of

inter-locked equipment. The inputs and outputs of PLCs on both robot and CNC

systems are accessible from within the robot programming language or G-Code

programming language. This scheme is shown in Figure 2.4.

Inputs

Outputs

CNC

or

Robot Control

Integrated

Purpose-Built

PLC

Figure 2.4 - Integrated PLC Control of High Power Peripherals

Both CNC and robot controls are generally provided with a "hard-wire"

interface to the outside world. This provides a simple means of integrating the

devices into automated systems. In a hard-wire interface, spare inputs and outputs

from the integrated PLC are selectively connected to external devices so that they

can be inter-locked. Program execution is then made dependent upon the condition

of inputs.

For example, if we wished to use a robot to feed a CNC machine with work-

pieces, a hard-wire inter-locking arrangement, such as the one shown in Figure 2.5

may be used.


CNC

Machine

Output x

Input y

Input m

Output n

Robot

Figure 2.5 - Inter-locking a CNC Machine to a Robot

In such a system, the CNC machine program should start execution as soon as

the robot has loaded a part (ie: when the robot program has been completed). The

robot should unload a part when the CNC machine program has ended. This can be

achieved by the robot setting output number "n" high when it completes a program

(last executable line of code) and the CNC machine setting output "x" high when it

completes a program (last executable line of code). The first lines of code on both

the CNC and robot are to wait for inputs "y" and "m", respectively to go high before

continuing. Figure 2.6 shows the form of the two inter-locked programs:

If Part Count > 0 then

wait until input m = 1

If Part Count > 0 then

Unload Part

Load New Part

Set Output n = 1

Increment Part Count

Delay

Set Output n = 0

Robot Program

CNC Machine Program

Wait until Input y = 1

Part Program

Set Output x = 1

Delay

Set Output x = 0

Figure 2.6 - Program Structure for Interlocking Robot and CNC


Note that the robot program needs a "flag" variable to distinguish the first part

from the subsequent parts. This is so that it does not wait for a "finished" signal from

the CNC machine before the machine has been fed with a part.

This simple, hard-wired form of communication and control has some severe

limitations. Firstly, neither of the devices know what the other is doing, while the

other device is executing a program. For example, if an unexpected condition arises

in the system (say the robot arm positions a part incorrectly or else fails to pick it up),

then the CNC machine will execute its machining program without knowledge of

the error status. This type of situation could damage the robot arm, the work-piece or

the CNC machine itself.

The inability of hard-wired communications to handle abnormal (error)

situations, by intelligent interrogation of inter-locked devices, can only be overcome

through over-engineering of the mechanical systems to increase safety factors. The

more appropriate solution however, is for devices to be able to exchange important

status information during program execution (not just before and after) through

intelligent communications links.


2.4 Linking Computer Aided Design to Manufacture

Complex CNC machine programs are seldom developed on the machines

themselves. They are either developed off-line on a PC based, ASCII word-

processor or on some form of Computer Aided Design system. In either event it is

necessary to down-load the CNC programs, developed on a remote (host) computer

system to the CNC machine. It should also be noted that the CNC machines

themselves are seldom equipped with low cost, bulk program storage facilities (such

as the hard-disks found on computers). Therefore, for long term storage of programs,

developed or modified on the machines, it is also necessary to be able to up-load the

files to a host computer.

In the past, program transfer and storage was achieved by the mechanical

punching a paper (mylar) tape and physical transfer of the tape from machine to

machine. However, file transfers between host computers and CNCs are now most

commonly performed through a (serial) data communications link, such as that


Serial Data Link

Host Computer

CADWord

Processor

BulkStorage Media

CNC Machine

Figure 2.7 - Serial CAD to CAM Links

Maintaining the integrity of program files is of crucial importance in both the

up-loading and the down-loading processes. Errors in CNC program files could

result in damage to:

• cutting tools

• the machines themselves (servo-drives, etc.)

• valuable work-pieces.


This damage can be caused by corruption of program variables, such as feed-

rates, positioning commands, tool-selection codes, etc., during file transfer.

Transmission of large quantities of data through cables (whether conducting or

optic fibre) is by no means an error free proposition. Communications are subject to

noise, Electro-Magnetic Interference (EMI), synchronisation and timing errors on

transmitting and receiving equipment. We accept that statistically, out of a large

number of transmitted bits, some will be incorrect.

If data corruption causes visual damage to the machine or work-piece then we

may immediately suspect the cause. However, since CNC machining is concerned

with achieving complex shapes and accuracy in the order of microns, problems due

to corrupted program files may not always be conspicuous or easy to trace until it is

too late. For these reasons, we need to:

(i) Minimise errors occurring during transmission

(ii) Provide a mechanism for detecting errors

(iii) Check all incoming data

(iv) Detect and/or correct any corrupt information through re-transmission

procedures.

The first objective can most readily be achieved by selecting an appropriate

communications "medium" in which noise and EMI are minimised. Although

shielded, "twisted-pair" cables and co-axial cables are commonly used as

communications media, they are both susceptible to EMI. Optic fibre systems, which

use light pulses rather than electrical signals for transmission, are now a preferred

alternative, since they are immune from EMI.

Objectives (ii) to (iv) can all be realised by establishing a set of rules by which

both the receiving and transmitting devices can check and correct for errors in data

transmission. This set of rules is referred to as a "communications protocol". Most

modern computer systems can be programmed to respond to any protocol. However,

we again note that many CNC machine controllers do not have this programming

flexibility. For this reason, CNC manufacturers often equip their controllers with

built-in communications protocol software (DNC) to perform this task. In these

situations, the software on the host computer is tailored to match the protocol of the

CNC. Since each CNC manufacturer generally has a unique communications

protocol, the establishment of secure, error-free links becomes a time consuming and

expensive proposition.


Some CNCs have neither a built-in protocol nor the architecture upon which

this can be embedded. Such controllers are often equipped with only a "file dump"

facility that operates through the serial communications port. The "file dump" allows

CNC controllers to either read or write an entire file, from/to a host computer. In

order to interact with the CNC file dump facility, a host computer runs a piece of

software referred to as a "terminal emulator", which performs the complementary

(read or write) procedure to the CNC. However, the file dump technique makes no

provision for error detection or correction. It is therefore not possible to guarantee the

accuracy of files that have been dumped from a host system to a CNC (and vice-

versa). "Dumped" files must therefore always be checked manually.


2.5 Manufacturing Systems

A number of different, metal-cutting, manufacturing systems are used in order

to satisfy the performance criteria demanded by a wide range of industries, including

workshops, automotive and aerospace manufacturers. The common system

configurations are shown in Figure 2.8, which gives an indication of how each

system fits into annual volume / variety regions in the production environment.

1 10 100 1000

1

10

100

1000

10000

100000

FMS with CNCs, AGVs & Robots

F.T.L.

DedicatedSystems

Stand-alone CNC

RobotFed CNC

Part Variety

Annual Volume

Figure 2.8 - Realms of Metal-Cutting Manufacturing Systems

The systems mapped onto the graph in Figure 2.8 have differing performance

characteristics and also place different demands upon the data communications used

by their control systems. We shall now examine the structure of each of the

integrated systems and the way in which communication between devices occurs.


The dedicated, in-line transfer machine is shown in Figure 2.9 and is a high-

volume, low part variety system. It is composed of a number of machining stations

and a transfer conveyor. Each of the machining stations is designed and tooled for a

specific application. For each station, tools are loaded into an induction motor

driven, multi-spindle cutting head, which has an advance and retract motion. When a

work-piece comes into position within a machine, the head advances for a fixed

period, then retracts, to allow the work-piece to move down-line to the next

destination. Each machining module is generally controlled by a PLC, which is

hard-wired to its sensors, coolant pumps, etc. These machining modules are

generally not user-programmable devices. They are pre-programmed to perform

only a fixed task.

PLC PLC PLC

PLC PLC PLC

PLC

Transfer Mechanism(Conveyor)

Supervisory PLC

DedicatedMachining Modules

Figure 2.9 - Schematic of Dedicated, In-Line Transfer Machine

The transport mechanism for in-line transfer machines is also a PLC controlled

device. In simple systems, the transport mechanism controller is also the system

controller, and is hard-wire inter-locked to the dedicated machining modules. In

more complex systems, a separate, high powered PLC is used to coordinate the

running of the system and drive mimic-panels and graphic information displays.


In transfer machines, where individual modules are controlled by a range of

PLCs, produced by different vendors, it is common practice to simply hard-wire from

the supervisory PLC to other PLCs in the system. However, in a single PLC vendor

environment a number of proprietary solutions are generally feasible. Some of these

solutions allow PLC data buses to be inter-connected through a back-plane system

for information exchange. Other solutions allow for interconnection of PLCs

through high speed Local Area Networks. Regardless of which system is chosen, the

objective is for the supervisory PLC to implement sequential control over the system

through input/output inter-locking with individual module controllers.

Rotary transfer machines are analogous to in-line transfer machines except that

parts transfer, from machine to machine, occurs through via an indexing mechanism

in a circular path. The control principles however are almost identical.

The hard-wire, inter-locking, communications techniques, shown in Figure 2.9,

for dedicated systems are generally adequate because:

• individual machining modules are relatively simple devices, executing

simple, fixed, programs

• the amount of information which any, one machine can feed back to a

supervisor is comprised of little more than off/on limit-switch status

• the supervisory controller does not need to change programs on

individual modules in the system.

Dedicated manufacturing systems, of the type shown in Figure 2.9, fulfil a vital

role in the high-volume production of a small variety of parts. However, in order to

vary the type of part that passes through such a system, it is necessary to manually re-

tool each of the machining stations. If the type of part to be produced is radically

altered, then such systems require major re-engineering, or as is often the case,

complete replacement. Since these systems are designed for the production of a

specific item, their cost and production life are calculated on the basis of anticipated

product life.

Increased competition in manufacturing, coupled with increasing consumer

demands for new products, mean that product life-spans are decreasing. The cost

effectiveness of dedicated production systems is therefore diminished accordingly.

In addition, companies driving towards export competitiveness with products now

find that they need to produce a "family" of products, tailored to specific global

markets. These requirements engender a need for flexibility in production systems.


Flexibility in production systems is achieved through the ability of individual

modules in those systems to respond to changes in part variety. This is in turn,

achieved through the use of fully programmable machining modules and flexible

parts transport techniques.

It would be sensible to suggest that flexibility in manufacturing could be

achieved by taking a dedicated system, such as that shown in Figure 2.9, and

replacing some or all the fixed machining modules with CNC machines. This is

common practice, and the result is referred to as a "Flexible Transfer Line" or FTL.

However, it should be noted that the cost ratio of a CNC machining module to a

dedicated module is in the order of 10 to 1. It is therefore not economically feasible

to replace, say 50 dedicated machining modules in a fixed system with 50 CNC

machines. Generally, each CNC machine uses automatic, programmable tool

changing in order to perform the functions of a number of dedicated modules. Thus,

production flexibility is increased but throughput is decreased in what becomes a

normal trade-off situation.

While it may be common in a dedicated production line to have 50 to 100

machining stations, a flexible production system may have only 5 to 10 CNC

machining stations, performing the same net function at a lower production rate.

However, the benefits in flexible production become self-evident when production

needs change, because flexible systems can respond very quickly to new demands,

with minimal human intervention.

The transfer line arrangement of Figure 2.9, whilst very fast, does not provide

the optimal transport mechanism for maximum production flexibility. Robots,

Gantry Robots and Automated Guided Vehicles (AGVs), on the other hand, provide

a high degree of transportation flexibility at the cost of production throughput. All

three devices use relatively sophisticated control systems. AGVs in particular,

commonly use a powerful PLC as a Constant System Monitor (CSM), which governs

the positions to which vehicles move.

The Flexible Manufacturing System (FMS), designed for a very wide variety of

parts, is more likely to resemble the schematic shown in Figure 2.10, rather than that

of 2.9. The intelligence level of each module (machine) within the system is much

greater than that within the dedicated production line. CNC machines in

sophisticated FMS environments may even be augmented with specialised robots to

transfer tools from AGVs to machine tool carousels and vice-versa.


In a complex FMS environment, where a number of different part-types may be

within the system simultaneously, the controller is required to:

• co-ordinate the flow of work-pieces of differing types, from one machine

to another, based upon a rolling schedule

• activate different part programs on CNC machines, as required by the

part-types present in the system

• down-load part programs to CNC machines as required by the machines

• co-ordinate (inter-lock) the role of the work-piece transport system with

the operation of CNC machines.

Some of these functions can be (and sometimes are) implemented through the

hard-wire inter-locking of devices to the FMS controller, which can be a powerful

PC, PLC, workstation or mini-computer. However, FMS control is more

appropriately achieved through data communications between the controller and the

other computerised (intelligent) modules within the system.

In section 2.3 it was noted that there are severe limitations with hard-wire inter-

locking of computerised machinery to a system (cell) controller. The system

controller is unaware of the status of computerised slave devices, while they are

executing their programs. In a complex, FMS environment, the system controller

must have the capacity to interrogate other equipment whilst programs are running.

This gives the controller access to a wide variety of information regarding the status

and error-conditions of machines, thereby allowing for intelligent decision making in

the control algorithm.

Simple, hard-wiring techniques only allow devices to exchange one piece of

data per wire (say an on/off state or transducer voltage). They do not allow one

computer to transfer data files to another computer. This of course means that down-

loading of CNC machine programs from a supervisory computer cannot be achieved

with the hard-wired system alone. In simple hard-wired, FMS systems, machine

programs are normally resident in the local memories of each machine during a

production run. Programs are generally down-loaded (or file-dumped) to machines,

via data communications links, prior to the start of automatic FMS control.

One of the major benchmarks of FMS is the ability to tolerate and reconcile

fault conditions. Each module in the system performs a complex task and is

therefore subject to a large number of possible faults or errors. It is costly for an

FMS controller to shut down an entire system, simply because one machine has

developed a fault. The objective is for the controller to attempt to maintain orderly

and safe system operation even under certain fault conditions.


CNC

CNC CNC

CNC

AGV

AGV

AGV

FMS Controller AGV Controller

ProgrammableMachining Modules

Figure 2.10 - Schematic of a Flexible Manufacturing System

If we consider a scenario where a CNC machine in an FMS system stops before

its pre-defined cycle is completed, due to an internal error, then there may be a large

number of causes. The action that the FMS controller can take to remedy the

situation must be programmed on the basis of information available from the CNC.

For example, the CNC may not have executed its program at all, because the

program file may not exist in the machine's memory. The solution is for the FMS

controller to down-load the file and again attempt to remotely start program

execution. Alternatively, the CNC machine may have experienced a spindle-motor

overload, in which case the FMS controller can only set up an external alarm and

wait for human intervention.

Hard-wire communications do not provide an adequate means of conveying

complex status information from a machine controller to a system control computer.

This can only be achieved through more sophisticated data communications

techniques.


A Local Area Network, similar to the idealised model of Figure 2.1, is the

mechanism required in order for intelligent machines to communicate with

supervisory systems, such as the FMS controller. In such a system, a supervisory

computer can theoretically interrogate any other intelligent device at any time for

status information. If an error exists, then the supervisor can determine the cause in

the same way that a human would, and thereby attempt fault correction. Local Area

Networks are now commonly used to link supervisory computers to slave devices in

proprietary FMS systems (where equipment is essentially single-vendor).

In the past, the lack of network standardisation has made it difficult to realise a

LAN in a multi-vendor FMS environment. However the push towards industrial

networking standards by automotive manufacturers has made even this problem

surmountable.

59

Chapter 3

Principles Of Data Communications

A Summary...

Basic concepts of computer to computer communications. Models for

communications links and problems with long distance communications. Cross-talk

in parallel conductors. Extension of internal communications concepts to external

communications (parallel communications). The Centronics and IEEE-488 (GPIB)

communications ports.


♦ You need to understand the basic concepts associated with making computer-

based devices communicate with one another

♦ You need to understand the physical problems and limitations of the

conductors used in communications

♦ You need to learn the basics of communications "protocols"

♦ You would like to come to terms with parallel communications and hardware

hand-shaking.


3.1 Eight Fundamentals of Computer to Computer

Communication

In order for two, computer-based devices to communicate with one another,

even at the lowest level, a number of fundamental criteria must be satisfied:

(i) A "physical" link between the two devices must be established. This is referred

to as the transmission "medium" and may be realised through conducting cable,

optic fibre cable or through electromagnetic wave propagation at radio, micro-

wave or millimetre wave frequencies.

(ii) Both devices must use the same representation for binary data on the external

communications link. For example, both devices may need to accept that a

binary "1" is represented by voltage or current level "A" and binary "0" is

represented by voltage or current level "B" on the link.

(iii) Both devices must use the same physical reference level with which to interpret

data on the communication link. For example, if voltage is used for signal

representation then a receiving device "X" must measure voltage on the link

with respect to the same reference voltage that a device "Y" uses to transmit.

(iv) If transmitted bit streams represent alpha-numeric characters, then both devices

must interpret the characters in the same way. For example, if one device

transmits bits representing ASCII characters, then the receiver must decode the

bits as ASCII characters and not as EBCDIC characters.

(v) The transmitting device must actively run software that sends data through its

communications port and the receiving device must actively run software that

reads in data through its communications port. The software must be co-

ordinated so that transmission does not occur until the receiving device is ready

to handle incoming data.

(vi) The transmitting device must not send out data at a rate which is too high for

the receiving device to handle.

Principles of Data Communications 61

(vii) There must either be some pre-defined programming of the receiving device, so

that it always handles incoming data in the same way, or the instructions for the

handling of data must be sent by the transmitter, with the data. For example, a

printer directly outputs all characters that enter its port, unless they are

identified as special strings, which command the printer to perform a special

function.

(viii) If there is any possibility of the receiver being unable to handle the rate of

incoming data, because of the time it has to take to process that data, then there

must be some form of "hand-shaking" implemented. This should enable the

receiver to signal the transmitter to stop and re-start transmission at any time,

thereby preventing the loss of data.

These fundamental criteria may appear to be self-evident, but they are

frequently mis-understood or not understood at all. Unless all of the above

conditions are met, then there is no scope whatsoever for sensible data transfer to

occur. You should therefore look upon these criteria as the 8 prerequisites of data

communications.

The next question to be examined is, whether or not error-free data

communications can be achieved by meeting only these 8 criteria. The answer to this

is no. Satisfying the above criteria will allow data communications to take place, but

much more work needs to be done in order to provide links that are both bi-

directional and reliable.


3.2 Resolution of Conflicts in Communication - Protocol

Internal data communication within a single computer system is very well co-

ordinated and synchronised. Devices are specially selected and integrated into a

system to perform in a unified and ordered manner. Regardless of the autonomy of

any one device or chip, within a computer system, a Central Processing Unit

(microprocessor or processor board) is responsible for supervising the activities of all

other devices. Hence a master-slave relationship exists and provides a stable

platform for co-ordination of data transfer.

Once we decide to provide data communications outside the shell of a single

computer then many of the luxuries of internal communications are lost. We face an

environment of multiple vendors, differing electrical interfaces and differing forms of

data representation. Moreover, we often have two equally intelligent devices that

cannot automatically be configured into a master to slave relationship.

Within a single computer system, we have a situation where many of the

devices (chips) are passive and need to be activated by the CPU in order to transmit

data. Conflicts for use of the transmission media do not arise. However, when two or

more computers wish to communicate, then it is the human user (system designer)

who must ensure that conflicts for use of transmission media are resolved through

appropriate hardware and software.

Within a single computer we generally have a sealed system, where the

likelihood of fatal transmission errors is minimised by the absence of human

intervention. If a device, such as a memory chip, fails within a computer then a fatal

error occurs and the computer may completely lock-up. In an engineering control

environment, this is probably more stable than a situation where a computer mis-

interprets data from an incorrectly functioning remote device and acts inappropriately

upon that data. It is therefore essential that when two, or more, computerised devices

communicate with one another externally, they can react to errors caused by external

(remote) equipment. Typically, the sorts of errors that can arise are:

• the transmission medium can be physically broken

• the remote computer may be switched off or inoperative

• the transmission medium may be subject to electro-magnetic interference

• the remote device may attempt to transmit on the same transmission

medium at the same time as the local device.


None of the errors, listed above, can be corrected by solely complying with the

basic communications criteria outlined in 3.1. Therefore, in order for the normal

process of error detection and correction to take place between communicating

devices, the software and hardware on all computerised devices must be made to

adhere to a common set of rules. These rules outline the methods for data

transmission, error detection, resolution of conflicts for use of the transmission media

and so on. When combined with a specification for the fundamental communications

criteria of 3.1, the total set of rules is referred to as a "communications protocol".

At this point, you may think "so far so good", but where can I find this set of

rules for communications, so that I can interconnect any two, computerised devices?

Needless to say, there is no universal communications protocol for computer

communication. There are countless numbers of specifications and protocols, some

proprietary to computer manufacturers, others evolved from historical tele-type

transmission techniques and still more that have been generated by various

professional computer bodies around the world.

There is no question of one, particular protocol being universally "better" than

all the others. Individual protocols have strengths and weaknesses, primarily because

they are designed for specific applications and specific areas. For example, "Brand

X" mainframe to "Brand X" mainframe office communications or PLC to PLC

factory communications, etc. The real problem is that even where communications

requirements are such that it would be sensible to use the same protocol to

interconnect similar devices, the multi-vendor environment has made this difficult.

For example, Brand X office computers cannot simply be "plugged into" Brand Y

office computers, even though both are designed to perform a similar task, are

essentially similar devices, transfer similar data and live in a similar environment.

We now look, qualitatively, at the way in which protocols work in regard to a

simple, one-to-one, computer to computer link (a point to point protocol). Figure 3.1

shows the link. Let us say that we wish to transfer an ASCII file from device 1 to

device 2. Let us also assume that the physical aspects of the link protocol have

already been matched. That is, both devices satisfy common mechanical interfaces,

voltages, binary data representation, etc. How does a protocol enable us to reliably

transfer data between from one device to another?


Computer BasedDevice 1

Computer BasedDevice 2Transmission Medium

Figure 3.1 - A Point to Point Link

There are a number of phases that both devices must pass through in order to

perform the common communications function of file transfer (from device 1 to 2).

These phases ensure that the software on each device is structured to correct for

errors or inconsistencies from the corresponding, remote device. The rules for each

of these phases are clearly defined by a protocol and typical phases are as follows:

(i) Establishment of Link

Device 1 checks to see if Device 2 is present on the link by sending a specific

"enquiry" message. If the link is active and device 2 is active then it should

respond by sending back an "acknowledgement" message. Device 1 must track

the time that device 2 takes to respond. If device 2 does not respond within a

time interval (defined by the protocol) then device 1 assumes that the link is not

active. This is called a transmission "time-out" error.

(ii) Issue of a Command and Command Qualifier

Device 1 sends device 2 a message, in a predefined format, which tells device 2

that a file is to be transferred. As a qualifier within the message, device 1 tells

device 2 what to do with the file. For example, device 1 may tell device 2 to

place the incoming file onto disk storage, with the file-name "FRED".

(iii) Acknowledgement of a Command

If device 2 has correctly received the command and qualifier from device 1,

and is capable of carrying out the command, then it sends device 1 an

acknowledgement message. The acknowledgement message tells device 1 that

it can now proceed with further action needed to fulfil the command. If device

2 is unable to act upon the command from device 1, then it must respond with

an error message. An error could occur on the receiver if, for example, the disk

on which the incoming file is to be stored, is already full. The error response

message would tell device 1 that it should not proceed with its proposed course

of action.


(iv) Dissection of Messages

All messages, command and otherwise, must be broken down into packets of

manageable size for transmission. Thus if an error should occur in a packet,

then only that packet needs to be re-transmitted (and not the entire message).

Therefore, when device 1 wishes to transfer a large file to device 2, the file is

broken up into packets and transmitted packet by packet.

(v) Error Detection and Correction

When device 1 sends a message packet to device 2, it performs a mathematical

calculation (manipulation) on every unit of data transmitted. This calculation is

transmitted to device 2 immediately after the message. Device 2 performs

exactly the same mathematical calculation on its incoming data as device 1.

Device 2 also reads in the calculation sent by device 1 and compares it with the

local calculation. If the two calculations provide an identical result, then it is

assumed that the incoming message was not corrupted on the link. Device 2

can then issue a positive acknowledgement to device 1 to indicate that it is

ready for the next message. If the two calculations are inconsistent, then it is

assumed that incoming data has been corrupted, and device 2 issues a "negative

acknowledgement" message to device 1, which indicates that the previous data

message must be re-transmitted.

(vi) Termination of Transmission

Device 1 transmits a file, piece-wise, ensuring that each packet is correctly

received by device 2, using the technique described in (v). After the last piece

of the file is transmitted to device 2 and positively acknowledged, then device 1

must terminate the transmission. Device 1 sends an "end of transmission"

message to device 2. This allows device 2 to close the stored file and return to

other duties.

The various phases of communication for a file transfer, under this typical

protocol, assuming no error conditions, are illustrated in Figure 3.2. If you can

understand the inherent uncertainties with each phase, then you should begin to

realise the number of things that can go wrong in the above process. For example,

what should device 1 do if device 2 is switched off in the middle of file transfer?

What should device 2 do if device 1 is switched off in the middle of data transfer?

What happens if both devices wish to transfer files simultaneously - which device

should have preference? And yet, if the rules of protocol are inadequate or if the

software on any one device is inadequate, then one of the devices will misinterpret

incoming information or just "lock-up".


Just how rigorously we define a communications protocol and the means of

escape from error conditions, largely depends upon how important it is to achieve

accurate information transfer and "lock-up" free software operation. If for example,

device 1 is a PC and device 2 is a printer, then the protocol illustrated in Figure 3.2 is

probably far too rigorous and sophisticated to be worthwhile. On the other hand, if

device 1 is a PC and device 2 is a CNC machine, then we might say that the protocol

described is a minimum requirement because of:

• the length of the communications link

• the link's susceptibility to electro-magnetic interference

• the importance of accurate data transfer.

Enquiry Message

Acknowledge Message

Command Message& Check Calculation

Acknowledge Message

Data Packet 1& Check Calculation

Acknowledge Message

Data Packet N

& Check Calculation

Acknowledge Message

:

Termination Message& Check Calculation

Acknowledge Message

Time

Computer Based

Device 1

Computer Based

Device 2

Handshaking Signal Flow

Figure 3.2 - File Transfer Sequence under Typical Protocol


We therefore choose simple, loose protocols for an electro-magnetically

"clean" environment, where communication is short distance and errors are not

crucial. This minimises the amount of work required in interconnecting intelligent

devices. Conversely, the more important it is to minimise or eliminate errors and

lock-ups, such as in a computer control environment, the more secure and rigorous

the protocol must be. The penalty for data security is complexity of communications

software and subsequently, the speed of the link itself.


3.3 Modelling Conducting Communications Links

In order to understand why it is a complex matter to make two computerised

devices communicate with one another, it is first necessary to examine the physics of

a conducting communication link. We often view a conducting cable (wire), between

two computers, as an ideal element in an electrical circuit. This is shown in Figure

3.3. We assume that the wire has no resistance to the flow of current and that

therefore, the signal emanating from device A is the same as the one reaching device

B.

Earth Potential

Conducting CableDevice A Device B

δδδδ l

Figure 3.3 - A Single Wire Communications Link

The idealised model serves our purposes well for a number of levels of

analyses. For example, when we are examining rules of protocol, as in section 3.2,

we ignore the effects of imperfect conductors. However in order to understand why

errors occur in communications links, we need to look at a more appropriate model

of the conducting material. Firstly, we look at an infinitely small section of the wire (

δl in length) and examine its physical properties.


There are no "lossless" conducting materials. All materials have some

resistance to current flow, and energy is converted to heat within the conducting

medium. So the circuit model for our infinitely small length of wire has a series

resistor "R" to reflect the loss of energy at the receiving end of the conductor.

Equally, the air between the conductor and earth is not a perfect insulator and

therefore provides an alternative path in which current can flow through to earth.

The conductance (inverse of resistance) of this alternate path to earth is "G" and

reflects that current that does not appear at the receiving end of the conductor as a

result of charge flow through the alternate path.

Since the conductor has current flowing through it, a magnetic field is produced

around the conductor, and the resultant magnetic flux linkage of the infinitely small

section of wire is represented by a series inductor "L". The conductor will also have

a certain voltage (and net charge), with respect to earth, causing an electric field

between the conductor and earth, thereby giving rise to a capacitance "C".

The series inductance and the shunt capacitance reflect energy storage and

release within the line. Since both devices store and release energy at differing rates,

the voltage at the receiving end of the infinitely small length of wire will not

generally be in phase with that at the transmitting end. The complete transmission

line is built up from these infinitely small sections and hence we could draw the

circuit model for the transmission line as shown in Figure 3.4.

Vi

R L

C GVo

...

δδδδ l Segment of Line

R L

C G

δδδδ l Segment of Line

...

Figure 3.4 - Lumped Parameter Approximation of a Conducting Cable

This is referred to as a "lumped parameter" approximation of the transmission

line because all the physical properties that, in reality, are distributed evenly along

the line are represented by simple "lumped" circuit elements. Nevertheless, the

approximate circuit provides us with some insight into what happens when digital

signals pass through the transmission line.


A typical digital waveform that may pass through such a conducting cable,

during both internal and external computer communications is shown in Figure 3.5.

Time

Voltage

0 v

5 v

Figure 3.5 - Typical Digital Waveform

Mathematical analysis (Fourier Series) tells us that any waveform, regardless of

its shape can be represented by the sum of a number of sinusoidal waveforms of

differing frequency and amplitude. So looking at the digital waveform in Figure 3.5,

we could say that the high-frequency sinusoidal components of the waveform,

contribute to the sharp vertical edges, whilst low frequency sinusoidal components

contribute to the overall shape and the horizontal edges.

For any of the individual sinusoidal components of the digital waveform, the

ratio of output voltage (at the end of an infinitely short length of wire δl) over input

voltage can be obtained using the traditional "phasor-method" of circuit analysis.

The impedance of the parallel branch is given by:

Zj fC G

p =+

1

2π

...(1)

The impedance of the series branch is given by:

Z j fL Rs = +2π

...(2)


The ratio of output voltage to input voltage is then obtained through voltage division

and is given by the expression:

V

V

Z

Z Z

o

i

p

p s

=+

...(3)

Substituting equations (1) and (2) into (3) gives us the complex number expression:

V

V

j fC G

j fL Rj fC G

o

i

=+

+ ++

1

2

21

2

π

ππ

( ) ( )

...(4)

The magnitude ratio of output voltage over input voltage is given by:

V

V fRC fLG RG f LC

o

i

=+ + + −

1

2 2 1 42 2 2 2( ) ( )π π π

...(5)

The phase difference of the output voltage with respect to the input voltage is given

by:

ΦV Vo iArc

fRC fLG

RG f LC− = −

+

+ −tan

2 2

1 4 2 2

π π

π

...(6)

Both expressions (5) and (6) are frequency dependent. Therefore we can say

that the phase and magnitude-ratio of output voltage to input voltage will be different

for each sinusoidal component of the digital waveform. Substituting some "limit"

values into these expressions, we can observe that in the infinitely small section of

line:

• very high frequency ("f" tending to infinity) sinusoidal components will

be attenuated (diminished) to zero

• low frequency ("f" tending to zero) sinusoidal components will be

attenuated by a factor of (1 + GR)


• low frequency ("f" tending to zero) sinusoidal components will be

slightly "shifted" in phase with respect to the input.

If we were to exaggerate this effect, then the output voltage at the end of the

infinitely small section would look as the voltage waveform illustrated in Figure 3.6.

Time

Voltage

Input Waveform

Output Waveform

Figure 3.6 - Exaggerated Output Voltage at the end of δδδδl Segment

The attenuation of high frequency sinusoidal components, in the output

waveform, means that the edges lose their sharpness. The phase shift in low

frequency components, means that the output waveform appears to "lag" behind the

input waveform. As a result of attenuation in some of the sinusoidal components, the

output waveform also appears attenuated in some areas.

Since a conducting transmission line is composed entirely of these infinitely

small sections, the distortion and attenuation of the output voltages, with respect to

the input voltages, is increased with length. If the length of the transmission line is

sufficiently large, then the output waveform will be attenuated and distorted to such

an extent that it cannot be discerned from noise. This is shown schematically in

Figure 3.7.


Noise Level

Voltage

Time

Input Waveform

OutputWaveform

Figure 3.7 - Degenerative Effects of Long Transmission Lines

The lumped parameter circuit is not in itself adequate to describe the complex

physical phenomena that take place along a conducting transmission line, particularly

at high data transmission frequencies. In reality, accurate modelling of a conducting

transmission line requires consideration of a number of other factors. These include

the phenomenon referred to as "skin effect". As the frequency of the voltage

waveform on the transmission line increases from 0, current flow tends to occur more

predominantly on the outside of the conductor, rather than uniformly through the

cross-section. At very high frequencies (Megahertz and Gigahertz), current flow

occurs on the surface of the conductor, thereby giving the cable an apparently higher

"resistance".

Another phenomenon that occurs along the transmission line at very high

frequency transmission rates is that of "travelling waves" of voltage. Since

conducting transmission lines are not ideal, it takes a finite time for the voltage at one

end of the line to "ramp up" to the value at the other end. If high frequency

transmission lines are not terminated with an appropriate impedance (matching

impedance), then voltage waveforms travelling down the line can be reflected from

the target end, back to the source, thereby causing signal distortion.

The net result of all these phenomena is that we cannot assume that the signals

at the end of a conducting transmission line are the same as those at the source. The

longer we make a transmission line, and the higher the frequency at which we

transmit digital data, the more difficult it is to ensure that data integrity is maintained.

As a corollary of the above, there are a number of techniques that we can

employ, to ensure that data integrity is secured on the transmission link. In simple

links, these measures may include the restriction of data transmission frequencies and

line lengths to levels that are not deleterious to transmission accuracy. In more

complex links, signals need to be corrected or physically altered (amplified or

modulated) prior to transmission to ensure that they are not degraded by the link.


3.4 Electro-Magnetic Interference and Cross-Talk

The signal at the output end of a conducting, data transmission cable is not only

distorted because of the cable itself. Output signals can also be affected by magnetic

fields that induce additional voltages in the cable. These induced voltages can lead to

data errors at the receiving (output) end of the transmission line.

In order to understand this phenomenon, we examine the simple case of two

infinitely long, parallel conductors (each carrying a current that varies with time).

These are shown in Figure 3.8.

r1i1(t)

Conductor 1Conductor 2

d L

H~

Figure 3.8 - Two Parallel, Current-Carrying Conductors

Ampere's Law states that the magnetic field intensity generated around

conductor 1, as a result of the current flowing through it, is given by the closed-line-

integral expression:

⌠

⌡ H.dl = N i1(t)

~ ~

...(7)

where N is the number of "turns" in conductor 1 (clearly equal to 1) and i1(t) is the

current flowing in that conductor.


As a function of radial distance (r1) from conductor 1, the magnitude of the

magnetic field intensity becomes:

Hi

r= 1

12π

...(8)

The magnitude of the magnetic flux-density as a function of radial distance

from the first conductor is then given by:

Bi t

r=

µ

π1

12

( )

...(9)

where µ is the "permeance" of the medium between the two conductors. The

magnetic flux over a length "L" of conductor, passing through the distance "d",

separating the two parallel conductors, is given by:

⌠

Φ = ⌡B.ds

~ ~

...(10)

Φ =µ

π

i t

dd L1

2

( ). .

...(11)

Therefore the flux, per unit length, which passes through (links) the second (parallel)

conductor is given by:

Φ

L

i t=

µ

π1

2

( )

...(12)


Faraday's Law, tells us that the voltage induced in the second parallel

conductor, as a result of the flux linked from the first, is proportional to the rate of

change of the flux linkage:

Vd

dt

di t

dt∝ ∝

Φ 1( )

...(13)

Hence we can see that a time-variant current, passing through one conductor is

capable of generating (inducing) a voltage in the second conductor. This voltage

induction occurs whenever a changing magnetic field (regardless of its source) passes

through the conductor. If the magnetic field is generated by the flow of electrical

current (as above), then the induced, "unwanted" voltages in conductors are

specifically referred to as "Electro-Magnetic Interference" or "EMI".

The above example, which shows long, straight and parallel conductors is a

special case, lending itself to simple field calculations as shown in equations (7) to

(13). It highlights the effects of electro-magnetic voltage induction. The magnetic

field distributions of shorter, non-parallel conductors can be far more complex to deal

with mathematically, but the principles are similar. The two key points to note are

that:

(i) Current flow in a near-by conductor can induce unwanted signals in a

data carrying conductor

(ii) The larger the magnitude of the current flow in a near-by conductor and

the larger its rate of change with time, the larger the induced voltage in

the data conductor.

It is therefore important to watch for high power conductors, in the vicinity of

data communications cables, particularly where currents are being "switched". In an

industrial environment this is a situation that commonly arises when high-powered

electric motors (especially a.c. induction motors) are either switched on and off

regularly, or else have widely changing mechanical loads.

Induced voltages in data conductors are not always the result of high-current

cables in the vicinity. Sometimes, two low-current, parallel data conductors, in close

proximity, can induce voltages within one another. This situation is referred to as

"cross-talk" because data in one conductor is cross-linked into a parallel conductor.


The actual magnetic-field (flux) distribution in one conductor as the result of a

current in another is dependent upon the relative geometry of the conductors. The

"cross-talk" effect is most pronounced, with the field distribution arising from two,

long, parallel conductors. Cross-talk can therefore be reduced by altering the field

distribution between two data carrying transmission lines. This is in turn achieved

through changing the geometry of the conductors, by simply "twisting" pairs of

insulated cables around one another. The "twisted-pair" cable arrangement is shown

in Figure 3.9.

The susceptibility of data-carrying conductors to external magnetic (and

electro-magnetic) fields is minimised by wrapping insulated conductors in a

conducting cage or "shield". The shield can be a foil wrapping or a braided wire cage

(or both). Commercially available data transmission cables normally have a number

of insulated, twisted-pairs shielded with a braided cage and all wrapped in a plastic

insulating sleeve. Cable manufacturers provide a range of options so that end users

can select the number of conducting wire pairs to suit their needs.

PVC JacketStranded wire"Twisted Pairs"

with Polyethylene coating

Aluminium / Mylar Foil

Copper Braided Shield

individually insulated

Figure 3.9 - Twisted-Pair Cable Composition


3.5 Parallel Data Transmission and Communications Ports

Data within a computer system is transferred in a "bit-parallel" manner. This

means that all the binary digits (which together represent a basic unit of computer

information) are essentially transmitted at the same time and received at the same

time. If the basic internal unit of computer information is say, an 8-bit byte, then at

least 8 conductors are required to link the two devices for "bit-parallel" operation.

The objective of data-communication is to transfer binary information from the

data bus of one computer to the data bus of another computer, from which it can then

be directed to any other internal location (such as memory, disk, etc.). At a first

glance, therefore, it may appear sensible to extend the concept of "bit-parallel"

communications beyond the boundaries of a single system, to enable "computer to

computer" communications to occur. This concept is shown schematically in Figure

3.10.

CPU Memory

Computer A

CPU Memory

Computer B

d7

d0 d0

d7

Data Bus A Data Bus BExtension of internal

data bus structures

Figure 3.10 - Expanding "Bit-Parallel" Communications

It is actually feasible to enhance the simplistic link shown in Figure 3.10 in

order to establish a realistic link between devices. This is referred to as a parallel

"point to point" link.


The problems with implementing a simplistic parallel link, such as that shown

in Figure 3.10, are numerous. Firstly there is the problem of physical

incompatibility. Computer "A" may use one set of voltages to represent binary digits,

whilst computer "B" may use a completely different set of voltages. Secondly, the

data bus of computer "B" may be of a different size to the data bus of computer "A".

Finally, even if we could link the two devices in this way, we have a situation

where two intelligent devices (CPUs) may both attempt to act as masters over the use

of the data bus. For example, a contention situation could arise where device "A"

sets a line low, while device "B" tries to set the same line high, thereby causing a

temporary short-circuit.

Some of these problems are overcome by providing an electronic interface or

"buffer" between each device and the external communication link. This is shown in

Figure 3.11. In order for the two devices to then communicate, the interface on each

device must perform a two-way conversion between the internal data bus signals and

the common external representation.

ParallelInterfaceCircuit

CPU Memory

d0

d7

Computer A


CPU Memory

d0

d15

Computer B

Common standard forrepresentation ofbinary data

Figure 3.11 - Electronic Buffering of Parallel Communications

The circuitry in such a buffer needs to be designed with a view to withstanding

possible short-circuits because the interfaces are normally not capable of resolving

contentions for use of the external communication medium.


When we connect two devices for parallel communication, they are generally

not of the same intelligence level. For example, device "A" may be a Personal

Computer, whilst device "B" is a Printer (a dedicated, low-level computer). It may

therefore be necessary to resolve contentions on such a link by providing additional

lines on the interface circuits for external "hand-shaking" purposes. This is shown in

Figure 3.12.


CPU Memory

d0

d7

Computer A


CPU Memory

d0

d15

Computer B

Common standard forrepresentation ofbinary data

ready?ok!

Handshaking lines

Figure 3.12 - Hand shaking Lines in Parallel Communications

Hand shaking lines on communication links are used in order to synchronise

and/or co-ordinate the flow of data between two intelligent devices. They are

sometimes referred to as "hardware protocols" because they are designed to achieve

(using hard-wired links) the same ends as software protocols. Hardware protocols

are not unique to external communications. Within any individual computer system,

the address bus structure is the defacto hardware hand-shaking system that effectively

controls the flow of data from the CPU to memory chips and vice-versa.

Figure 3.12 shows the most common form of hardware hand-shaking between

intelligent devices. If we continue with the scenario where device "A" is a Personal

Computer and device "B" is a printer, then the "ready?" and "ok" lines serve the same

function as the "Enquiry / Acknowledge" sequence in a software protocol. Device

"A" may assert the "ready?" line to a "true" (enable) state, and if device "B" is ready

(on-line), then it should respond by asserting the "ok" line to a "true" (enable) state.

This would allow people to develop software on device "A" that takes into account

the possibility of device "B" being inoperative or disconnected.


Additional "control lines" are often used in communication links for the co-

ordination of data flow and device to device signalling. A good example is a parallel

link between a computer and a printer. The parallel link contains hand-shaking and

control lines that pertain to the status of the printer. An "out of paper" line is a

common hand-shaking line in such links.

Having established how simple parallel links can be made, we are again

confronted with the problem of standards for the links between devices. A number of

conformance issues are immediately apparent with respect to the parallel link:

• the number of data lines to be used

• the voltage representation of binary data

• the representation of characters

• the number and role of hand-shaking lines.

These issues are addressed by a number of common specifications and standards for

parallel links.


3.6 The Centronics Parallel Port

A number of specifications and so-called "standards" exist to define the parallel

communication process between intelligent devices. As with so many other aspects

of computing, there are no universal standards or ubiquitous solutions.

A parallel communications specification that has become very widely accepted

for computer to printer links is called the "Centronics" Parallel Interface. Centronics

is a registered trademark. Its specification has been widely accepted by printer

manufacturers, primarily because it is the common parallel interface on IBM (and

compatible) Personal Computers. The Centronics connector plug and pin allocation

are shown in Figure 3.13.

18

1716151413121110 9 8 7 6 5 4 3 2 1

36

3534333231302928272625242322212019

+5v

Chassis GND

Logic GND

OSCXT

Supply GND

Select

Paper EndBusy

AcknowledgeData Bit 8

Data Bit 7Data Bit 6

Data Bit 5

Data Bit 4

Data Bit 3

Data Bit 2

Data Bit 1

Data Strobe

Undefined

Undefined

(R) Data Strobe

(R) Data Bit 1

(R) Data Bit 2

(R) Data Bit 3

(R) Data Bit 4

(R) Data Bit 5

(R) Data Bit 6

(R) Data Bit 7(R) Data Bit 8

(R) Acknowledge(R) Busy(R) Input Prime

Input Prime

Fault

Undefined

Undefined

Figure 3.13 - Centronics Parallel Interface Connector


The Centronics parallel interface is a 36 line link. Eight of these lines (pins 2 -

9) are used to carry data. Pins 19 to 30, labelled with an "(R)", are signal ground

return lines for the corresponding data lines. Binary data in the Centronics parallel

link is represented with standard Transistor to Transistor Logic (TTL) voltage levels.

These are shown in Table 3.1. Note that under this representation, there is an

allowable error margin of 0.4 volts between the output from TTL circuits and the

input to TTL circuits.

Quantity Item Voltage Range

Binary 0

Inputs to Circuits

Outputs from Circuits

0.0 → 0.8 V

0.0 → 0.4 V

Binary 1

Inputs to Circuits

Outputs from Circuits

2.0 → 5.0 V

2.4 → 5.0 V

Table 3.1 - TTL Voltage Levels for Binary Representation

Data flow on the Centronics parallel link can be governed by the hand-shaking

lines that are provided. You should particularly note that these hand-shaking lines

have been established under the assumption that the device on one end of the link

will be a computer and the device on the other end will be a printer.

Pin (line) 1 on the Centronics link is a "strobe" signal that is supplied by the

computer to "clock" data out through the parallel data lines. The receiving device

(printer) examines the 8 bits of parallel data, from the computer, only on the negative

going edge of the strobe pulse waveform. This gives the receiving device a timing

mechanism for differentiating between successive data bits on each line. The

negative-edge triggering technique is shown in Figure 3.14. This illustrates the

receiving device interpreting bit number 3 of incoming data as a "0" at t1 and as a "1"

at t2.


Time

Voltage

Time

Voltage

Strobe Signal

t1

t2

Signal on Data Line 3

Figure 3.14 - Negative Edge Triggering Using a Strobe Signal

Pin (line) numbers 10 (ACKNLG) and 11 (BUSY) are two hand-shaking lines

that co-ordinate the flow of data. If for example, the printer is not ready to receive

data, then it sets pin 11 high - otherwise it is kept low and the computer is free to

transmit. If the printer resets pin 10 to low, then it is acknowledging receipt of the

last 8 bits of parallel data and indicating that it is ready to receive more - otherwise

the printer is not ready to accept data. Table 3.2 lists the various Centronics line

functions and their direction of information flow. Note however that the functions of

lines 12, 13, 14, 15, 31, 32, 34, 35 and 36 vary according to individual applications,

and they are often used to convey additional printer status information (such as out of

paper, etc.).

The Centronics Parallel link is designed for fast, one way data flow, from a

master device (computer) to what is generally a slave device (printer). It does not

readily lend itself to an environment, where two, equally intelligent computer devices

can both talk and listen to each other at the same time.


Line or Pin Corresponding

Return Line

Signal Direction

1 19 Strobe From Computer

2 20 Data Bit 1 From Computer








10 28 Acknowledge From Printer

11 29 Busy From Printer

12 Paper End Application

Dependent

13 Select Application

Dependent

14 Supply Ground Application

Dependent

15 Oscxt Application

Dependent

16 Logic Ground

17 Chassis Ground

18 +5 Volt Rail

31 30 Input Prime Application

Dependent

32 Fault Application

Dependent

33 Undefined

34 Undefined

35 Undefined

36 Undefined

Table 3.2 - Centronics Pin Configuration and Common Data Flow

The Centronics link is primarily intended as a point to point system, with only

one device at either end. However, its capabilities can be extended through

commonly available "Parallel Exchange Network Units". These enable a single

computer to feed a number of Centronics compatible devices as shown in Figure

3.15. Alternatively, a number of computers can use the exchange to share high cost

printers and other peripherals. This is referred to as "resource sharing".


Centronics Port Centronics Port Centronics Port

Centronics Port

Centronics Ports

Centronics Cable

Centronics Port

Computer 1

Computer N Laser Printer Matrix Printer

Parallel Exchange Network

Figure 3.15 - Connecting Multiple Devices Through Centronics

The parallel exchange network unit is simply a switching (multiplexing)

device, which can make a direct, point to point link between any two devices that are

connected to it. The operation, sophistication and number of ports on these exchange

units vary markedly between vendors but in relative terms the devices are all

inexpensive. This is therefore a common and simple technique for sharing

equipment through a relatively simple Centronics "Star" Network.

A common resource-sharing implementation might be as shown in Figure 3.15.

This arrangement would enable either of the two computers to use either of the two

printers. The majority of exchange units use "software switching" to facilitate this.

This means that in order for one device to access another, through the exchange, the

originator first sends a simple command string to the exchange. The command string

tells the exchange which device is to receive information from the originator. The

exchange then makes the physical "point to point" connection and thereafter becomes

transparent. The originator (computer say) can then talk to the receiver (printer) as if

the exchange was not present. The receiver (printer) is therefore never aware that it

is connected to the exchange and functions as normal.

It is possible in such a system that a "contention" will arise when both

computers wish to use the same printer at the same time. The more sophisticated

exchange units can resolve these contentions and "queue" requests for connection in

their own built-in memory buffers.


3.7 Networked Parallel Data Transmission and IEEE-488

In a scientific or engineering environment it is often necessary for a number of

"intelligent" devices to be linked to one another so that data can be transferred and

shared. For example, in a metrology laboratory, a Personal Computer may need to be

linked to a number of microprocessor controlled data-acquisition devices so that it

can process data and issue control signals. A simple point to point link is clearly

inadequate for this purpose. There needs to be some form of "network" by which

data interchange can occur.

Within an individual computer system, a parallel network exists in the form of

the data and address bus. A Central Processing Unit (CPU) can readily communicate

with other chips by selectively setting address bus lines high and low. Each and

every memory location in such a system is activated by a unique pattern of high and

low bits on the address bus. This is referred to as "addressing". Each chip device in

the system has a unique range of addresses allocated to it. Each memory location or

register in each chip has a unique address within the range allocated to the chip itself.

All the chips share the same conductors (bus) for data transfer and contentions for

use of the conductors inevitably arise. These are resolved either through the CPUs

"masterly" use of the address bus or through special "bus controller" chips.

The internal parallel data transfer network can be expanded for external use,

provided that the following parameters are standardised:

• the physical representation of data

• the size of the external data bus

• contention resolution (for media usage)

• device addressing.

The most common specifications for parallel data communication, in network

form, are those referred to as the IEEE-488 "Instrumentation Bus" or Hewlett

Packard Instrumentation Bus (HPIB) or General Purpose Instrumentation Bus

(GPIB). These are all generic or proprietary terms for essentially the same

specification. The instrumentation bus is very widely used on scientific, metrological

and general laboratory equipment for short distance communications.


The GPIB specifications help us to define:

• the number of data lines to be used

• the shapes and pin configurations of connecting plugs

• the values of voltage required to represent binary digits

• device addressing

• the hand-shaking lines

• the control lines.

The concept of the GPIB is not unlike that of the Centronics parallel system,

except that it is far more flexible (in terms of the devices that can be connected to it)

and incorporates a number of features that make it amenable for use as a network as

well as a point to point link. Connecting plugs in the GPIB system have a "plug

through" facility so that by plugging one connector into the back of another, a daisy-

chained, parallel network can be generated. This concept is illustrated in Figure 3.16.

GPIB Port GPIB Port GPIB Port

Device 1 Device 2 Device 3

GPIB Cable

Plug-through Connector

Figure 3.16 - Daisy-chaining to Form a Parallel Network

The GPIB system is intended as general purpose, network in which data-flow

can be bi-directional, unlike the uni-directional, computer to slave (printer)

relationship in the Centronics link. The IEEE-488 (GPIB) connector plug and pin

allocation are shown in Figure 3.17.

The GPIB connector is a 24 pin device with 16 active lines. Each device in the

GPIB system must be identifiable through a unique address to avoid bus conflicts.

Each device in the system must be aware of its own address in order for the GPIB to

function correctly.


1 DIO1

2 DIO2

3 DIO3

4 DIO4

5 EOI

6 DAV

7 NRFD

8 NDAC

9 IFC

10 SRQ

11 ATN

12 SHIELD

DIO5 13

DIO6 14

DIO7 15

DIO8 16

REN 17

GND 18

GND 19

GND 20

GND 21

GND 22

GND 23

Logic GND 24

Figure 3.17 - IEEE-488 Connector and Pin Configuration

Pins 1-4 and 13-16 in the GPIB are used for data lines. The data on these lines

may either represent unrelated binary information or ASCII character types. The data

bus lines (DIO1- DIO8) allow the transfer of data, control words and device

addresses. Note however, that in contrast to the Centronics representation of binary

information, a binary "0" is represented by +5 Volts d.c. and a binary "1" is

represented by a voltage of 0 Volts.

Within the IEEE parallel network system, there are essentially three types of

devices that can be connected:

(i) Controllers

The controller is the device that is capable of getting other devices to accept

commands. It does this by asserting the "Attention" (ATN) line (pin 11). Only

one controller is permitted to exist on the parallel data bus at any one time.

(ii) Talkers

A talker is a device that is configured to transmit data on the data bus to other

devices. Normally, only one talker is permitted to transmit on the data bus at

any one time.

(iii) Listeners

Listeners are devices that read in data from the data bus, utilising a pre-defined

hand-shaking sequence. More than one listener can exist and be active on the

bus at any one time.


Hand shaking lines work on a similar principle to those in the Centronics

system except that a number of devices may assert or monitor the lines. In the GPIB

there are three hand-shaking lines, two of which can be asserted by listeners and the

third by a controller.

The "Data Valid" (DAV) line (6) is one that is asserted by the controller to

indicate that it has placed a control byte on the data bus. The "No Data Accepted"

(NDAC) line (8) is one that is asserted by a listener on the GPIB to indicate that it

has not yet accepted the last byte that was placed on the bus. The "Not Ready for

Data" (NRFD) line (7) is used by an active listener to prevent new data or control

bytes to be placed on the bus. Talkers all monitor the NRFD line and wait until it is

de-asserted before sending the next 8 bits of information.

The control lines are similar to hand-shaking lines except that they are used to

define the way in which binary information on the data lines is to be interpreted. The

"Interface Clear" (IFC) line is used by a controller on the GPIB to place the entire

interface system, and all its connected devices, into a defined "quiescent" state.

The "EOI" line is used by talkers to indicate the end of a multiple byte, data

transfer message. In this mode it acts as an "end of data" indicator flag. A GPIB

controller also asserts the "End or Identify" (EOI) line in conjunction with the

"Attention" (ATN) line, when conducting a "poll" on the status of other devices in

the system.

The "Service Request" (SRQ) line is asserted by a GPIB device to indicate to

other devices the need for some specific service program. The "Remote Enable"

(REN) is asserted by a controller to force a listening device to ignore its "front panel"

controls.

The IEEE-488 network is a relatively fast and efficient means of transferring

data between devices over short distances. This makes it particularly suitable for the

laboratory environment, which is electro-magnetically "clean". As with all parallel

data networks and links, the ability to transfer 8 bits of data simultaneously from

source to destination is a major factor in performance.

A number of computer and scientific equipment vendors, including Hewlett

Packard, have used the IEEE-488 system as the back-bone system for interconnecting

devices over limited distances. Some of these equipment manufacturers take

advantage of the parallel system performance and use the GPIB for functions such as

memory to disk-drive transfers and so on. The "generalised" structure and

specification of the IEEE-488 system make it an extremely useful tool for many short

distance applications.

91

Chapter 4

Serial Data Communications - Fundamentals

A Summary...

An examination of problems associated with using parallel links over long distances.

Line-drivers and modulation techniques. Converting parallel data into serial formats.

The UART and USRT. Synchronous and Asynchronous serial communications

links.


♦ You need to learn the problems of parallel communication

♦ You need to know why and where serial communications is used

♦ You need to understand about line-drivers and amplification

♦ You don't understand the difference between synchronous and asynchronous

communications

♦ You need the concepts of modulation explained.


4.1 Serial Communications in Integrated Manufacturing

If it had not been for the advent of CNC machines, PLCs and robots, then many

manufacturers could have lived their lives in complete ignorance of the problems

associated with the lack of standardisation in data communications. Few people

could have imagined just how difficult it would be to make a range of vastly differing

industrial controllers communicate with one another. Indeed, when some of these

devices were originally designed (notably CNC), there was little understanding of

why industrial controllers should communicate at all and even less understanding of

what they would need to say if they could communicate.

In the manufacturing office, a simple phone-call to a computer vendor would

have been more than adequate to secure the installation, management and

maintenance of a network for the computerised office. Manufacturers could have all

been thankful to the great god of production problem resolution - volume. For no

matter how badly designed a computer system and no matter how incompatible one

form of computer architecture is with another, if there are enough of them in the

market-place, an effective solution to every problem is never far away.

The majority of computers in the office fall into a relatively small number of

vendor stables and architectures. And there are invariably an enormous number of

office machines on the market with the same (or similar) architectures. Even when

"Brand X" systems are not compatible with "Brand Y" systems the manufacturer of

"Brand X" computers will try to break into the "Brand Y" market by providing a

communication link (and a piece of interfacing software) that will facilitate

compatibility.

The provision of links between office computer systems of differing

architectures is often financially attractive on a volume basis alone. Over and above

this however, we have a bonus situation where office computers are generally of the

same vintage. The likelihood of finding computerised office equipment older than 10

years is relatively small. So much so that we could say the likelihood of finding an

office computer of 20 years of age would be almost nil.

The manufacturing environment, on the other hand, is very different to that of

the office. With the exception of "off-the-shelf" CNC machines, production

equipment is generally "tailor-made" for specific applications. Control systems

(although increasingly modular) are usually tailored for specific applications. Even

"off-the-shelf" CNC mills and lathes are low volume entities in comparison with

office computers and printers. To make matters worse, these low volume CNCs are

produced by a large number of vendors, each with their own individual views on

controller architecture.

Serial Data Communications - Fundamentals 93

Production equipment often has a far longer life-span than normal computer

equipment. A significant proportion of production machines are still extremely

efficient even after forty years of service. Within a manufacturing organisation we

therefore contend with a wide range of control equipment and an equally wide range

of architectures, ranging from state-of-the-art microprocessor control to hard-wired,

relay-ladder-logic control.

The low volumes and large varieties of manufacturing control equipment make

it extremely difficult (and unprofitable) for organisations to offer the same range of

communications solutions that are available to the office world. Professionals within

the manufacturing environment therefore do not yet have the luxury of selecting

"communications solutions" from an electronics supermarket.

It is normally accepted that, for manufacturing management purposes, there is

merit in integrating production equipment through communications links. This

should, in theory, enable real-time monitoring of production data and allow for more

rapid changes to production schedules and part designs. It is also accepted that

effective data links between Computer Aided Design (CAD) systems and production

machines are now vital to minimise human errors. With these goals in mind, moves

have long been afoot to try to rationalise (standardise) communications within

manufacturing. However, (at the time of publishing) this standardisation has still not

been realised.

There is some hope that in the long term, communicating with a machine or

controller, from a host computer, will be as simple as making a plug-in connection.

However it must be realised that even if universal communications standards for

manufacturing are adopted immediately, there are still many short term problems to

be overcome.

A significant proportion of machines and production systems, with controllers

built during the 1970s and 1980s, will still be in service for many years. For the

many and varied PLC and CNC controllers in such systems, the prospect of plug-in

compatibility with sophisticated communications networks is virtually non-existent.

However, if these systems are to be integrated with other computers (in order to make

manufacturing management software systems more efficient and direct links from

CAD possible) then the traditional mechanisms for communication (and their

limitations) must be clearly understood.


The only mechanisms for communication between many of the industrial

control systems, developed during the 1970s and 1980s, and host computers are the

so-called "point to point" serial links. Regardless of how these links are viewed,

relative to networks, it must be accepted that they will play a major role in

manufacturing for many years. Although these links are conceptually simple, they

tend to be a major cause of problems and time wastage to manufacturing

organisations. Each serial link between an industrial control system and a host

computer represents a unique problem. Each link requires a unique hardware and

software solution.

As a result of non-standardisation, point to point, serial communications links

are amongst the most misunderstood areas in the manufacturing world. Many

professionals within industry do not appreciate the considerable (and time

consuming) problems involved in achieving reliable data transfer on these links. A

sound understanding of the principles of point to point serial communication is

therefore vital in order to reduce development times and costs.


4.2 The Role of Parallel Communications in

Manufacturing

Following a discussion of the role of serial communications in manufacturing,

one may ask about the prospect of parallel communications, for transfer of

information to and from production controllers. In practice, parallel communication

is rarely used outside a laboratory or metrology environment, where the distance

between devices is less than (say) 15 metres.

Even within a small manufacturing organisation, the distance between a host

computer and an industrial controller is likely to be in the order of hundreds of

metres and parallel communication techniques cannot readily be transferred to

communications over longer distances. One fundamental reason for this is because

of the voltage attenuation and distortion that occurs through a conductor. A simple

rule of thumb would be to say that normal digital (TTL) signals cannot reliably be

interpreted at the receiving end of a low grade conductor once its length exceeds

several metres. There are two possible solutions to the problem:

(i) Use a higher grade of conductor

(ii) Amplify the signal before transmission.

The first solution only provides a marginal increase in the maximum

transmission distance and does not, in itself, provide a solution for long-distance

communication. The second solution requires an "interface" between the

transmission line and the computer.

Devices that modify a signal at the transmission end of a link, to enhance

reception, are referred to as "line-drivers". The complementary devices, which

convert line signals back to the required internal form for the target device are

referred to as line-receivers. Sometimes the line-drivers and line-receivers are

internal to the computer system. Signal amplification is a good example of "line-

driving" and is a way of overcoming the degenerative (attenuation) effects of a

transmission line. However, in order to implement this solution in a parallel system,

a number of line-drivers, as shown in Figure 4.1, would need to be used.

A parallel link may have more than 15 signal-carrying lines, each of which

would have to be "driven" in order to increase the span of the link to more than a few

metres. Although it would be feasible to provide these drivers, there is clearly an

increased cost element involved.


Computer A Computer B

Line Driver 1 Line Receiver 1



Line Driver N Line Receiver N

Figure 4.1 - Extending the Range of Parallel Communications

In a medium to large scale organisation, the length of a link between a CAD

system and a CNC machine could be in the order of a kilometre (taking into account

cable deviations around obstacles and so on). Leaving aside the issue of "line-

drivers" we need to look at the more obvious question of cable cost and utilisation.

At any instant in time on a parallel communication link, each conductor carries only

one binary digit of information. Consequently in the extended ASCII or EBCDIC

representations of characters, 8 conductors (each of a kilometre in length) would be

required to transmit each character. If you add to this the number of hand-shaking

and control lines in a given link then you will appreciate just how much cabling is

involved. Consider then the feasibility of linking computers on a nationwide or

global basis - parallel techniques start to look very unattractive.

In a realistic system, it is often necessary to have the capacity for two

intelligent devices to talk to one another simultaneously. Kirchoff's voltage law tells

us that only one voltage level can exist at any given point in an electrical circuit, at

any given time. Consequently, we cannot simply have two devices transmitting to

one another on the same conductors at the same time. If we wish to have this

simultaneous, two way data transfer between devices, then we either need two sets of

8 conductors or else find a suitable means of sharing the same conductors. In order

for two transmitting devices to share the same conductors, a more complex voltage

representation of binary data is required (this requires modulation techniques). While

both these solutions are possible, neither is attractive - the former because of the

increased number of conductors and the latter because of the complex line-drivers

required.


Parallel communication systems do have one major advantage over rival

technologies. A major feature of parallel communication is its relative speed of

transmission. All the data bits that form a single character are sent and received

simultaneously. However, speed is not always a prerequisite in communications.

For example, a CAD to CNC link does not need to be fast because the physical

machining process is not comparably fast. Moreover, as the cost of the link itself

increases (with distance), there must be a trade-off situation, where it becomes

extravagant to continue with parallel links and an alternative must be used. The

alternative is serial communications, where one line is used to transfer all data bits.

It should also be well noted that the cost of physical hardware in parallel links

is not the only reason for their lack of use in long distance communications. Had

there been a universally adopted standard for medium-distance parallel

communications, then it is just possible that the cost of parallel hardware would have

been overlooked in favour of "plug-in compatibility". In the final analysis, the costs

associated with developing specialised hardware and software probably far outweigh

the cost of line-drivers and extra cabling. However, despite the emergence of parallel

communications specifications such as IEEE-488, standards are no more universal

than in serial communications.

Parallel communications have therefore remained in the realm of short-distance

office and laboratory communications.


4.3 Parallel to Serial Conversion

Common digital circuits, such as "shift-registers" allow us to convert parallel

information, as found on an internal computer data bus, into serial information. This

is illustrated in Figure 4.2.

d7

d0

Computer Data Bus

1 0 0 1 1 1 0 1

Clock Signal

Serial Output

Parallel Inputs

b7 b6 b5 b4 b3 b2 b1 b0

Figure 4.2 - Shift-Registers for Parallel to Serial Conversion

Data bus bits, b0 - b7, enter the shift-register simultaneously (in a parallel

fashion) and are then fed out of the register, in sequence, each time the clock-signal

waveform reaches a pre-defined point (usually the negative edge). This is shown in

Figure 4.3.

Once data is converted from parallel form into a serial bit stream, then it can be

transmitted over long distances using only a single conductor. This provides

significant savings over parallel transmission (in terms of cabling and line drivers).

It is an equally simple task to generate complementary decoding circuits for

receiving devices, that will convert incoming serial bit streams into a parallel form

for internal use. These digital circuits are conceptually similar to the ones used for

parallel to serial conversion, except that data flow is in the opposite direction. When

the conversion and decoding circuits are linked with a conducting cable, the net result

is a serial communication link.


Time

Time

Clock Signal Voltage

Shift Register Output Voltage

d0 d2 d3d1 d4 d5 d6 d7

Figure 4.3 - Timing Diagram for Parallel to Serial Conversion

As with all data communications, both the transmitting and the receiving

devices must agree on the form of binary data representation to be used. It is

important to understand that voltage is a relative quantity and is not absolute. The

representation of binary ones and zeros at a transmitting device will be through

voltage levels, with respect to its local reference level. Similarly the interpretation of

data at a receiving device will be through voltage levels with respect to its own local

reference level. If these two reference levels are not the same then transmitted data

cannot be correctly interpreted by the receiver. A "common" reference voltage line is

often connected between communicating devices so that all devices interpret data

with respect to the same reference. This is shown in Figure 4.4.

Device A Device B

Transmit Line

Common Reference Line

V Vt r

Figure 4.4 - A Common Voltage Reference for Transmission Signals


Once we have a serial mechanism by which we can transfer data on a single

line, then it is also feasible to provide an additional line for simultaneous, two-way

communications. This is shown in Figure 4.5.

Device A Device B

Transmit Line


V V

Receive Line

V V

ta rb

ra tb

Figure 4.5 - Simultaneous Two-Way Serial Data Transmission

A transmission system in which data communications can only ever occur in

one direction (master to slave) is referred to as a "simplex" link. A system in which

data communications can occur in two directions, but not simultaneously is referred

to as a "half-duplex" link. When interconnected devices can simultaneously transmit

and receive then the link is referred to as a "full-duplex" link.

When we transfer data in parallel systems, the minimum unit of information

(byte or word) is defined by the number of data conductors. For an 8 bit, parallel

system, an entire byte of information is transferred simultaneously from one device to

another. If that byte represents alpha-numeric information then the minimum amount

of information transferred is one character.

In serial systems the minimum unit of data that can be transferred is one bit.

However, sometimes it is necessary to treat a group of bits as a single character, such

as in the ASCII system. Therefore in a serial link, we define systems that treat each

bit as a discrete unit to be "Bit-Oriented". Serial systems in which bits are only

interpreted in clusters of 8, in order to represent alpha-numerics, are referred to as

"Character-Oriented" systems.


To summarise the concepts of serial data communications between computer

systems, we can say that it consists of 4 conversion phases:

(i) Conversion from parallel to serial representation

(ii) Conversion from internal form to external transmission form

(iii) Conversion from external transmission form to internal form

(iv) Conversion from serial to parallel representation

The four phases are shown schematically in Figure 4.6 for a simplex link.

Phase (i) involves the clocking of parallel data out onto the transmission line, one bit

at a time, with the rate determined by the clock speed. Phase (iv) is the

complementary function that has to clock serial data back into a register for parallel

transfer to the target device's internal bus. Phases (ii) and (iii) are performed by line-

driver and line-receiver circuits, which act as the interfaces (marked I/F in Figure 4.6)

between the internal data representation of the computer system, and the external

data representation required on the transmission line. These two phases modify the

transmitted signal into a form that minimises the effects of line distortion and

attenuation.

Device A

d0

d7

I/F

Clk

1 1 0 1 1 1 0 1

Device B

d0

d7

I/F

Clk

11011101

Serial Data Line


V VClock Signal BClock Signal A ta rb

Figure 4.6 - Schematic of Serial Data Transfer Between Devices


4.4 Synchronous Serial Data Communications

The schematic of Figure 4.6 shows two devices that are linked by a common

pair of conductors. Device "A" clocks out voltage pulses (the data signal), whose

widths are determined by the frequency of clock signal "A". It is assumed that the

transmission medium is ideal and that the signal appearing at the receiver is exactly

the same as that emanating from the transmitter. The receiving device, "B", reads

incoming voltage pulses at time intervals determined by the frequency of its clock

signal "B". That is, at a predefined point in its clock cycle (the negative going edge

say), device B examines the input signal and accordingly places a high or low value

into the register (and shifts other values along).

If the frequency of clock signal A and the frequency of clock signal B are not

precisely the same, then it is possible that device B will not be able to interpret the

incoming signal correctly. This is shown in an exaggerated form in Figure 4.7. As

can be seen from this diagram, the mismatch between the transmitter clock and the

receiver clock eventually causes the receiver to misinterpret the incoming signal -

even though it has been correctly received.

Although Figure 4.7 exaggerates the phenomenon of mismatched clocks, it

illustrates that even slight mismatches, between the clock used to shift information

out of the transmitter's register and that used to shift data into the receiver register,

will ultimately lead to erroneous interpretation of data. Since it is not feasible to

simply expect two independent free-running clocks to be in synchronism, a

mechanism must be found to co-ordinate the clocking of data between a receiver and

transmitter.

The first technique that we shall examine that enables a receiver to correctly

decode incoming serial data is referred to as "synchronous" serial transmission. This

involves "synchronising" the receiver's clocking signal to that of the transmitter.


d0 d2 d3d1 d4 d5 d6 d7

d0

(ok)

d1

(ok)

d2

(ok)

d3

(ok)

d4

(ok)

d5

(ok)

d6

(wrong)

Time

Time

Clock Signal Voltage at A

Transmitted & Received Voltage

Time

Clock Signal Voltage at B

Time

Interpreted Voltage at B

Figure 4.7 - Incorrect Interpretation of Data Due to Unmatched Clocks at

Receiver and Transmitter

The most obvious way to synchronise the receiver's clock to the transmitter is

to provide an additional line, containing the transmitter's clock signal, in parallel with

the signal line. This is shown in Figure 4.8.


Device A

d0

d7

I/F

Clk

1 1 0 1 1 1 0 1

Device B

d0

d7

I/F 11011101

Serial Data Line


Clock Signal BClock Signal A

Clock Line

Figure 4.8 - Synchronising a Receiver to a Transmitter

Although this appears to be a good idea, in practice, this technique is not

generally used. This is partly because the use of an additional line diminishes the

value of serial transmission and partly because it is not always possible to have the

additional line between the receiver and the transmitter. This often happens when

using public communications networks that provide only a single line for data. An

alternative is to somehow embed the transmitter's "clocking" information into the

data signal itself. The receiver needs to "extract" or "recover" the clock signal in

order to correctly decode the incoming signal. Whenever the receiver extracts

clocking information from the transmitter, the scheme is referred to as "synchronous

transmission".

There are a number of means by which synchronising information can be

transmitted within a data signal. The first method is referred to as "clock encoding

and extraction". Under this scheme, clocking information is placed into the data

stream by use of special transmission techniques. The receiving device extracts this

clock information and uses it as the reference clock for data decoding.

The simplest form of clock encoding and extraction is achieved through a bi-

polar encoding technique, where binary 1's are represented by a positive voltage and

binary 0's are represented by a negative voltage. Between each pair of binary bits, the

voltage waveform is at zero volts. This is referred to as an "RZ" waveform or a

Return-to-Zero waveform. A bi-polar, RZ waveform is shown in Figure 4.9.


Time

Time

Voltage Waveform for Raw Data to be Transmitted

Voltage Waveform for Bipolar Encoded Signal

b0 b1 b2 b3 b4 b5 b6 b7

b0

b1

b2 b3 b4

b5 b6

b7

Figure 4.9 Bi-Polar Encoded (RZ) Waveform

The fact that we now have a zero voltage state in between successive bits

means that the receiver can detect the time duration between bits and therefore

extract "clock" information. Note how this is not possible with the raw waveform of

Figure 4.9, because successive, contiguous streams of 0's or 1's make it impossible

for the receiver to differentiate between bits.

Another, slightly more complex technique, known as the "Manchester

Encoding", or Phase Encoding (PE) technique, produces a waveform with the

normal, two voltage levels. It is referred to as a "Non Return to Zero" or "NRZ"

encoding technique. The width of pulses in the Manchester scheme varies depending

on whether successive bits are the same or not. This provides a mechanism for

"extracting" clock information at the receiver.

If clocking information is not embedded into the transmitted data signal, there

is a possibility that the receiver's own clock will allow it to drift out of synchronism

whenever a long stream of zeros and ones are received. Therefore, the only other

means by which a receiving device can synchronise itself to a transmitter, is to

always ensure that there are enough transitions (0 → 1 and 1 → 0) in the data signal.

This means that the transmitted data must be encoded in a special format.


This encoding is referred to as a "Non Return to Zero Inverted" (NRZI)

technique or a "differential encoding" technique. Under this scheme, the original

waveform is transmitted raw, until a binary "0" occurs. From this point onwards, the

waveform is inverted after every binary "0". This is shown in Figure 4.10.

Time

Time

Voltage Waveform for Raw Data to be Transmitted

Voltage Waveform for NRZI Encoded Signal

b0 b1 b2 b3 b4 b5 b6 b7

b0 b1 b2 b3 b4 b5 b6 b7

Figure 4.10 - Differential (NRZI) Encoding of Waveforms

Differential encoding ensures that there will always be sufficient bit transitions

in the transmitted waveform, to which the receiver's clock can synchronise, provided

that there are no continuous streams of binary "1s". In practice, this does not occur,

purely because of the way in which binary data is transmitted in synchronous links.

Data in bit oriented schemes is broken up into groups of bits, referred to as "frames".

In order to distinguish between frames, binary 0's are always strategically inserted

into the data to generate special bit patterns.


4.5 Asynchronous Serial Data Communications

Asynchronous serial communication is perhaps the most common form of data

communications that must be handled within a manufacturing environment. It is

widely used for communication between:

• Production machines (CNCs) and computers

• Production Controllers (PLCs) and computers

• Computers and terminals

• Computers and printers

• Computers and plotters

• Computers and computers.

Asynchronous communication is of importance to us, if only because it is one

of the most misunderstood topics in manufacturing (with good reason). It is also

important because it is the area in which a large amount of specialised tailoring must

be done by manufacturing professionals.

Historically, asynchronous serial communication was introduced for links in

which data transmission occurred only at spasmodic intervals - say between a

terminal (used by a human) and a computer. In these situations, the transmission line

spends a large proportion of its time in an "idle" state, with no transitions between

high and low. The receiver in these links therefore needs to be able to synchronise

itself to the transmitter only at the start of an incoming data unit (and these are

intermittent).

In as much as asynchronous links are designed for low volume data flow, the

speeds at which transmission occurs are much lower than those associated with

synchronous links. This means that it is not necessary to use complex encoding

techniques to supply clock synchronising information to the receiver. The inclusion

of a simple transition (1→0 or 0→1) between basic data units is enough to allow a

receiver to decode the incoming waveform. In other words, asynchronous links are

those in which the receiver does not attempt to extract the transmitter's clocking

information.

Another feature that has been incorporated into asynchronous transmission,

both for historical and practical reasons, is that the system is usually character-

oriented. The basic unit of data transmission is normally an 8-bit quantity. This

accommodates the ASCII (7-bit), extended ASCII (8-bit) and EBCDIC (8-bit)

character sets. There is no reason why asynchronous systems must be restricted to

character-oriented transmission, but in view of their common, practical application it

has been a logical development.


Assuming an asynchronous ASCII system is used, Figure 4.11 shows how the

character 'u', which has an ASCII value of 117 decimal (or 01110101 binary), is

transmitted. This shows what is referred to as a "frame". A frame is a complete

basic unit of information that incorporates data, plus the essential encapsulating bits

that are used in the transmission process.

Time

1 ... 1

0

1

0

1

0

1 1 1

0

1 1 1...

LineIdle

Start

BitStop BitsASCII Character

Transmission Line Voltage

Frame

LineIdle

Figure 4.11 - Asynchronous Transmission Format for the ASCII Character 'u'

Figure 4.11 illustrates a number of important points in regard to asynchronous

serial data transmission. These are:

• Binary 0 is represented by positive voltage

• Binary 1 is represented by negative voltage

• The line is kept at binary 1 when idling

• Each character is surrounded by start and stop bits.

It is a source of aggravation and confusion that the voltage logic for

transmission of data on an asynchronous link is the exact opposite to what one would

naturally expect. It is also in conflict with the voltage levels used in typical digital

circuits such as TTL. We should also note that this representation is not a universal

standard but it is in very common usage on asynchronous links.

In early electro-mechanical transmission, data was transmitted on a link by the

flow and interruption of current on the line (and not by voltage variation). It was

discovered that the reliability of such links could be greatly improved by maintaining

a fixed current during idle periods. Data was then effectively transmitted by

interrupting the quiescent state and stopping current flow. The idle state is when the

system is "marking time" and hence is referred to as the "MARK" condition or binary

1 (current ON). The condition where current is absent is referred to as the "SPACE"

condition or binary 0 (current OFF).


We must now accept that in asynchronous serial transmission, 1, MARK and

Negative (no signal) are synonymous and similarly that 0, SPACE and Positive are

synonymous. Once we come to terms with the inverted voltage logic, we can see

how the start and stop bit/s allow a receiver to synchronise itself with incoming data.

Figure 4.12 shows how the transition appears between successive characters.

Time

Start

Bit Character Data BitsStop

Bits

Start

Bit

Transmission Line Voltage Transition Point

Next

Character

0

1 1

0

Figure 4.12 - Well Defined Transitions Between Frames in Asynchronous

Communications

The transition region caused by the succession from stop bits to a start bit

provides enough information for the receiver to synchronise itself to the incoming

data. Note particularly that there do not have to be 2 stop bits in order for this

recognition to occur. The same result can be achieved with only 1 stop bit. In most

asynchronous links, a transmitter and receiver can be set up to function on either 1 or

2 stop bits. As long as both devices use the same convention it doesn't make any

difference.

At this point it is imperative to note another convention in asynchronous data

communications. That is, START is signified by a binary 0 (positive voltage or

SPACE) and STOP is signified by a binary 1 (negative voltage or MARK). This

makes sense if we adhere to the convention of an idling line being in a MARK state.

A change from MARK to SPACE indicates that data is being transmitted. This is

again the exact opposite to what we have come to expect in digital circuits, where we

normally set a value to binary 1 in order to enable and binary 0 to disable. You need

to be extremely careful when reading literature related to this topic. You should try

to deal with binary values (not voltage levels) when analysing asynchronous serial

circuits and you can use Table 4.1 for equivalent terms.


As long as you remember that in order to start or enable any function in serial

communications you must supply a binary 0 and to stop or disable any function you

must supply a binary 1 then there is no confusion.

Binary 0 Binary 1

Space Mark

Positive Negative

Start Stop

Enable Disable

Low High

False True

Table 4.1 - Equivalent Terms in Serial Communications

An important question that needs to be examined is how and why synchronous

and asynchronous links differ. If it is possible for an asynchronous receiver to

accurately decode incoming information from a stop to start bit transition then why

cannot the same be achieved in synchronous transmission?

The fundamental difference between the two schemes is speed. Asynchronous

links generally transmit data at rates of either 110 300, 1200, 2400, 4800, 9600 or

19200 bits per second (bps). These are relatively slow speeds in comparison to

synchronous links that run at speeds in the order of Megabits per second. In order for

an asynchronous receiver to extract timing information from the stop to start bit

transition, its clock must run at many times (≈16) the transmission frequency. This

becomes a less reliable system as transmission rates increase toward those of a

synchronous system.

The second, major difference between synchronous and asynchronous schemes

is in the amount of data transmitted, and the overheads imposed by adding start and

stop bits to a data frame. Since asynchronous schemes relate to low data rates, the

insertion of start and stop bits (which increase overheads by a minimum of 2 bits for

every 8 bits of data - 25%) is not of great consequence. However in synchronous

schemes, which are designed for the high speed transfer of large quantities of data,

these overheads are unacceptable.

Both synchronous and asynchronous schemes are more complex than might

first be envisaged. Thus far we have introduced some of the essential concepts of the

two methodologies. We shall build upon these to provide a practical working

knowledge of serial communications links and particularly of RS-232, which is of

particular importance in manufacturing.


4.6 Error Detection Techniques

Regardless of whether we use synchronous or asynchronous communications

techniques and regardless of how well we engineer a communication link, there is

always the possibility that an error will occur when we transmit data from one device

to another.

The gravity of an error in communications depends entirely upon the

application. For example, if a communication link is established to transfer a part

program from a CAD system to a CNC machine and an undetected transmission error

occurs, then the corrupted program may ultimately result in damage to either the

machine, cutting-tool or work-piece. On the other hand, an error in communications

between a computer and line-printer may simply cause a spurious symbol to appear

on a print-out. For each application, risk factors must be considered and appropriate

error detection and correction measures taken to ensure that a required link reliability

is achieved. Sometimes, such as in the case of a computer to printer link, these

measures may amount to nothing more than accepting that errors will occur on rare

occasions. In any event it is essential that we are aware of the risks involved.

The key point to note about all error detection techniques is that none of them

are 100 per cent effective. In other words, no matter which technique we apply, a

receiving device cannot be assured that it has received a message correctly unless it

can verify the message against its own local reference. Obviously if a receiver

already has a reference copy of the message, then there is no need for transmission in

the first instance. Therefore, when we say that a link between two devices is secure,

we really mean that the probability of an undetected error passing through the link is

very small.

There are a number of error detection techniques in use. The scheme which

one might intuitively expect to be simple and effective is called "echoing". This is


The system relies upon the receiving device sending its incoming message back

to the transmitter. The transmitter checks the echo message with the original and if

they are the same, then it is assumed that the message at the receiver is correct. If the

transmitter notes a difference between the original message and the echo, then the

original message is re-transmitted. The echoing technique is sometimes used to check

part program down-loads from a host computer to older CNCs, but is otherwise not

in widespread use.


Device A Device B

Message

Message

Transmit a Complete Message

Echo Back Complete Message

Figure 4.13 - Error Detection and Correction by Echoing

The most obvious problem with the echoing technique is the amount of time

required to achieve error detection and correction. The system becomes unwieldily

when the length of a message becomes large because we more than double the

amount of time required to send data, even when transmission is correct. For

example, the time taken to echo-send 1 Megabit of data at 10 kbps is greater than 200

seconds when the data is correctly received. If there is a single bit error in the data on

the first transmission a correct transaction takes more than 400 seconds. Add to this

the probability that the echo message may be incorrect (corrupted), while the original

is correct and it becomes apparent that the system is not viable except when no other

alternatives are available.

Two salient points emerge from an examination of the echoing system of error

detection:

(i) Large messages need to be broken down into smaller units for

transmission so that if an error is detected in a unit then only that unit

needs to be re-transmitted (and not the entire message)

(ii) Complete echoing is not practical but a similar system (based upon

smaller message units) can be implemented. An additional piece of

"checking" information (which numerically summarises a message unit)

can be transmitted with each message unit, so that the receiver can judge

for itself whether or not it has correctly received the unit.

These two points are the basis for all error detection techniques used in

communication.


Each unit of information that is transmitted on a link is followed by a piece of

checking data that mathematically relates all the elements in the message unit. The

checking data therefore "summarises" all the contents of the message unit in a single

bit or group of bits. A receiving device takes in both the message and the piece of

checking information. It then performs the same checking calculation on the

incoming message (as the transmitter performed on the outgoing data) and compares

this with the incoming check calculation. If they are the same then the receiver

assumes the message unit is correct - otherwise it assumes the message unit is

incorrect (corrupt). This is shown schematically in Figure 4.14.

Device A Device B

CheckCalculation

Extracted

Data

Local

Calculation

RemoteCheck

Local

Check

Same Different(OK) (Error)

Comparison

Message

Figure 4.14 - Error Detection through Check Calculations

There are two problems with these systems:

• A transmission error in both the check calculation and the message unit

could cause the receiver to mistake an incorrect message unit for a correct

one (and vice-versa).

• Since the checking calculation is physically smaller than the transmitted

data unit it should be evident that it cannot uniquely describe that data.

In other words, one check calculation can accurately describe a number of

totally different data units.

It is because of these two problems that the receiver can never be 100 per cent

accurate in determining the validity of an incoming signal. This is the penalty that

we pay in order to increase the speed of transmission.


In simple statistical terms however, we can see that:

Pr(Eunc) = Pr(Ed)

... (1)

Pr(Euc) = Pr(Ed) . Pr(Ec)

... (2)

Where:

Pr(Eunc) = Probability of an undetected error in a system with no check

calculations

Pr(Ed) = Probability of a data error occurring

Pr(Euc) = Probability of an undetected error in a system with check

calculations

Pr(Ec) = Probability of a check calculation being correct when a data unit is

incorrect

From the two probability expressions shown, it is clear that even if the chances

of a check calculation being correct whilst the data unit is incorrect, are as high as

one in a hundred, then we have still increased the reliability of a "checked" link by a

factor of 100 over an unchecked link.

The simplest form of error-detection used in digital circuits and communication

is referred to as "parity checking". When active, this comes in two different forms,

namely "odd parity" or "even parity". A single parity bit is sent after each unit of

data. In the "odd parity" system, the parity bit is either set or reset in order to make

the total number of "1s" in the data unit (including parity bit) odd. In the "even

parity" system, the parity bit is either set or reset in order to make the total number of

"1s" in the data unit (including parity bit) even. The odd and even parity system

waveforms are shown in Figure 4.15 for the serial transmission of the ASCII

character "u", which has a bit pattern of 01110101.


Time

Time


1 1 1 1 1

0 0 0 0

Parity Bit

1 1 1 1 1

0 0 0

1

Parity Bit

(a) Odd Parity System

(b) Even Parity System


Figure 4.15 - Serial Transmission of ASCII 'u' Under Odd and Even Parity

Parity checking is yet another remnant from the early days of data

communication. There are a number of problems apparent with the system:

• the corruption of 2 data bits or one data bit and the parity bit allow an

error to pass through undetected

• parity checking is usually associated with character-oriented systems.

Although a parity error can be detected with the system, few devices can

automatically request for a re-transmission of a single character (it is too

time consuming to disrupt information flow on a link for the sake of one

erroneous character) and hence the system is of limited use.


The two problems noted above are typical of those associated with all error

checking techniques, but they are more pronounced with the parity system. The

probability of undetected errors slipping through a parity check is higher than with

other techniques. More importantly, parity checking is at the opposite extreme to the

echoing technique in that it breaks messages up into units of individual characters,

which are too small for a practical link. Where the echoing technique demanded the

re-transmission of an entire message in the event of an error, the parity system would

demand a re-transmission of every erroneous character. This constant interruption to

a transmission sequence, and demand for re-transmission of individual characters,

adds unnecessary complexity and overheads to a link.

Despite the fact that the parity feature is seldom utilised, for error correction, it

is still important to us because parity bits are very common items on asynchronous

serial links. Parity checking is normally performed by hardware and therefore it is

vital that two communicating devices are configured to the same parity settings in

order for the link to function. Some devices allow parity to be either odd, even,

switched off or configured so that the parity bit is always 1 (MARK parity / stick

parity odd) or always 0 (SPACE parity / stick parity even). As long as

communicating devices agree on parity, it does not need to become a major issue.

Having examined the two extremes of error detection, we can now focus on

two important intermediate techniques. We now appreciate that a large message

needs to be broken down into smaller units for transmission. In this way, if a unit is

detected as being corrupt then only that unit needs to be re-transmitted, rather than

the entire message. If the units are too small (such as individual characters), then the

process becomes impractical for the reasons noted above. There is no single value of

unit size that is universally adopted as being optimal for message transmission in

serial links. A typical value for a unit may be in the order of a few hundred bytes.

The common names for a basic unit are "block", "data frame", "packet" or

"telegram".

In character-oriented serial links, the Block-Check-Sum, or BCS, is commonly

used as the checking mechanism for blocks of data. Let us assume that we arbitrarily

had a block size of 5 bytes and examine how a BCS might be calculated. Let us

suppose that we wish to transmit an ASCII message "HELLO JACK" from one

device to another. The message is broken up into two blocks, namely "HELLO" and

"JACK" that are transmitted, in turn, with corresponding Block Check Sums. A

common BCS calculation involves taking an "exclusive OR" of corresponding bits

that make up the ASCII values of each data character and transmitting this as the

check-sum. Table 4.2 shows how this is implemented.


Character ASCII Value Block Check Sum

(Running Tally of

Exclusive OR of

Characters)

0000 0000

H 0100 1000 0100 1000

E 0100 0101 0000 1101

L 0100 1100 0100 0001

L 0100 1100 0000 1101

O 0100 1111 0100 0010

(Transmitted Sum)

Table 4.2 - Calculation of an Exclusive OR Block-Check-Sum

There is no single standard that defines the way in which a Block-Check-Sum

calculation is to be performed. Table 4.2 shows only a simple example. However,

the actual BCS calculation selected influences the effectiveness of the BCS in

trapping errors. It is not difficult to perform some probability calculations in order to

quantitatively ascertain the effectiveness of the BCS. That is, to determine the

probability of the BCS character being apparently correct at the receiver, whilst the

message is corrupt. This is done on an individual basis for each specification of a

BCS checking scheme.

In the exclusive-OR scheme shown above, the BCS scheme would fail

whenever the corresponding bits on pairs of characters were incorrect. The scheme

would also fail in situations where a single bit in the data was incorrect and the

corresponding bit in the BCS was also incorrect. In other words, for the above

example, we can consider the data bytes and the BCS as a 6 byte message,

transmitted in the following sequence:

Character Bit Pattern

b7 b6 b5 b4 b3 b2 b1 b0

H 0 1 0 0 1 0 0 0

E 0 1 0 0 0 1 0 1

L 0 1 0 0 1 1 0 0

L 0 1 0 0 1 1 0 0

O 0 1 0 0 1 1 1 1

BCS 0 1 0 0 0 0 1 0


Multiple pairs of errors in any one of the bit columns shown in the example

also make this particular BCS appear correct, even though both the data and the BCS

are incorrect. Try this for yourself by reversing all the values of the underlined bits in

the "b5" column. This form of reasoning can be converted, using permutations,

combinations and the binomial theorem into an expression, which is ultimately

dependent upon the probability of an error in a single bit occurring, or the mean Bit

Error Rate (BER).

Therefore if we wish to ascertain the effectiveness of a BCS calculation, we

need to determine the mean number of bit errors occurring per unit of time. This can

be done by continuously transmitting a known stream of data to a receiver and having

the receiver check each bit of incoming information against its local reference value.

In a manufacturing environment, this needs to be carried out over a time period that

accurately reflects the production environment. The test must have a time profile

where factors such as switching of heavy current machinery, etc. are included. Errors

can then be logged and the mean BER determined for the worst-case scenario.

Ultimately the objective for professionals, designing links in the manufacturing

environment, is to minimise the mean bit error rate before even considering its

influence on BCS calculations. Sometimes this involves the replacement of

conducting links with optic fibre technology and so on. It must be made clear that

check calculations are not a cure for the problem of bit errors - they are a secondary

line of defence against data corruption. Minimisation of error occurrence must

always be the primary defence.

Some communications links in the manufacturing environment are subjected to

"error bursts". These are often caused through switching of high current equipment,

and are characterised by a group (burst) of bits that are in sequence and corrupted.

An otherwise low BER link may be affected spasmodically by these phenomena. If

the duration of an error burst is more than 8 bits, then simple BCS calculations such

as the one described above are unreliable because errors can occur in the same bit of

consecutive characters. This can be visualised by examining the way in which the

"HELLO" packet described above is actually transmitted on a serial link:

H E L L O BCS

01001000 01000101 01001100 01001100 01001111 01000010

♦♦♦♦♦♦♦♦

Error burst

Assuming that all the bits affected by the error burst are set high (say), then it is clear

that corresponding (underlined) bits of consecutive characters may slip through the

BCS.


We therefore use more complex check calculations that are bit-oriented but are

also suitable for character-oriented systems. These are referred to as "Frame Check

Sequences" (FCSs) or Cyclic Redundancy Checks (CRCs). The generic name for

these check digits, which are appended to blocks of data is a "Polynomial Code".

The number of binary digits in a CRC is chosen to reflect the worst case error burst

conditions, but 16 and 32 bit CRCs are predominant in standards for calculations.

An extremely tedious mathematical analysis is required to quantitatively prove

why CRCs are far more effective than BCS calculations in minimising the probability

of undetected errors slipping through to the receiver. It is not the purpose of this

book to enter into this analysis. Suffice to say that the following five principles are

used in calculating a CRC:

(i) An entire packet or block of data is treated as one long binary number

"b"

(ii) The number is multiplied by 2n by adding n zeros to the end of the

number (resulting in the number "B"). The value of n depends upon the

specification for the CRC calculation and is equal to the number of CRC

digits to be transmitted.

(iii) The new number "B" is divided by another selected binary number "g",

which is referred to as a "generator polynomial". The value of "g"

depends upon the specification for the CRC calculation, but it always

contains one bit more than the number of CRC bits to be transmitted

(iv) The remainder of the binary division is the CRC which is transmitted

following the data.

(v) The receiver takes the incoming bit stream (b'), multiplies it by adding

"n" zeros (giving B'), adds the CRC digits (modulo 2) and divides each of

them by the generator polynomial. If the transmission was successful,

then the result of the division (r) is always zero - otherwise it is non-zero


Mathematically, the above steps are expressed by:

B b

CRCB

g

rB

g

CRC

g

B

g

B

g

B

g

B

g

n= ×

=

= +

= +

= +

2

2

...(ii)

Remainder ...(iii)

...(iv)

( )

'

'

'

All the calculations performed above are modulo 2, which means that there are

no carry digits. Therefore "g²" is the same as "g". It also means that if B' and B have

identical bit patterns, then their modulo 2 sum must be equal to zero since:

1 + 1 = 0 and 0 + 0 = 0

Note also that step (iii) in the above sequence is equivalent to performing an

exclusive OR function, bit by bit between the modified frame contents and the

generator polynomial.

The major characteristic of the polynomial code technique is that all error

bursts with a duration of fewer bits than the generator polynomial are detected. It is

also important to note the short-hand way in which the generator polynomial is

expressed in standards. For example, the generator polynomial within the CCITT

specification for CRCs is given by:

x16 + x12 + x5 + x0

This is equivalent to the number 10001000000100001. Clearly, the polynomial

indices therefore represent the bits in the generator that are set to 1.


4.7 Signal Modulation

Up until now we have only examined communications systems where the

conducting communication medium (cable) can only carry one bit of information at

any instant in time. This observation followed on from a brief look at Kirchoff's

Voltage Law, which says that at any one point in any electrical circuit only one

voltage can be present at any instant in time. We also noted with interest, the

wastefulness of long-distance parallel communication, where a single cable conveyed

only one bit of information in any one data transfer. The logical progression was to

examine serial communication, which was slower but more cost effective in terms of

cabling.

We now need to accept that it is possible for a single cable to carry more than a

single bit of information at any instant in time, whilst still obeying Kirchoff's Voltage

Law. There are many ways to achieve this. The most obvious is just to add data

voltage waveforms together and transmit the total voltage - but then how would we

ever decode them at the other end? The answer is that we can't unless each of the

individual voltage waveforms have been given unique characteristics before they are

added together and transmitted. Then, at the receiving end, we can sort out the

individual data voltage waveforms (from the total waveform) by searching for the

unique characteristics.

We therefore need a more complex representation for binary data, that will

allow many signals to share the same link, by effectively creating "channels" within

the medium. This is achieved through signal modulation. This technique encodes

each waveform with unique, frequency dependent characteristics that can be readily

decoded.

The signal modulation used in digital communications is completely analogous

to that used in radio or television broadcasting. You will note that between a

television or radio transmitter and your receiver there is only one communication

medium (the air) - yet many signals use the same medium simultaneously through the

technique of modulation.

In order to understand how modulation works, we need to understand the

relationship between a signal and its frequency spectrum. Mathematically, the

frequency spectrum of a time dependent signal, x(t), is obtained by taking its "Fourier

Transform" X(f). This is achieved through the following transformation:

⌠+∞

X(f) = x(t) . e-j2πft dt

⌡-∞


X(f) is referred to as the "frequency domain" representation of the signal x(t).

The symbol "j" is used to denote the "imaginary number".

The "Inverse Fourier Transform" of the function X(f) takes us back to the

original "time domain" representation of the signal x(t):

⌠+∞

x(t) = X(f) . ej2πft df

⌡-∞

This looks somewhat complicated, but in physical terms it really means that we

can view energy (or voltage) from two different perspectives - frequency and time.

As an example, the frequency spectrum of a simple square pulse, looks as shown in

Figure 4.16.

Voltage

Time+τ+τ+τ+τ−τ−τ−τ−τ 0000

1v

Voltage

Frequencyπ/τπ/τπ/τπ/τ0000 2π/τ2π/τ2π/τ2π/τ

2τ2τ2τ2τ

Figure 4.16 - Frequency Spectrum of Square Pulse


So, there are two ways in which we can identify voltage patterns on a

transmission line - we can either look at their time domain or frequency domain

representations. Up until now, we have only examined the time domain. In Figure

4.16, the frequency domain representation of the square pulse is much more complex

than the time domain representation. Often the reverse is true, as for the unlimited

cosine voltage waveform,

v(t) = cos 2πfct

whose frequency spectrum is shown in Figure 4.17.

Frequency

Voltage

+fc-fc

Figure 4.17 - Frequency Spectrum of an Unlimited Cosine Waveform

The frequency spectrum of a cosine voltage wave is composed of two infinitely

tall and narrow peaks at frequency values corresponding to the frequency of the

cosine waveform. If we were to be pedantic, each peak should have an "∞/2" height

because the total wave energy is divided equally between the two peaks.

Does Figure 4.17 imply that if we output a cosinusoidal voltage waveform from

a voltage oscillator, that we would measure infinite voltage peaks, using a voltmeter

centred at that frequency? The answer is no. The frequency spectrum shown in the

above example is for a cosine waveform that starts at negative infinity in time and

ends at positive infinity in time. The frequency spectrum of a realistic time-limited

cosine waveform, of frequency fc, which starts at time -τ and ends at time +τ is



Voltage

Frequency0000fc fc

Figure 4.18 - Spectrum of Time-Limited Cosine Waveform

The height and width of the main peaks, depend upon the time duration of the

cosine waveform. The larger the value of "τ" the taller and narrower the main peaks.

As the time duration of the waveform approaches infinity (reflecting infinite energy),

the spectrum approaches that shown in Figure 4.17. However, we commonly use the

spectrum shown in Figure 4.17 as an approximation when analysing systems.

Taking the argument further, we could look at a transmission line, where the

voltage waveform (as a function of time) was the sum of 4 cosine functions, each of

differing frequency and amplitude:

v(t) = A.cos 2πf1t + B.cos 2πf2t + C.cos 2πf3t + D.cos 2πf4t

The frequency spectrum for this waveform is the sum of the spectra of the

individual waveforms. However, if one plots the time domain function, using some

arbitrary values of frequency and amplitude, then a very untidy waveform emerges. If

any individual component is significantly larger than the others, then the total

waveform looks like a distorted version of the largest individual component. On the

other hand, when we look at the frequency spectrum of the total waveform, it is

surprisingly simple. This is shown in Figure 4.19, where f2 > f3 > f4 > f1.

What has been achieved in this example is of considerable interest to us. We

have a number of different waveforms on the transmission line simultaneously

(added together), giving us a frequency spectrum where individual components can

be easily singled out.


Voltage

Time

1/f1

2/f1

(a) Distorted Resultant Time Domain Waveform

Voltage

Frequency

0 f1

f4

f3

f2

-f1

-f4

-f3

-f2

(b) Frequency Spectrum of Multiple Cosine Waves

Figure 4.19 - Multiple Cosine Waves on Transmission Line

The conclusion that can be drawn is that if we choose our time domain signals

appropriately, then it is possible to achieve a frequency spectrum in which individual

components can be readily identified. For example if we transmitted the complex

time domain signal of Figure 4.19, then we could recover any individual component

of that signal at the receiver by "filtering" in the frequency domain. A "filter", in

communications terms, is an electronic device that blocks out all frequencies except

those within a desired range. The effect of a filter is shown in Figure 4.20, which

schematically shows how the f2 component of our sample waveform can be

retrieved.


Voltage

Frequency

0 f1

f4

f3

f2

-f1

-f4

-f3

-f2

Band-Pass Filter

Figure 4.20 - Filtering out Desired Signals

The question that now needs to be examined is how a signal, which does not

give us a desired frequency spectrum, can be forced into a form where it does behave

in an appropriate manner. For example, let us assume that we wish to transmit two

signals on a communication link simultaneously, and that their spectra are as shown

in Figure 4.21.

Voltage

Frequency

Voltage

Frequency

1v

1v

Signal 1

Signal 2

Figure 4.21 - Frequency Spectra for two Different Signals


Simply adding the two voltage waveforms (and spectra) together, as we did

before, will produce a resultant waveform that is not only distorted in the time

domain, but which is also not recoverable in the frequency domain, from filtering.

This is shown in Figure 4.22.

Voltage

Frequency

1v

Figure 4.22 - Result of Adding Waveforms of Figure 4.21

However, by "treating" each of the signals prior to adding them, we can keep

their respective spectra discrete. For example, if we electronically multiply signal 1

with a cosine wave of frequency f1 and signal 2 with a cosine wave of frequency f2,

(where f2 > f1) the frequency spectrum of the combined signals is shown in Figure

4.23.

Voltage

Frequency

1/2v

f f-f-f2 1 1 2

Figure 4.23 - Frequency Spectrum for "Treated" Signals


Direct multiplication of each of the signals with a cosine wave of a specific

frequency (referred to as carrier frequency) is known as "Double Side-band

Modulation" or DSB. It is easily achieved using fundamental electronic circuits.

Note well the effect of this procedure. Apart from the fact that the original signals

are "mirrored", clearly they have been "shifted" on the frequency spectrum away from

their original "baseband" positions.

Provided that we limit the frequency range over which individual signals exist

(the bandwidth), then we can use modulation to create many channels on the same

communication medium. This is shown in Figure 4.24.

Voltage

Frequency

f f-f-f2 1 1 2

Channel 1 Channel 2

Figure 4.24 - Channels Within Communications Media

Mathematically, we can say the above phenomenon arises through the

"convolution" of frequency domain functions that occurs when we multiply time

domain functions. That is:

a(t) . b(t) ↔ A(f) * B(f)

where the asterisk defines the convolution of the two frequency domain functions.

The convolution of two functions is defined as follows:

⌠∞

A(f) * B(f) = A(Ω) . B(f-Ω) dΩ

⌡-∞


In other words, if two functions are multiplied in the time domain, then their

spectra are convolved in the frequency domain. One can verify the result of Figure

4.23 by graphically convolving the waveforms of Figure 4.21 with the frequency

spectra of two cosine waves of differing frequencies.

Graphical convolution is not as complex as the mathematical expression might

suggest. Assume that the spectrum of the signal waveform is A(f) and that the

spectrum of the cosine waveform is B(f). A(f) is plotted on a new set of axes

(voltage versus Ω) to represent A(Ω). The cosine spectrum is also redrawn on the

new axes to represent B(Ω). In order to represent B(-Ω), we need to reflect the

waveform about the zero frequency point. In the case of the symmetrical cosine

spectrum, this results in the same waveform. If we substitute arbitrary values of "f"

into the expression B(f-Ω) we can move the B(-Ω) along the Ω axis. Whenever the

two waveforms overlap, we can calculate the area of the product. If we plot the

resultant area as a function of "f", then we have the convolution of the waveforms.

The "Dual" situation of the above convolution is also true and hence, if two

functions are multiplied in the frequency domain, then their time domain equivalents

are convolved. That is:

A(f) x B(f) ↔ a(t) * b(t)

where

⌠∞

a(t) * b(t) = a(τ) . b(t-τ) dτ

⌡-∞

Leaving aside the mathematics of the situation, we now ask a question. Why

can there not be an infinite number of channels on any one communications cable?

As with any physical piece of apparatus there are always practical limits to operation.

The higher up in frequency that we move signals (through modulation on a

communication cable) the more the output signal is attenuated by that cable.

The limits or the "total bandwidth of the cable", are entirely dependent upon the

physical make-up of the cable that is being used to convey the signal. When the

entire cable bandwidth is used to transmit only one channel, then we refer to this as a

"baseband" transmission. When the cable is divided into a number of channels then

we refer to this as "broadband" transmission.


The earlier example of modulation, or signal channelling, is only one of many

techniques used to achieve the same result. DSB modulation is not a common

technique used for digital communications. Common modulation techniques used in

conjunction with serial communications links include:

(i) Amplitude Modulation (AM)

(ii) Frequency-Shift Keying (FSK)

(iii) Phase-Shift Keying (PSK)

In an Amplitude Modulated (AM) system, a constant frequency, sinusoidal

waveform is used to represent binary data. This waveform is referred to as the

"carrier". The amplitude of the carrier varies depending on whether a binary "1" or

"0" is transmitted. This is shown in Figure 4.25.

Time

Voltage

Time

Voltage

1 0 1Raw Data

Modulated Data

Figure 4.25 - Amplitude Modulated Binary Signal


If we select different carrier frequencies on the same communications link, then

it is possible to have a number of different channels, each transmitting different

binary information. In practice this form of modulation is not widely used, primarily

because all the information is contained within the amplitude of the carrier. Line

attenuation therefore affects make it difficult to maintain bit accuracy in complex

communications systems.

In a Frequency-Shift Keying (FSK) system, a constant amplitude sinusoidal

waveform is used to represent binary data. However, the frequency of the waveform

varies depending on whether a binary "1" or "0" is transmitted. This is shown in

Figure 4.26.

Time

Voltage

Time

Voltage

1 0 1Raw Data

Modulated Data

Figure 4.26 - FSK Modulated Binary Signal

This type of modulation is very commonly used for transmission of binary data

at relatively low bit rates (300 - 1200 bits/second). Multiple channels can be

achieved by representing binary numbers on one channel with one pair of sinusoidal

frequencies, and on another channel by a different pair of sinusoidal frequencies.


The Phase-Shift Keying (PSK) system of modulation is based on the

transmission of a constant amplitude, constant frequency sinusoidal waveform. The

phase of the waveform varies, depending on whether a binary "1" or "0" is

transmitted. This is shown in Figure 4.27, where there is a 180° phase change in the

carrier between a binary 1 and 0. As with other modulation techniques, multiple

channels can be supported on the same cable by using different pairs of carrier

frequencies for each channel.

The form of PSK shown in Figure 4.27 requires the receiver to maintain a

reference carrier, with which to compare the incoming signal and is sometimes

referred to as "Phase Coherent" PSK. This coherent form of PSK modulation is

difficult to decode and therefore an alternative form, referred to as "Differential" PSK

is often used. In differential PSK, the carrier signal shifts by 270° in phase to

indicate a binary 1 and by 90° to indicate a binary 0.

Time

Voltage

Time

Voltage

1 0 1Raw Data

Modulated Data

Figure 4.27 - PSK Modulated Binary Signal


Note that regardless of the form of modulation, if we have two devices

connected together, we can have a full duplex communication link over a single

cable. We achieve this by having two channels for transmission. One device

represents binary numbers through the use of one pair of frequencies and the other

device uses another pair of frequencies. We call this a "forward" and "reverse"

channel arrangement

The electronic circuits that are used to decode modulated signals are referred to

as "demodulators". Demodulation circuits are designed to isolate specific

components from the frequency spectrum of an incoming signal (as shown

simplistically in Figure 4.20 for DSB). The specific mechanism by which

demodulation is achieved depends entirely on the type of modulation used and the

design principles of these circuits are outside the scope of this book.

Modulation can be used in two-way serial communications (half-duplex and

full-duplex) and therefore intelligent devices need both a modulator and a

demodulator circuit for transmission. The combined unit is referred to as a

"Modem".

Referring back to our earlier, point to point serial link (Figure 4.5), where we

observed that it was necessary to have two wires for simultaneous bi-directional

transmission (full-duplex), we now see that with modulation only a single wire (and

reference or ground line), with forward and reverse is required. In order to enhance

the transmitted signal, a line-driver system, which amplifies the modulated signal is

also commonly used. In very long links, line drivers are placed at strategic points

along the link to ensure that the signal does not attenuate unacceptably along any one

section. The complete system for long distance transmission is shown schematically

in Figure 4.28 (a).

Once we have modulated a signal so that we can realise a multi-channel

communications system for transmission and reception of data, then we can work

with a range of different media - such as air, optic fibre or co-axial cable. The most

prevalent data communications media are co-axial and optic fibre cables, illustrated

in Figures 4.28 (b) and (c) respectively.

A Co-axial cable is composed of a signal-carrying, central conductor, which is

enclosed in an outer conducting shell. The outer conductor forms the other half of

the wire pair (signal return path). The two conductors are isolated by a dielectric

material and the complete structure is housed in a non-conducting jacket. The

physics of the co-axial cable design is such that it is highly immune from electro-

magnetic interference.


Transmit Channel

Receive ChannelDevice A Device B

Modem&

Line-Driver

Modem&

Line-Driver

(a) Full-Duplex Serial Data Transmission Over Long Distances

Centre Conductor

Dielectric

Copper Braid

PVC Jacket

(b) Typical Conducting Co-axial Cable for Multi-channel Communication

(Signal Ground)(Data Conductor)

Duplex OpticFibre Cores Tight Buffers

Surrounded byKevlar Fibre forReinforcement

PVC Jacket

(c) Typical Non-Conducting Dual-Core Optic Fibre Cable for Multi-channel Communication

Figure 4.28 - Serial Data Transmission Using Long Distance Cables

Optic fibres are fine glass filaments sheathed in a cable. A light impulse at one

end of a filament is reflected along the sides of that filament to the target end. The

properties of the filament are such that light impulses can be transmitted over very

long distances without significant attenuation. Electrical signals can be converted to

light impulses through the use of specialised semi-conductor devices such as Light

Emitting Diodes (LEDs). Conversion from light impulses back to electrical signals is

also possible.


The beauty of optic fibre cable is that, unlike all conducting cables, it is not

subject to electro-magnetic interference. This characteristic alone is of prime

importance in the industrial environment. Optic fibre cable also has a very high

bandwidth, thus allowing for a large number of communications channels. For these

reasons optic fibre technology is gaining widespread acceptance. The only

significant disadvantages of optic fibre are that connectors and terminators are more

complex, and naturally, there must also be (electrical ↔ optical) interface circuitry at

either end of a communication link. These factors obviously contribute to the overall

cost of establishing an optic fibre link.

To conclude our discussion on modulation, we should note that its channelling

properties enable a single cable to provide not only multiple digital data channels, but

also voice and video channels. This is a very important, because it means that a

single trunk cable, running through a large organisation can handle an enormous

range of different communications functions, thus amortising the high installation

costs.


4.8 DCE and DTE

Modern microprocessor based devices are often categorised by names or

functionalities that are now either redundant or not directly applicable. A prime

example of this is in the way such devices are configured for serial communications

purposes.

In the early years of computing, communications between a dumb-terminal or

teletype machine and a distant mainframe computer occurred though public

communications lines and modems. Although it is now possible for modems to

connect directly to a computer bus, some modems are connected to their local

computer, terminal or teletype through a short, asynchronous serial link. This is


Serial

LinkTerminal Modem

DTE DCE

Public Line Serial

LinkModem Computer

DTEDCE

Figure 4.29 - Long Distance Connection of Terminals to Computers

On top of each device in Figure 4.29 is a label, specifying that a device is either

Data Communications Equipment (DCE) or Data Terminal Equipment (DTE). It

seems a relatively logical definition. The two acronyms DCE and DTE are said to

define the "gender" of the device. At one stage they also defined the gender of plug

connectors, the pin configuration of communications plugs and so on. DTE devices

and plugs were designed to connect directly to DCE devices and plugs.

Unfortunately the definitions shown above have, through changing technology

and applications, been corrupted since their initial inception. Nowadays, one often

comes across computers that are cited by their manufacturers as being DCE rather

than DTE devices. Some computers are configurable to be either DCE or DTE. If it

were not for the problems of plug connections and plug configurations then the

nomenclature itself would not be of relevance.


As it happens, there is often a need to plug two devices together and therefore it

is essential that we know the correct gender of each device, in order for plugs and

wiring to be connected accordingly. For example, two devices of the same gender

need specially reversed wiring in order to be interconnected.

Ultimately, we need to determine the gender of devices before we attempt to

join them with a communication link. Sometimes this is achieved through reading a

manufacturer's specification (if we believe that we can trust their understanding of

DCE and DTE) and sometimes gender must be determined by electrical testing of

plugs and connectors. The electrical testing can only be done after consulting the

appropriate communications standard. As you may have guessed, each standard

defines specific electrical properties for plugs which are of DCE and DTE genders,

and it is these properties we need to test.


4.9 UARTS and USRTS

Now that we have examined some of the broader aspects of serial

communications, we can return briefly to two important integrated circuits that are

the basis of parallel to serial conversion within a computer. The Universal

Asynchronous Receiver Transmitter (UART) and the Universal Synchronous

Receiver Transmitter (USRT) chip are the basic, internal hardware units of

asynchronous and synchronous computer communication. These circuits are

generally used for character-oriented transmission schemes, since they divide bit

streams into blocks of 7 or 8 data bits, encapsulated in stop and start bits.

The schematic diagram for the UART is shown in Figure 4.30, together with its

links to the computer data bus. The computer address bus has been omitted to

preserve some clarity.

Computer

Data Bus

Transmit

Buffer

Transmit

Register

Control

Logic &

Status

Registers

Clock

Receive

Buffer

Receive

RegisterClockClock

ParityOut

ParityIn

Parity In

Parity OutUART

Serial TransmitSerial Receive

Circuit

Interrupt

Figure 4.30 - Schematic of UART


The control logic block within the UART is responsible for adding parity bits,

stop and start bits to outgoing characters. The control block also strips incoming

frames of stop and start bits, checks incoming parity bits and the frames themselves,

for validity. It is capable of detecting errors in:

• parity

• overrun

• framing.

Overrun errors occur when incoming characters enter the buffer faster than they

can be cleared. This often happens when the bit rate (clock speed) on the

transmitting device does not match that of the receiver. Framing errors occur when a

stop bit is not received after the control logic has counted the correct number of data

bits within a frame.

The control logic circuitry of the UART has a number of internal registers that

contain all the relevant status information for the device. These registers are

generally mapped onto the computer's memory and can be accessed from the main

CPU. UART overrun, parity and framing errors do not halt the operation of the

device. These errors are instead flagged within the various status registers of the

UART and it is the responsibility of the CPU to act upon them.

Most UARTs are designed to "assert" an interrupt line when data has been

received. This enables the CPU to run an Interrupt Service Routine (ISR) that

removes data from the volatile registers and buffers in the UART and places it into a

more stable area of general purpose computer memory.

Another important feature of the control circuitry within a UART is the mode

control register. By transferring an appropriate bit pattern from the computer's CPU

into this register, the UART can be programmed for a number of different parity

schemes, including:

• odd parity

• even parity

• mark parity (always 1)

• space parity (always 0).

The number of stop bits (1 or 2) and the number of data bits within a frame

(5,6,7 or 8) can also be programmed through the status register. Bit rates in the order

of 110 bps to 19200 bps can be provided by the control logic, which scales the clock

signal supplied by the external clock circuit.


For synchronous transmission schemes the USRT is used for conversion

between serial and parallel data formats. Its schematic is shown in Figure 4.31. In

principle, the USRT is similar to the UART, except that the incoming data is clocked

into the receive register with a clock signal that is derived (extracted) from the data

itself.

From a user point of view, the key point to note about both the UART and the

USRT devices is that they perform hardware checking of incoming data. Some of the

hardware checking cannot normally be by-passed. This is of importance because it

means that if these devices are not "programmed" (set-up) correctly by the CPU (ie:

user-program), through use of the UART/USRT mode control registers, then they

will continually flag and report hardware errors back to the CPU. These hardware

errors and subsequent mismatches in framing, cause incoming data to be interpreted

incorrectly by user software.

Computer

Data Bus

Transmit

Buffer

Transmit

Register

ControlLogic &

Status

Registers

Clock

Receive

Buffer

Receive

RegisterClock

ParityOut

ParityIn

Parity In

Parity OutUSRT

Serial TransmitSerial Receive

Circuit

Interrupt

ClockExtraction

Clock

Figure 4.31 - Schematic of USRT


The "programming" of a USRT or UART involves matching its parameters to

those of the device at the other end of the transmission line. These parameters are

entered as data in special control registers in each device. This fundamental step of

setting and matching:

• data bits within a frame

• bit rate

• parity

• stop bits within a frame (UART only)

must always be carried out as a first priority.

Without a matching set of these key parameters on transmitting and receiving

devices, there can be no sensible interpretation of the data transferred on a serial link.

143

Chapter 5

Serial Data Communications

- Hardware Application

A Summary...

Asynchronous communications techniques. The RS-232C System. Definitions and

shortcomings. How to physically link devices on the RS-232C standard. Extending

the horizons of serial communications through optic fibres. The balanced electrical

circuit of RS-449. The 20mA Current Loop System. Cable considerations and

precautions.


♦ You want to learn about point to point asynchronous serial links and how to

apply them in practice

♦ You want to learn how to link RS-232C devices

♦ You think you already understand the RS-232C system!


5.1 The RS-232C Standard

It is somewhat ironic to use the word "standard" in conjunction with this

section heading. We will shortly discover that in practice, there is little that remains

as standard in the common application of the Electronic Industries Association (EIA)

RS-232C specification for asynchronous serial communications links.

The RS-232C (commonly abbreviated RS-232) standard is also identified as

one of the "V" series of specifications from the Commité Consultatif Internationale

de Telegraphie et Telephonie (CCITT). As a result of this, RS-232 is sometimes

referred to as the V.24 standard. The system was originally introduced as a

specification for the connection of Data Terminal Equipment (DTE) to a Post

Telephone and Telecommunications (PTT) modem. This is shown schematically in

Figure 5.1.

DTE DCE DCE DTE

Terminal Modem Modem ComputerPublic LineRS-232

Link

RS-232

Link

Figure 5.1 - Original Application of RS-232 C (V.24)

The RS-232 specification was designed to fulfil the needs of the environment

shown in Figure 5.1. Its primary function application was in short-distance, low-bit-

rate links between devices (computers and modems) in clean-room environments.

The problems associated with RS-232 have come about largely because we have

extended its use to a vast range of different applications, for which it was never

intended.

The RS-232 port on each of the devices shown in Figure 5.1 is driven by a

Universal Asynchronous Receiver Transmitter (UART). The UART performs

conversion of outgoing data from parallel form to serial form and incoming data

from serial to parallel form. In addition, it is also equipped with special inputs and

outputs, which are used to co-ordinate the flow of data with an external device.

These special purpose inputs and outputs are referred to as the hardware hand-

shaking lines.

Serial Data Communications - Hardware Application 145

Figure 5.2 shows a schematic of the UARTs in DCE and DTE devices and the

way in which data transfer and hand-shaking occurs in the RS-232 system. Hand

shaking inputs and outputs in Figure 5.2 are signified by a circle containing the input

or output number (on the UART). An inequality sign (< or >) inside the circle

denotes the normal direction of information flow with respect to the local device.

<1

>1

<2

>2

<3

<1

>1

<2

>2

<3

Output

Register

Input

Register

InputRegister

OutputRegister

Transmit Data

Clear to Send

Request to Send

Data Set Ready

Data Terminal Ready

Carrier Detect

Receive Data

Signal Ground

DTE UART DCE UART

Figure 5.2 - Schematic showing DCE and DTE UARTs and Hardware Hand-

Shaking on an RS-232C Link

In Figure 5.2, the "Request to Send", "Clear to Send" and "Carrier Detect" lines

are directly responsible for switching data transmission on and off. The "Data Set

Ready" and "Data Terminal Ready" lines are used so that DCE and DTE devices,

respectively, can indicate whether they are powered up and ready for communication.

We will look at these lines in more detail as we proceed through this chapter, but for

the moment we only need observe the structure of the hand-shaking in relation to the

UARTs.

We also need to recognise at this early stage that RS-232 is one of the most

important of all the communications specifications associated with manufacturing, if

for no other reason than because it is the most widely used and misunderstood

system. For all the sophisticated communications networks that are available for

manufacturing, few cause as much frustration and irritation as this one standard.

Most computer controlled devices in manufacturing have, what are referred to, as

"RS-232 compatible" communications ports. As we progress through this chapter,

we shall see just how much (or how little) this actually means to the system designer.


5.2 The RS-232C Connectors

There are two, very common connectors (plugs) used for RS-232

communications. These are "D" shaped connectors that come in either a 25 pin

(called DB25) or 9 pin (called DB9), male or female form. These are shown in

Figure 5.3. As with most elements of the specification, "D" plug configurations are

not universally and some equipment manufacturers choose to use a totally different

connector. For example, round "DIN" plugs are sometimes used in an industrial

environment because they are more rugged.

Pin

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

18

20

21

22

23

24

25

Pin

(a) DB25 Connector Plug

Pin

1

2

3

4

5

6

7

8

9

(b) DB9 Connector Plug

Pin

Figure 5.3 - Common RS-232 Connector Plugs

Table 5.1 is provided for reference and shows the side-by-side pin functionality

for both the DB9 and DB25 RS-232 connectors. Again, these pin configurations are

not universally adopted, so we need to check manufacturers' specifications for each

application. We also note that the 9 pin connectors obviously cannot accommodate

the same number of signal lines as the 25 pin connectors. Therefore how can the 9

pin connectors be used? As it happens, modern RS-232 applications require only the

9 pins of the DB9 connector in order to function. Nowadays, the extra pins on the

DB25 connector are rarely used in equipment connections.


Function

Abbreviation Normal

Source of

Signal

DB25

Pin

DB9

Pin

Protective Ground GND 1

Transmit Data TXD DTE 2 3

Receive Data RXD DCE 3 2

Request to Send RTS DTE 4 7

Clear to Send CTS DCE 5 8

Data Set Ready DSR DCE 6 6

Common Signal Ground COM 7 5

Carrier Detect CD DCE 8 1

Negative Voltage Rail -V 9

Positive Voltage Rail +V 10

11

Secondary Received Line Signal

Detector

DCE 12

Secondary Clear to Send DCE 13

Secondary Transmitted Data DTE 14

DCE Transmitter Signal Element

Timing

DCE 15

Secondary Received Data DCE 16

Receiver Signal Element Timing DCE 17

18

Secondary Request to Send DTE 19

Data Terminal Ready DTR DTE 20 4

Signal Quality Detector SQD DCE 21

Ring Indicator RI DCE 22 9

Data Signal Rate Selector DSRS 23

DTE Transmitter Signal Element

Timing

DTE 24

25

Table 5.1 - Pin Numbers and Functionality of RS-232C Plugs

Based Upon DB25 or DB9 Connectors


When we talk of data communications, we sometimes refer to the gender of a

device in terms of whether that device is Data Terminal Equipment (DTE) or Data

Communications Equipment (DCE). In terms of the original intention of RS-232,

these terms had a good deal of significance. Unfortunately, since the RS-232 system

is now used in many different areas, the practical applications of the specification

have muddled the original meanings of the gender. For this reason, some modern

computerised devices turn out to be DCE whilst others are DTE, and still others can

be switched from DCE to DTE. The only way to be certain is by electrical testing of

the connectors, and we will look at techniques for this in subsequent sections.

When we talk of RS-232 communications, we also need to talk about the

gender of hardware connectors and whether they are male or female. If the original

RS-232C definitions were strictly adhered to, then all devices with male connectors

could be identified as DTE and all devices with female connectors could be identified

as DCE. However, this is yet another specification that is not upheld in practice. It is

therefore possible for DTE devices to have female connectors and DCE devices to

have male connectors.


5.3 Basic RS-232 Connections

For a few brief moments let us forget the ugly real world and concentrate on

the all too rare situation, where two RS-232 devices are compatible and can be

directly connected to one another. From this point onwards we shall only use the pin

numbers as they are defined for a DB25 connector in Table 5.1. The RS-232

connection is shown in Figure 5.4, where a DTE device is connected to a DCE device

through a 9 wire cable, with 25 pin connectors at either end. Note the terminology

that has been used to define the direction of signals with respect to each device, the

">" and "<" symbols act as arrowheads indicating the direction of flow.

TXD

RXD

COM

RTS

CTS

DSR

DTR

CD

RI

DTE DCE

2 >

3 <

7

4 >

5 <

6 <

20 >

8 <

22 <

> 2

< 3

7

> 4

< 5

< 6

> 20

< 8

< 22

Figure 5.4 - Basic 9 Wire RS-232 Connection of DTE to DCE

It seems to go against the entire purpose of serial communications to use 9 lines

to transfer data. In fact only three lines are essential for full-duplex RS-232

communications. These are the TXD, RXD and COM (Signal Ground) lines. The

other hardware hand-shaking lines can be omitted by selective design in many

applications.


Hardware hand-shaking on RS-232 links is extremely undesirable, purely

because of the variations that exist in non-standard links (that is, when we use RS-

232 for connecting devices other than computers and modems together). If one has

influence over the design of a non-standard link then it should be avoided altogether.

Unfortunately, understanding the hardware hand-shaking is a necessary evil because

a large number of devices (particularly printers) already use it extensively and must

be accommodated accordingly.

Before we proceed any further, we need to examine how binary data is

represented on the RS-232 link. The voltage levels for RS-232 logic levels are

shown in Figure 5.5. Note well the inverted logic and also the error margin between

outputs and inputs. This margin is designed to cater for attenuation in the lines.

-15v

-5v

+5v

+15v +15v

-15v

-3v

+3v

Logic 0SpaceEnable

TransitionRegion

Logic 1MarkDisable

Logic 1MarkDisable

TransitionRegion

Logic 0SpaceEnableError Margin

Error Margin

RS-232 Outputs RS-232 Inputs

Figure 5.5 - Logic Voltage Levels for RS-232

Fortunately for users, the RS-232 voltage ranges shown in Figure 5.5 are

generally adhered to in most implementations of the specification. Another feature

of RS-232 that is universally adhered to, is that all the outputs and inputs are

"electronically buffered". In other words, it is possible to short-circuit any two pins

on an RS-232 port without causing damage to the circuitry. In light of the amount of

experimentation that is often required to establish an RS-232 hardware link, this is an

absolutely vital feature of the system.


Now that we have established the correlation between voltage levels and binary

logic levels, we can examine what should theoretically happen, in terms of hardware

hand-shaking, on an operational link. We use the model shown in Figure 5.6 as the

basis of our examination and assume that the entire 9 wire connection is in place for

the RS-232 link. As fate would have it, the link of Figure 5.6 can be used in either

half-duplex or full-duplex mode and the hardware hand-shaking differs depending

upon which mode is active. The explanation which follows attempts to define both

the half and full-duplex hand-shaking arrangements.

DTE DCE DCE DTE

Modem Modem

Public Telephone Line

RS-232

Link

RS-232

Link

Computer

A

Computer

B

Figure 5.6 - Basic Model for RS-232 Hand shaking

Let us assume that Computer A wishes to access Computer B by dialling it on

the telephone network. In the normal course of events, once Computer A dials,

Computer B should respond with an answering tone, then a brief log-on message

(prompt) to Computer A. The normal communications exchange then begins. The

following hardware hand-shaking sequence occurs:

(a) If Computers A and B are both ready for communications then they each

enable their Data Terminal Ready (DTR) lines.

(b) If Modems A and B are both ready for communications then they each

enable their Data Set Ready (DSR) lines.

(c) After Computer A has dialled the number, Modem B enables its Ring

Indicator (RI) to tell Computer B that it has been called.

(d) Computer B responds to the Ring Indicator by enabling its Request to

Send (RTS) line.

(e) When Modem B receives an RTS from Computer B it transmits a carrier

tone across the phone line to Modem A.


(f) When Modem A receives the carrier signal from Modem B, it enables its

Carrier Detect (CD) line. In a half-duplex link, this tells Computer A that

it should not send data because computer B wishes to transmit. In a full-

duplex link, an enabled CD tells Computer A that the link is active.

(g) After a short delay (which gives the A side time to get ready to receive

information) Modem B gives Computer B a Clear to Send (CTS) signal

indicating that it should now proceed with data transmission.

(h) Computer B transmits its message to Modem B, which then modulates

the binary information into data tones. In a half-duplex link, when

Computer B has finished transmission it disables its RTS line. In a full

duplex link both DTEs keep their RTS lines enabled.

(i) In a half-duplex link, when Modem B notes that the RTS line is disabled,

it stops transmitting the carrier to Modem A. Modem A responds by

disabling its Carrier Detect. In the full-duplex link the carrier always

remains on.

(j) In the half-duplex arrangement, when Computer A notes that the Carrier

Detect is disabled, it enables its Request to Send line in order to send a

response message.

(k) After a short delay (which gives the B side time to get ready to receive

information) Modem A responds to the Request to Send signal from

Computer A with a Clear to Send signal. Computer A can then transmit

its data.

This two-way process continues until neither of the devices has any more data

to transmit. The process terminates and the devices disconnected from the phone

lines. The entire process is shown schematically in Figure 5.7. Note the convention

where enabled signals are qualified by a "↑" and disabled signals are qualified with a

"↓".


Handshaking Signal Flow

Computer

A

Computer

B

Modem

A

Modem

B

Telephone LinesDTR

DSR

DTR

DSR

RIDial Number

RTSCarrier ONCD

CTS

Tx DataData TonesRx Data

RTSCarrier OFFCD

RTS Carrier ON CD

Tx Data

CTS

Data Tones Rx Data

DSR DSR

Time

Figure 5.7 - Basic RS-232 Hardware Hand shaking Model for a Half-Duplex

Communications Link


5.4 Complex RS-232 Connections

Following the discussions of section 5.3 a number of questions need to be

raised:

• How do these computer to modem interfaces relate to other RS-232

implementations?

• Do all RS-232 ports respond with the same hand-shaking sequences

noted in 5.3?

• How can we tell which device is DCE or DTE?

• What happens if we want to interface two DCE or two DTE devices to

one another?

The answer to the first question is perhaps the simplest. RS-232 was designed

for the environment and hand-shaking described in section 5.3. That is, for computer

to modem links. However, because such a large proportion of computer equipment

was fitted with an RS-232 port, countless other communications applications have

since developed. These include computer to printer or plotter, computer to computer

and computer to machine communications. Although all the RS-232 hand-shaking

lines, described in section 5.3, are labelled in terms of their use with modems, there

is no reason why they cannot be used for other applications. Unfortunately, as these

new applications developed, the hand-shaking sequences, described in 5.3, were of

less and less relevance and manufacturers strayed away from the original standard.

The net result is that we use RS-232 links for an enormous range of

applications for which it was never intended. We are left with hand-shaking signals

that have little or no relevance to their application and to make matters worse,

equipment manufacturers vary the operation of hand-shaking lines to suit their own

needs. So in answer to the second question we can say no - not all RS-232 ports

respond to hand-shaking in exactly the same way.

We now move on to the problem of determining the gender (DCE or DTE) of a

particular RS-232 device. We can, as a first step, examine the manufacturer's

handbook and see what they believe the gender of their device to be. This is not

always reliable, since some manufacturers do not appear to understand the definitions

of DCE and DTE themselves. There is however, a simple series of tests that can be

used to determine the gender of an RS-232 device. These require the use of any

simple voltmeter.


When an RS-232 device is idle, its "output data" line (pin) will be marking

time (binary 1 or negative voltage between -5v and -15 v). For a DTE, the output

data line is labelled as the TRANSMIT DATA (TXD) line and the input data line is

labelled as RECEIVE DATA (RXD). The labelling convention for data flow is

relative to the DTE device. Therefore the output data line for a DCE is actually RXD

and the input line is TXD.

By testing the voltage of both the Transmit and Receive pins on an RS-232

port, with respect to the signal ground (COM) pin, we can decide which of the two is

marking time. The true "input data" line to the port will be floating. The true output

data line will be marking time with a negative voltage.

It is important however, that before testing or using a connector, one is

relatively certain that it is in fact RS-232. Connectors such as the DB25 and DB9 are

not unique to RS-232 - they are just general purpose connectors. If one mistakenly

assumes that a particular connector is RS-232 and then uses it without further testing,

then a potentially damaging (or even dangerous) situation could arise. The following

test steps can therefore be used to ascertain gender or to help us confirm that a device

is RS-232 compatible:

(a) Check the manufacturer's description of the pin-configuration for the RS-

232 port

(b) Ensure that the serial port is active (open) - some computers leave their

serial ports inactive unless instructed otherwise by an operating system

command

(c) Connect the positive side of a d.c. Voltmeter to what the manufacturer

describes as the Transmit pin and negative side to the Signal Ground pin.

(d) If the voltage is negative (-5v to -15v) then the device is DTE.

(e) If the voltage is not negative then move the positive terminal of the

Voltmeter to the pin described by the manufacturer as the Receive pin. If

this voltage is negative (-5v to -15v) then the device is DCE.

(f) If neither of the voltages are negative then there are a a number of

possibilities (other than the rather obvious one of the port not working):

• the serial port is not active (open)

• the device is a receive only device

• the port is not RS-232 compatible at all

This test procedure is shown schematically in Figure 5.8.


TXD

COM

RXD

0

-

+

d.c.

Step (c) - A negative reading indicates that the device is probably DTE

TXD

COM

RXD

0-

+

d.c.

Connector

ofUnknownGender

ConnectorofUnknownGender

V

V

Step (e) - A negative reading indicates that the device is probably DCE

Figure 5.8 - Testing the Gender of an Unknown RS-232 Port

Once we have ascertained whether a device is DCE or DTE we still have a

number of problems that may need to be resolved. The most common is the problem

of what to do when we want to interconnect two devices that are both the same sex.

In the simplest scenario, where the manufacturers have been wise enough not to use

hardware hand-shaking in the link, it is possible to construct a special 3-wire cable to

form the DCE/DCE or DTE/DTE connection as shown in Figure 5.9. This cable

configuration is referred to as a 3-wire "null-modem" cable, since it makes the RS-

232 system operate as if the modems were transparent.


DTE DTE

TXD > < TXD

RXD < > RXD

COM COM

Figure 5.9 - Simple, 3-wire "Null Modem" Interface for Devices of the Same

Gender DTE to DTE (or DCE to DCE)

The real problems with RS-232 systems arise when hardware hand-shaking is

involved. We could simply try to cross all the hand-shaking lines as we have with

the data lines. The connection is shown in Figure 5.10. This works for some signals,

but fails when we don't have complementary hand-shaking lines. DCE and DTE

devices are clearly not symmetrical. For example, the Carrier Detect and Ring

Indicator lines are both outputs from a DCE and both inputs to a DTE - there is no

purpose in crossing over two pairs of inputs. RTS and CTS are complementary, but

crossing these two lines over does not necessarily achieve a sensible handshaking

scheme.

DTE DTE

TXD > < TXD

RXD < > RXD

COM COM

RTS >

CTS <

< RTS

> CTS

DSR <

DTR >

> DSR

< DTR

CD <

RI < > RI

> CD??

??

??

??

Figure 5.10 - Making a Null Modem with Hand-shaking Lines


The problem illustrated is generic and a similar situation will arise if we try to

interconnect two DCE devices that both expect full hardware hand-shaking. You

should now appreciate why hardware hand-shaking is so undesirable. The same type

of problem also occurs when one device is equipped with hardware hand-shaking

whilst the other is not. Some devices will not function at all until their hardware

hand-shaking lines are enabled. For example, if the CD is not enabled on some DTE

devices they will assume that the transmission link is inactive and therefore will not

transmit. To make matters worse, many devices only input or output some of the 6

standard hand-shaking lines.

We therefore need to be able to trick devices into thinking that hand-shaking

has been fulfilled. For example, with the UARTs of Figure 5.10, the Data Terminal

Ready line on each device will be enabled whenever that device is ready for

transmission. We can short-circuit the DTR line to the CD line, thereby causing each

device to think that a carrier is always present. We can also short-circuit the RTS

and CTS lines on each device so that whenever an RTS is asserted, the CTS is

automatically received. This connection is shown in Figure 5.11.

DTE DTE

TXD > < TXD

RXD < > RXD

COM COM

RTS >

CTS <

< RTS

> CTS

DSR <

DTR >

> DSR

< DTR

CD <

RI < > RI

> CD

Figure 5.11 - Rectifying Hand-shaking Problems on RS-232

A more complex problem that can arise is where one RS-232 device requires a

hand-shaking pin enabled, but there are neither complementary pins on the other

device nor other enabled pins on the local device. In this case, we sometimes have to

borrow a known "enabled" signal from the remote device by using an extra line.


Another common problem with RS-232 hardware hand-shaking occurs when a

remote DCE device is unable to supply a CTS signal to a DTE. In this case we can

short-circuit between the DTR and the CTS pins on the local DTE.

It is also possible, as a last resort, to by-pass the hardware hand-shaking on

both DTE and DCE devices using the connections shown in Figure 5.12.

DTE DCE

TXD > > TXD

RXD < < RXD

COM COM

RTS >

CTS <

> RTS

< CTS

DSR <

DTR >

< DSR

> DTR

CD <

RI < < RI

< CD

Figure 5.12 - By-passing Hardware Hand-shaking

Figure 5.12 would seem to indicate that it is possible to drive an RS-232 link

entirely without hardware hand-shaking. This is only true provided that both the

devices are aware that hardware hand-shaking is inoperative. The connection shown

in Figure 5.12 would fail in an environment where the hardware hand-shaking was

used extensively to co-ordinate the flow of data. For example, in Figure 5.12, as far

as the hardware hand-shaking goes, both devices are free to transmit continuously. If

this situation is acceptable (and in some cases it is) then the connection can be used -

otherwise it can cause other problems.


The other general problem with by-passing the hand-shaking process is that one

needs to understand exactly which signals a device needs enabled before it will allow

transmission to occur. For example, if DTE UART is set to work in a half-duplex

mode and the Carrier Detect (CD) line is enabled, then the device probably won't

transmit because the CD is designed to indicate that a remote device is already

transmitting. If a DTE UART is set to work in a full-duplex mode, then it probably

won't transmit unless the CD is enabled, because in this instance the CD indicates

that the link is active.

The result of all this discussion is that every RS-232 link has to be specially

tailored, bearing in mind the gender and availability of hardware hand-shaking.

There are a few off-the-shelf cable configurations such as the simple 3-wire straight

through TXD, RXD and COM) and corresponding null-modem connection (in Figure

5.9) which do not use hand-shaking. DB25 → DB9, DB9 → DB25 and male to

female converters are also common items. However, for the majority of applications

the link designer must become familiar with the hand-shaking problems and

solutions thus far described in order to establish effective links.


5.5 A Summary of Points Related to RS-232 Links

(i) There are no connectors that are universally adopted for RS-232, although the

DB25 and DB9 are in common usage. DB connectors are general-purpose

electrical connectors and it is very dangerous to assume that a plug is RS-232

compatible just because it uses one of these connectors. Conversely, it is also

possible that a plug, which does not utilise one of the DB connectors is RS-232

compatible.

(ii) The common pin configurations for the DB25 and DB9 connectors are

outlined in Table 5.1, but are not universally adopted. Always compare with

the manufacturer's specification for the connector.

(iii) The male or female gender of a connector is in practice not a reliable means of

assessing whether a device is DCE or DTE.

(iv) If one is sure that a connector is RS-232, then it is possible to short-circuit any

number of pins (on that connector) together without damaging the port. The

RS-232 voltage levels (-5 -> -15v and +5 -> +15v) corresponding to 1 and 0 are

normally adhered to in practice.

(v) Before connecting two devices of unknown genders (DCE/DTE), it is wise to

first ascertain their true genders from electrical testing of transmit and receive

pins - a manufacturer's specification is not necessarily reliable.

(vi) The hardware hand-shaking on RS-232 ports varies dramatically from one

device to another. Some devices have a number of inactive hand-shaking lines

whilst others use the complete set.

(vii) Establishing RS-232 hardware hand-shaking often requires tricking devices

into thinking that signals are present. This is achieved by short-circuiting the

required hand-shaking pins to known "enabled" pins.

(viii) There are no "standard" RS-232 connector cables. Although there are some

which are commonly used, generally, each cable is tailored for a specific

application.

(ix) Hardware hand-shaking is undesirable and software hand-shaking should

always be used wherever feasible. That is, where possible, RS-232 links

should preferably be designed as 3-wire (TXD, RXD and COM) links.


5.6 Devices to Assist in Establishing Serial Links

After reading the previous section, the reader may be left to wonder whether

there are any devices available to make the task of the RS-232 link designer an easier

one. As it turns out, there are many such devices.

One of the biggest practical problems in making test links is that RS-232

connectors and twisted-pair cables are very awkward to handle and difficult solder.

Without some special tools, experimenting with hand-shaking can be very time

consuming and unproductive.

The simplest RS-232 design tool is ribbon cable. A ribbon cable is nothing

more than a number of insulated, parallel conductors joined together to form a flat

ribbon. This is an ideal mechanism for making short test links. A good starting point

for RS-232 testing is to try transmitting via a straight-through connection using

ribbon cable. A 25 conductor ribbon cable and special crimp connectors on DB25

plugs make it possible to form "straight through" test leads very quickly and without

the use of solder. It should be noted however, that the conductors in ribbon cable are

not shielded from electro-magnetic interference and are subject to cross-talk if the

ribbon cable is too long. It is therefore imperative that the ribbon cable is only used

over short distances (several metres maximum) and only in an electro-magnetically

clean environment. Once the pin-connection diagram for the cable has been

determined, the ribbon cable should be replaced with shielded, twisted-pair cable.

Another useful device for deciphering the hardware hand-shaking on RS-232

links is referred to as a "break-out" box. A typical device is shown in Figure 5.13.

The basic purpose of a break-out box is simply to bring the 25 pins from each of two

RS-232 devices (which are ultimately to be linked) to a common central point. One

can then experiment with hand-shaking by making connections at a convenient

location. Most break-out boxes also feature a bank of switches which can connect or

disconnect corresponding pins. Many also feature switches which can cross connect

complementary lines for "null modem" experimentation. Another common feature of

break-out boxes is that they contain light emitting diodes to show which lines are

currently enabled or disabled.

A number of low-cost link design software packages are also available to assist

with hand-shaking. Some systems allow users to manually enter the results of break-

out box testing for computer analysis. Other systems work by connecting an

unfamiliar RS-232 device to the Personal Computer running the analysis software.

The computer then analyses the hand-shaking requirements of the unfamiliar device.

The only problem with such a system is that it relies upon the computer having the

traditional RS-232 port structure in order to operate in the first instance.


12

34

56

789

10

1213

1415

1617

1819

202122

2324

25

11

12

34

56

789

10

1213

1415

1617

1819

202122

2324

25

11

Ribbon Cable

DB25 Connector

Banks of switches to allow

short-circuiting or open-circuiting

of corresponding pins

(Connect to remoteend of link)

DB25 Connector

(Connect to localend of Link)

connector pins

brought out toeasy-accessterminals

DB25 plug

Figure 5.13 - Typical Break-out Box

A far more sophisticated link designer's aid is the "Line-Analyser". Typically

this is a micro-processor based system capable of monitoring all data and hand-

shaking activity on a serial link for the purpose of detecting and correcting any

number of faults and anomalies. This is however an expensive tool which is not

normally available in manufacturing organisations.


5.7 Selecting RS-232 Cables and Line-Drivers

The cables that are used for RS-232 communications are neither unique nor do

they have any outstanding qualities. The physical RS-232 link can be achieved by

any number of general purpose communications cables. For an RS-232 link designer

with an unlimited expense account, it may seem that selecting an appropriate cable is

as easy as looking up an equipment catalogue and choosing the most expensive

variety. To some extent this is true, but it is most important to appreciate the

different varieties of cable available and their performance and limitations before

making a selection.

General purpose communications cables are composed of a cluster of insulated,

twisted-pairs of conductors enclosed in some form of plastic sheath. In twisted-pair

systems it is possible to buy cables with differing numbers of internal conductors - 4,

7, 12, 16 and 25 conductor cables are common. The cost per metre of a 25 conductor

cable is typically triple that of the equivalent 4 conductor cable. Consequently one

only buys a cable with the minimum number of conductors required to achieve an

operable link. Therefore, the first step in the cable selection process is always to

determine the type of hand-shaking involved in the RS-232 link and the actual

number of conductors required to maintain a reliable transfer of data. We can then

begin to look at a range of cables that will supply at least this number of conductors.

General purpose communications cables are marketed in a range of different

quality levels. The quality of the cable depends upon the way in which the various

cable parameters have been optimised. Shunt capacitance, series resistance and

susceptibility to electro-magnetic fields are the three parameters that define the

quality of a general-purpose, twisted-pair cable. The lower the series resistance and

shunt capacitance (per metre) of the cable, the less the data signals will be distorted

and attenuated and therefore the higher the possible transmission distance. The better

the cables are shielded from electro-magnetic interference the less likely it is for data

to be corrupted. Shielding from electro-magnetic interference is achieved by

surrounding the data conductors with conducting materials. Some low-cost, twisted-

pair cables have no shielding, whilst others use an aluminium/mylar foil or braided

copper cage. High quality cables use both the aluminium foil and braided copper for

shielding. A range of twisted-pair cable grades are illustrated in Figure 5.14 to

highlight the differences in cable composition.


PVC Jacket

Mylar Tape Wrap

PVC Insulated

Stranded Wire Pairs

(a) Typical "Standard" Grade Twisted-Pair Cable

PVC Jacket

Aluminium Polyester Sleeve

(Aluminium Foil is the outside layer)

Stranded WireTwisted Pairs Insulated

with Polyethylene Coating

(b) Typical "Medium" Grade Twisted-Pair Cable Arrangement

PVC JacketStranded WireTwisted Pairs Insulated

with Polyethylene Coating

(c) Typical "High" Grade Twisted-Pair Cable Arrangement

Aluminium / Mylar Foil

Copper Braided Shield

Figure 5.14 - Compositions of Commercially Produced Twisted-Pair Cables


In addition to the composition of the cable, the quality of the conductors must

obviously affect the total performance of the cable. Higher grade cables use better

conductors than are normally used in standard grade cable (Typically 24-AWG in

high grade cables and 22-AWG in standard grade). A standard grade cable, such as

that shown in Figure 5.14 (a) would typically be rated with a maximum transmission

distance of 15 metres using RS-232 signals. The higher grades of cables, shown in

Figure 5.14 (b) and (c) would typically be rated at 150 metres - a factor of 10

difference.

Other criteria that must be considered when selecting cables for

communication, within the industrial environment, are their resistance to industrial

gases and liquids and more importantly their resistance to fire. Cables in which

insulation failures arise from normal (industrial) use can be the source of data

corruption and considerable expense in terms of fault-finding. In situations where

data links are of vital importance, the cost of fire resistant cable may be well

justified. Teflon or Halon insulated cables are fire resistant cables that can be used in

instances where, say, emergency shut-down signals need to be sent to production

machines after the eruption of a factory fire.

Shielding can isolate data conductors from electro-magnetic interference whilst

they are in the cable, but what about the connectors and terminators? Connectors are

often overlooked, but in an industrial environment an inappropriate connector can

allow electro-magnetic interference to corrupt data signals just as they would be

corrupted in unshielded cable. Metallic (conducting) casings provide the same type

of shielding for conductors inside connectors as do copper braiding and foil on

cables. From a safety point of view it is also preferable that such conducting casings

are insulated in an non-conducting sleeve.

We have already noted that improving the quality of a cable (optimising its

parameters) increases the distance over which we can transmit using RS-232.

However, no matter how high the cable quality there are always distance limits to

transmission. These can be increased through the use of line-drivers (boosters) and

modems. Line boosters are powered amplifiers that are placed at strategic lengths

along a transmission line and act as relay stations. They are transparent to the

operation of the data link itself. Similarly, modems and other signal drivers can be

used to transmit signals over long distances through varying media.

Figure 5.15 (a) shows two computers (A and B) linked by a short RS-232 link

that contains hardware hand-shaking tailored for the specific application. If we wish

to separate computers A and B by a long distance, then we can use line-drivers at

each end of the long distance line. This is shown in Figure 5.15 (b). However, in

doing so we now find that we have to satisfy the hand-shaking between each device

and its local line-driver rather than that of the distant computer. It is yet another

reason why hardware hand-shaking is so undesirable.


Computer ComputerRS-232 Link

with Hand Shaking

(a) Short Distance RS-232 Connections

Computer ComputerRS-232

Link

RS-232

Link

Line-Driver

Line-DriverLong-Distance

Medium

(b) Long-Distance RS-232 Based Connections

BA

A B

Figure 5.15 - Extending the Range of the RS-232 System

The long-distance transmission medium shown in Figure 5.15 can be one of a

number of different forms. It can be twisted-pair, co-axial or optic fibre cable or for

that matter just plain air, with data transmission occurring through electro-magnetic

propagation at radio frequencies.

Optic fibre cables convey digital signals by transmission of light pulses in a

glass-cored cable and are therefore impervious to electro-magnetic interference.

They are therefore ideal for the industrial environment. Optic fibre links are

commonplace in industry, particularly in point to point links where connectors and

interfacing circuits (which convert from RS-232 to light pulses and vice-versa) are

readily available at reasonable cost.


The transmission of data through air at high frequencies also has its advantages

because equipment can be moved around without having to reorganise cables.

However in order to minimise the effects of electro-magnetic interference from

industrial equipment, it is often necessary to transmit at very high frequencies. This

is referred to as "millimetre wave" transmission. The problem with millimetre wave

transmission is that the transmitter and receiver need to be on a direct line of sight in

order for correct data transmission to occur. In other words, physical obstructions

between devices can cause problems.

Overall, extending the range of RS-232 communications to long distances,

which are in the order of kilometres, is not a difficult proposition, provided that the

two remote devices are not relying upon one another for hardware hand-shaking.

There are many commercially available devices that will convert and/or modulate

RS-232 signals into a form suitable for transmission over such extended distances.

For all the short-comings of RS-232 it is fortuitous that widespread use of the

system has led to the proliferation of an enormous range of accessories, interfaces

and line-drivers. These accessories are not only widely available but also of a

relatively low cost per link.


5.8 Configuring UART Parameters

Once a "point to point" asynchronous (RS-232) serial link has been physically

realised, by constructing a cable to interface the devices at either end, there is still

some hardware configuration to be performed before any sensible data transfer can

occur.

The UART on each device is driven by a clock signal, whose frequency can be

varied to alter the number of bits per second at which data is fed from the output

register to the transmit line. The clock signal also determines the rate at which

incoming data is fed from the "receive" line to the input register. It is therefore

essential that the devices on either end of an RS-232 link have UARTs set with the

same clock speed so that data will be correctly interpreted.

The UART control circuits on two communicating devices must also agree on

the number of bits used to represent data. Since both 7 and 8 bit data formats are

common on RS-232 links it is also important that devices are both set to use the same

convention. The number of stop bits on RS-232 links also varies with differing

applications. Both 1 and 2 stop bit formats are common and again it is important that

both devices are set to the same format in order for data to be framed correctly. The

same applies to parity checking bits. As long as both devices agree on one of odd,

even, mark, space or no parity, data can be correctly framed and interpreted by the

UARTs on each device.

A complete RS-232 frame is shown in Figure 5.16, incorporating a start bit, 8

data bits, a parity check bit and 2 stop bits.

In any user-programmable system, UART parameters are configured or altered

through the CPU (microprocessor), which can load binary strings into UART control

registers, via the data bus. The UART control registers can be addressed by the CPU

in the same way as other memory locations in the system. In order for this transfer of

data to occur, a simple piece of code has to execute on the CPU. In some computer

systems, the Operating System has built-in commands that allow a user to configure a

serial port through its UART command registers. Software developers however,

often need to write their own sub-programs to set up the UART parameters before

feeding information into or out of a serial port.


Time

Start

Bit Character Data Bits StopBits

Start

Bit

Transmission Line Voltage Transition Point

NextCharacter

0

1 1

0

Figure 5.16 - RS-232 Signal Transmission (Framing)

In less intelligent devices (such as serial printers) UARTs have preset

parameters that cannot be changed by user software programming. However, some

of these devices allow the user to "hardware program" the UART parameters through

the use of hardware switches that physically set bits in UART control registers to

appropriate states. In the unlikely situation where neither of two devices can be

programmed to achieve "matched" UART parameters, then clearly no sensible RS-

232 communication can take place.

In situations where both devices can be programmed, the following priorities

should be assigned:

• Maximum bit rate (ultimately governed by the quality of the

communications cable, but typically up to 19200 bps)

• 1 stop bit (2 stop bits increase overheads)

• No parity check bit (if software hand-shaking is used)

Note that unless the software, running on the linked devices, is capable of flagging

parity errors or taking corrective measures, then there is no value in using parity. It

only increases overheads.


The minimum number of bits that must be transmitted for every single

transmitted character: is

1 start bit 7 data bits ⇒ 22% overhead

1 stop bit

The maximum number is:

1 start bit 8 data bits ⇒ 33% overhead

1 parity bit 2 stop bits

In as much as the maximum bit rate of the link is sometimes outside the control of

the end user, it is therefore wise to minimise the unnecessary bit overheads in the

system in order to increase performance.


5.9 Bit Rates and Baud Rates

At this point it is appropriate to introduce a term used in conjunction with the

speed of communications links - that is, the "Baud Rate". Up until now, its use has

been avoided and link speeds have been specified in "bits per second" (bps) because

this is a precisely understood quantity.

The term Baud rate is derived from the French communications pioneer

"Baudot" and is a quantity describing the "signalling" rate. The signalling rate

defines the length of the shortest signal divided into one second. In simple systems,

such as straight RS-232, where no modulation is used, the shortest signal is the bit

and therefore in this situation the Baud rate equals the number of bits per second.

However, when modulation is used the signal on the transmission line, at any

instant in time, can contain 2 or more bits of information (multiple channels). In this

case the bit rate and the Baud rate are not the same and clearly the Baud rate is only a

fraction of the bit rate.

We therefore note that the "Baud rate" is (in general) not the number of bits per

second at which data is transmitted. It is the number of signal units per second on the

transmission line. Each signal unit may contain multiple bits of data.


5.10 RS-422 and RS-449 Hardware Links

You should now be aware that in the RS-232 system, any spurious voltage that

is induced on the transmit or receive lines is liable to corrupt the interpretation of

data. This is because the receiving device at each end of the link decodes the binary

value of a signal based upon its voltage with respect to the signal ground line. The

RS-422 signalling standard, which is also referred to by the CCITT specification

V.11, attempts to address this problem of noise induction along a transmission line.

In the RS-422 system, the transmit and receive lines are paired "differential"

circuits. This is shown schematically in Figure 5.17, where two transmission lines

are used for each signal. This means that a minimum of 5 conductors are required for

a full-duplex link.

Computer-Based

Device AComputer-Based

Device B

Transmit Wire 1

Transmit Wire 2

Signal Ground

Receive Wire 1

Receive Wire 2

Vr1

Vt1 Vr2

Vt2

Figure 5.17 - Transmission Using Paired Differential Circuits

In differential-voltage communications systems, each transmitter produces two

voltage signals of equal and opposite polarity to represent every binary digit. The

receiver in such a system looks only at the difference between the two voltages in the

pair of lines to determine whether the signal represents binary 1 or 0. Any noise that

is induced on the link will be induced equally on the pair of transmit conductors.

However since the receiver only looks at the difference between the two, the noise

component is ignored because it is the common component. This is referred to as

common mode rejection. Typical differential signal voltage waveforms for the

transmit wire pairs are shown in Figure 5.18.


Voltage Vt1

Time

Voltage Vt2

Time

Voltage Vt1

Time

Voltage Vr1

Time

Voltage Vr2

Time

- Vt2

Induced Voltage

Voltage Vr1

Time

- Vr2

Induced Voltage

Figure 5.18 - Differential Signal Properties


A modified version of RS-422 has also been defined and is referred to as RS-

423. RS-423 circuits allow RS-232 outputs (which are single-ended) to be input to a

differential receiver.

The RS-449 system is the communication standard that uses RS-422 signalling

techniques. It is also referred to, using CCITT terminology, as the V.35 standard.

RS-449 is analogous to the RS-232 system in that it has similar hand-shaking lines

and a receive and transmit circuit. The major difference is that all signals are

differential and not single ended. RS-449 connectors generally come in the form of a

37 pin "D" shaped plug. This is shown in Figure 5.19.

1 Shield

2 Signalling Rate Detector

3 Unused

4 Send Data

5 Send Timing

6 Receive Data

7 Request to Send

8 Receive Timing

9 Clear to Send10 Local Loopback

11 Data Mode

12 Terminal Ready

13 Receiver Ready

14 Remote Loopback

15 Incoming Call

16 Select Frequency

17 Terminal Timing

18 Test Mode

19 Signal Ground

Receive Common 20

Unused 21

Send Data 22

Send Timing 23

Receive Data 24

Request to Send 25

Receive Timing 26

Clear to Send 27

Terminal in Service 28

Data Mode 29

Terminal Ready 30

Receiver Ready 31

Select Standby 32

Signal Quality 33

New Signal 34

Terminal Timing 35

Standby Indicator 36

Send Common 37

Figure 5.19 - RS-449 Connector Plug

Figure 5.19 shows some hand-shaking lines that clearly have similar functions

to those in RS-232. For example, in RS-449 terminology, the Data Mode and

Receiver Ready lines correspond to the Data Set Ready and Data Terminal Ready

lines of the RS-232 system. A feature of the RS-449 system that is not found in RS-

232 is the Test Mode line. When a DTE enables this line, the DCE automatically

loops back (echoes) its incoming signal back through to the Receive lines of the

DTE. This allows a DTE device to test for faults in the DCE.


The balanced circuits of RS-449 allow it to operate at much higher bit rates and

over longer distances than RS-232. Typically it is possible to transmit at a rate of

one megabit per second over twisted-pair links of 100 metres. The separation can be

even greater at lower bit rates.

Although RS-449 is inherently a better system for data transfer than RS-232 it

is not widely used in point to point links within the manufacturing environment. Few

industrial equipment manufacturers provide an RS-449 port as standard equipment.

This is another example of how volume generally dictates technology in computing

and data communication environments. Many original equipment manufacturers

design their systems with the most prolific communications interfaces and not

necessarily those that are the best suited for the task. Since personal computers and

workstations are the most prolific "computing" devices, one can often gauge trends

for industrial computer controllers from the events that take place in the office

environment - whether these are directly relevant technologies or not. In this

instance we find that RS-232 interfaces are provided on computer controlled

machines because the specification is very common on personal computers.

A number of data communications equipment suppliers provide low cost

interfaces and line-drivers which facilitate conversion between RS-232 and RS-449

signalling. This provides another technique for extending the range of

communications on RS-232 devices. However, the usefulness of RS-232 to RS-449

converters has been diminished since the introduction of RS-232 to optic fibre

converters, which provide far greater noise immunity.


5.11 The 20mA Current Loop

Another alternative to the RS-232 specification for serial data communication

is the 20mA current loop. This system allows for longer transmission distances than

RS-232 but at similar bit rates. Transmission lines of a kilometre in length are

feasible with the 20mA loop system.

As its name implies, binary information is represented by the current flowing

from the transmitter to the receiver (and back again). A current of 20mA signifies a

binary 1 and an open circuit (zero current) signifies a binary 0. The 20mA loop

system is shown schematically in Figure 5.20.

20mA CurrentMonitor

20mACurrentMonitor

Computer BComputer A

Transmit Circuit

Receive Circuit

Figure 5.20 - Schematic of 20mA Current Loop System

As with the RS-449 system, a pair of wires is used for data transmission and

hence the Common Mode Rejection properties of the 20mA loop system are good.

However, as with the RS-449 system, use of the 20mA loop system within

manufacturing is very limited.


5.12 Summary of Key Factors in Point to Point Serial Links

The following points summarise the discussions contained with this chapter in

terms of establishing a serial point to point link between two devices. They are

schematically shown in Figure 5.21.

(i) Determine the standard to be used for communications between devices

(ie: RS-232, RS-449, etc.)

(ii) Determine the gender of devices (DCE/DTE)

(iii) Satisfy the hardware hand-shaking requirements of devices, remembering

to avoid hardware hand-shaking if at all possible

(iv) Try to achieve an operational link over a short distance, using ribbon

cables and break-out boxes

(v) Determine the actual required separation of the devices

(vi) Select an appropriate transmission medium - (ie: cable and line-drivers or

modems) with due regard to electro-magnetic interference and

susceptibility to chemical and fire exposure.

(vii) Set the serial transmission parameters - (ie: baud rate, parity, stop bits,

etc.)

All the above points are only the basic hardware considerations - or more aptly

descriptions of "physical" requirements. We have not yet considered the software

requirements that need to be fulfilled in order to transfer data between two devices

once the physical link is functional. This will be covered in subsequent chapters.


Device A Device B

DCE or DTE ?

Bit Rate ?Parity ?

Stop Bits ?

DCE or DTE ?

Bit Rate ?Parity ?

Stop Bits ?

Separation ?

Signalling Technique ?

Connectors ?Transmission Medium ?

Hand Shaking ?

Conductors ?

Line-drivers ?Modems ?

Figure 5.21 - Hardware Considerations in Serial Links

181

Chapter 6

Serial Data Communications

- Software Application

A Summary... Development of software for serial communications. The XON/XOFF protocol. Implementation of simple ACK/NAK protocols. Terminal Emulation and the Kermit protocol.


♦ You want to learn how to program two devices to communicate with one another

♦ You want to develop communications protocols for linking devices

♦ You would like to learn about commonly used terminal emulation packages.


6.1 Developing Software for Serial Communications The construction of a physical link between two devices is only one part of the data communications process. In relative terms, the physical hardware link is normally easier to implement than the software that is needed for reliable communications. When selecting the physical hardware, we choose media and interfacing circuits such that the number of errors on the line is reduced to an absolute minimum. We never assume that a communication link is 100% error free. We do however need to perform a qualitative analysis of the consequences of a data error occurring. If these consequences are minimal (such as in a link between a Personal Computer and printer) then we consciously choose to accept a link that cannot be guaranteed as error-free. In some situations, we have no choice but to accept an unreliable data link and we then need to revert to manual error detection and correction techniques. Figure 6.1 schematically shows two computers that have been physically connected to one another through a serial communication link. Regardless of which standard we use for the link (RS-232, RS-449, etc.), data will not flow on the link until one (or both) of the devices transfers information from its CPU (or memory) to its UART. In addition, the receiving device requires a program that will read incoming data from its UART in order for the data transfer to have any real significance. Software therefore needs to be developed for each of the devices.

UART

Software

CPU

UART

Software

CPU

Device A Device B

Physical Link

Figure 6.1 - Linking Devices by Hardware and Software

Serial Data Communications - Software Application 183

The software required to perform these functions can be as simple or as complex as a system designer makes it. At the lowest level, device A can simply feed out a stream of data and device B can simply read it in and display it. At a more sophisticated level, the transmitting device sends data in packets (or blocks), with error checking performed by the receiver. If we needed a more sophisticated link, then the transmitting device could also send the receiver information (commands) describing how incoming data should be processed once it is received (eg: stored on disk, displayed on screen, etc.). All these functions are performed by software protocols. There are some commonly used protocols but (as we have come to expect) there are no universal standards. Some of the issues that are addressed by software protocols include:

(i) The representation of data in character oriented protocols (ie: ASCII, EBCDIC)

(ii) Establishing the presence and status of a remote device (iii) Controlling the flow of information so that the receiving device has time

to process the information (iv) Error checking and correction techniques (v) Recovery from failure of the transmitting or receiving device (vi) Resolution of conflict situations where two devices both wish to

communicate on the same transmission medium at the same time. Many of these features add overheads to the transmission of data and subsequently slow down the speed of data transmission. In the final analysis however, the performance of a protocol can be judged by:

• its ability to minimise transmission errors

• the average data transmission rate which can be achieved

• the ability of the software to recover from communications system error conditions.

In subsequent sections we shall look at a number of different protocols, how they can be programmed and used and how they perform.


6.2 The XON/XOFF Protocol The XON/XOFF protocol is perhaps the simplest of all communications protocols. Its only objective is to prevent a transmitter from sending information to a receiver whilst the receiver is unable to handle that information. The simplest example is an RS-232 serial link between a computer and a printer. Let us assume that the printer can print at a rate of say 100 characters per second. If we transmit characters to that printer (from a computer) at say 9600 bits per second, then that translates to approximately 960 characters per second (assuming 1 start bit, 1 stop bit, 8 data bits and no parity bits). It should be obvious that we will "overrun" the printer with information in a very short time, since it can only dispose of (print) one character in the time taken for an average of 9.6 characters to arrive. In other words, it is possible that data will be lost. We could try to resolve this problem by having a memory buffer on the printer. However, no matter how large the memory buffer, if the stream of input data is long enough we will eventually "overrun" the printer. The solution that is commonly employed is simple. When the printer's memory buffer reaches a certain level (upper threshold), it sends the computer the special ASCII character, whose value is decimal 19. This character has the acronym XOFF. When the computer detects the XOFF character, it stops transmitting. Once the level of the printer's memory buffer has reached a lower threshold, it sends the computer the special ASCII character whose value is decimal 17. This character has the acronym XON. When the computer receives an XON it resumes transmission from its previous cut-off point. This simple protocol is shown schematically in Figure 6.2. Note that with the XON/XOFF scheme, the receiving device must have enough room in its memory buffer to account for the characters coming in whilst it is sending an XOFF to the transmitter. Conversely, to avoid having a receiver idle whilst it waits for the transmitter to resume, the receiver must transmit an XON, at a point that will leave enough characters in the memory buffer to account for the time delay. In other words XOFF and XON are always sent before the printer is 100% full or 100% empty respectively.


UART

Software

CPU

Send XON

Send XOFF

Lower Threshold

Upper Threshold

MemoryBuffer

Physical Link

Device A Device B

Figure 6.2 - The XON/XOFF Protocol

Another concept that arises in discussing XON/XOFF protocols is the

"circular buffer". A circular buffer is created in software and is simply a First-In, First-Out (FIFO) memory area that is indexed as each item is removed. This is shown in Figure 6.3. Normally, circular buffers are programmed so that reading is a destructive operation. That is, once a "read" has taken place, the buffer is indexed and the contents of the read location are replaced with new information. Circular buffers are commonly used at receiver inputs so that information is not lost due to the time constraints of the receiver. Typically, in serial communication, end-users write "Interrupt-Service-Routines" (ISRs) which are automatically activated each time new data enters a UART register. The role of the ISR is to remove incoming data from the UART registers (which are volatile and overwritten each time data enters the UART) and place it into conventional memory. The conventional memory is structured as a circular buffer and normal end-user programs read the data from the buffer. The buffer is indexed each time the user reads from it. Circular buffers can also be used at transmitter outputs (as output buffers), so that the transmitter does not need to wait until each character is output before sending the next. It is the level of the circular input buffer that is generally responsible for triggering XOFF/XON transmission by a receiver.


Reading Point

Characters

Indexing Buffer

Figure 6.3 - The Circular Buffer Concept

An important point to note about the XON/XOFF protocol is that if it is efficiently implemented, then XON and XOFF should not appear as characters in a circular buffer. Programmers can usually enable or disable the XON/XOFF facility on the UART of each device. When XON/XOFF is enabled, the UARTs respond to these special ASCII bit patterns by switching on or off transmission and the characters are always treated as special control characters - not as data. The protocol is then transparent to user programs. However, when the XON/XOFF facility is disabled, the characters are treated in exactly the same way as normal data and have no effect on flow control. If XON and XOFF are treated as normal data, then it is clearly the programmer's task to generate software which will:

• read the characters

• isolate them from normal data

• carry out the flow control task. The XON/XOFF protocol and the circular buffer are an effective way of governing data flow in simple links. However, they do not address any of the more complex communications issues related to error detection and correction. The main role of XON/XOFF therefore remains with computer to printer links.


6.3 ACK/NAK Protocols Once we leave behind relatively simple protocols such as XON/XOFF, we also leave behind the concept of standardisation. There are no complex, point to point serial communications protocols which have been universally adopted in industry, although there are a few which are in common usage. From this point onwards we will therefore try to examine, in broad terms, the sort of protocols that are in use. They will all be classified as ACK/NAK protocols, for reasons that we shall discover later. There are countless variations on a central theme, so our main objective here is to "define" our own generic protocol and see how this is implemented through software programming. Once you have seen how this hypothetical ACK/NAK protocol is implemented then you should be able to translate the results to other situations. Most modern, computer-controlled industrial equipment is fitted with at least one RS-232 port. On many devices, this serial port does nothing more than allow a complete program or data file to be transferred into or out of that device. This is sometimes referred to as a "file-dump" facility (rather than a protocol). When a dumped file arrives at its destination, the receiving device has no way of knowing whether the information contained in that file has been corrupted along the communications link. We will look at file-dumping and its consequences a little later. However, we will firstly examine the implementation of ACK/NAK protocols that do perform error checking and correction. One may well ask why we would ever need to develop a piece of software to implement a communications protocol. The answer to this question is simple. Many computer based devices are designed to communicate through a software protocol. The protocol software on some devices is installed by the device manufacturer and cannot be changed by the user. Therefore if one wishes to transfer a file from a computer to such a device, then that computer must be programmed to conform to the other device's protocol. Sometimes such software is already provided by the device manufacturer. For example, a CNC manufacturer may supply the PC software required for the PC to communicate using the CNC's protocol. As often as not, this software is not readily available and some in-house development must be performed.


As we shall see, the successful development of protocol software requires a sound knowledge of programming concepts. It also requires a considerable amount of time and therefore expense. A lack of standardisation in point to point protocols (particularly those implemented on RS-232 links in manufacturing devices) means that it is often necessary to develop the complementary, computer (host) side software in order for communication to occur. One can then understand why "integration" in manufacturing can become so costly. In subsequent chapters we shall see how attempts have been made to standardise communications protocols in manufacturing and why standardisation is so difficult. Before proceeding further with software protocol development, we need to re-examine the first 32 characters of the ASCII character set (see Table 1.3). We shall be making use of some of these characters as we progress because most of them are intended for communications purposes. The bit patterns for the first 32 ASCII characters do not generally appear amidst normal text (data) in user files, except where they are used as delimiters (eg: carriage return). There is therefore nothing remarkable about these characters, other than the fact that they are normally reserved for special purposes. It is also important to note that although each of these characters may have had some specific task when originally defined, their application often varies considerably, depending upon the protocol in use. The ones that we shall be using in our hypothetical protocol are:

ASCII

Hex Value Decimal Value

STX (Start of TeXt) 02 02

ETX (End of TeXt) 03 03

EOT (End of Transmission) 04 04

ENQ (ENQuiry) 05 05

ACK (ACKnowledge) 06 06

DLE (Data Link Escape) 10 16

NAK (Negative AcKnowledge) 15 21 Most of the acronyms given to the characters are self-explanatory, but the role of the DLE character is not quite clear. The basic objective of the Data Link Escape character is to separate normal data from communication link control functions. In other words, when a receiver reads in strings of characters, the DLE becomes a delimiter by which it can determine that either the data has ended or the link control has ended. The actual use for the DLE seems to vary significantly from one protocol to another and so it is best viewed as nothing more than a delimiter. As we go through the development of our protocol you can see one particular application for the character.


Our hypothetical protocol (which we shall name HYPOLINK) will be developed in such a way that two devices (computers) are able to transfer data files to one another as shown in Figure 6.4. The originator of the file will be able to tell the recipient whether to display the file on screen or store it on disk under a particular file name. The protocol will include some error detection and correction facilities through a Block Check Sum (BCS) calculation.

Disk

Screen

Disk

Screen

Device A Device B

Physical Link

Two-way

File Transfer

Figure 6.4 - Basic Model for Point to Point Serial Protocol 'HYPOLINK'

The rules of the HYPOLINK protocol are defined with respect to the diagram shown in Figure 6.4 as follows: (i) Communication between devices is based upon RS-232 signalling with no

hardware hand-shaking. (ii) The following transmission parameters are used:

• 9600 bits per second

• 1 start bit

• 8 data bits

• 1 stop bit

• Odd parity

• Half-duplex transmission

• XON/XOFF protocol disabled


(iii) Only ASCII characters can be transmitted as information on the link. With the exception of the control characters ENQ, ACK, NAK, and EOT all information on the link must be transmitted in either command, data or message packets of the form shown in Figure 6.5. For the purposes of this protocol, a packet is defined to be composed of an information field, encapsulated between delimiters. The DLE character is used to signify to the recipient that the next character is a communication control character (STX or ETX) and not data. If a DLE character should coincidentally appear within a transmitted data file, then the DLE must be repeated to avoid ambiguity.

DLE

STX

Information Field

DLE

ETX

(1 Byte)

(1 Byte)

(1 Byte)

(1 Byte)

(1..250 Bytes)

Total packet

includingDelimiters

Figure 6.5 - Structure of Command, Data and Message Packets

(iv) The information field of a command packet has the structure shown in Figure

6.6. The first byte in the information field is the ASCII character 'C', which signifies a command packet. The second byte is either an 'S' or 'D' and is used to instruct the recipient to show the file on Screen or write it to Disk respectively. The Source File Name is the name of the transmitted file as it appears on the originator. The Target File Name is the disk file name under which the recipient is to store the received file. If the recipient only shows the file on screen then it ignores the Target File Name.

C

S/D

Source File Name

Target File Name

File Size in Bytes

(1 Byte)

(1 Byte)

(8 Bytes)

(8 Bytes)

(8 Bytes)

Packet ID

Command Field

Command

Qualifiers

Figure 6.6 - Structure of Information Field for Command Packet


(v) The information field of a data packet has the structure shown in Figure 6.7. The first byte in the field is the ASCII character 'D' to signify a data packet. The ASCII data section contains a block of the file being transmitted.

D

Target File Name

(1 Byte)

(8 Bytes)

ASCII Data (1..241 Bytes)

Figure 6.7 - Structure of Information Field for Data Packet

(vi) The information field of a message packet has the structure shown in Figure

6.8. The first ASCII character in the field, 'M', signifies a message packet. The Message Code is a single ASCII character that tells the originator of a command packet whether or not the recipient is able to carry out a command after that command has been correctly received.

M (1 Byte)

Message Code (1 Byte)

Message Code:

'F' = Disk Full Error

'S' = Screen Error

'A' = Command Accepted (OK)

Figure 6.8 - Structure of Information Field for Message Packet

(vii) After each command or data packet is transmitted on the link, the originator

will transmit a Block Check Sum (BCS), which is the exclusive or (xor) of the bit pattern of every transmitted character in the information field of a packet.

(viii) A receiving device will carry out the same BCS calculation as the transmitter,

on each incoming packet. The receiver will then compare the incoming BCS with its own local value. If they are the same then the receiver will send an ACK to the transmitter, otherwise it will send a NAK.


(ix) If a transmitting device receives a NAK (negative acknowledgment) from the recipient, then it must re-transmit the last data packet. If a transmitter does not receive an ACK (positive acknowledgment) after 3 attempts at transmission then it must assume link failure and cease communication.

(x) Communication between two devices consists of six phases:

• Establishment of Link

• Issue of a Command Packet

• Acknowledgment of a Command Packet

• Dissection and Transmission of Packetised Data

• Error Detection and Correction

• Termination of Transmission (xi) Any remote device that does not respond to an ENQ, command or information

packet within 4 seconds, with either an ACK or a NAK, will be assumed to be off-line and therefore the originator of a communications sequence will desist from further communications activity.

(xii) After the final packet in a communications sequence is transmitted by the

originator, it must terminate transmission by sending an EOT character that must be acknowledged by the recipient.

A typical communications sequence for the Hypolink protocol is shown in Figure 6.9. In order to implement such a protocol in software, we need to have a number of sub-programs (procedures) which will:

• set the serial port (UART) to the appropriate bit rate, parity system, etc.

• write a character to the serial port and report errors

• read a character from the serial port and report errors. The software for reading a character from the serial port needs to be intelligent and "interrupt-driven". That is, each time a character arrives into the UART, a system interrupt (and Interrupt Service Routine) should cause the character to be automatically removed from the UART's register and placed into a circular memory buffer. The program that uses the "serial port read" procedure is then actually reading from memory and not the UART itself. The reason for this is straightforward. If several characters arrive into the UART's input register before the program has "read" and acted upon the previous character, then data will be lost. It is therefore necessary to set up a memory buffer, whose length will accommodate the time delay between the "serial port read" statements in the executing program.


ENQ

ACK

Command Packet

ACK

Message Packet

ACK

Data Packet 1

ACK

ACK

EOT

ACK

Device A Device B

& BCS

& BCS

& BCS

Data Packet N

& BCS

Figure 6.9 - Typical 'HYPOLINK' Communications Sequence

(Assuming No Transmission Errors)

The development of software to execute the functions noted above is generally carried out in assembly language and is totally dependent upon the computer hardware in use. For many programming languages (compilers) available on PCs, the appropriate procedures (sub-programs) have already been developed and are either included as part of the package, or can be purchased as optional "tool-boxes". The form of these procedures is usually such that a "parameter list" is used to pass information to the serial ports and return error codes (parity, overrun, etc.) generated on the serial port/s. Let us assume that the three procedures are:

• Set_Serial_Port_Parameters (Port, Baud, Parity, Stop_bits)

• Write_Character_to_Port (Port, Output_Character, Error_code)

• Read_Character_from_Port (Port, Input_Character, Error_code)


where:

• Port is the number of the serial port (*)

• Baud is the Baud rate (*)

• Parity is 0 for Even and 1 for Odd (*)

• Stop_bits is either 1 or 2 (*)

• Input_Character is the ASCII character read from the port (#)

• Output_Character is the ASCII character written to the port (*)

• Error_Code is the returned status of the serial port (#) and:

* indicates that the parameter is passed to the procedure # indicates that the parameter is returned from the procedure.

We shall use these procedures to create a PASCAL program that implements the above protocol. The purpose of this exercise is to illustrate how high level language structures can be used to develop protocols, and not to highlight any language-specific constructs. For this reason, we will use only the simplest (generic) programming structures. The only salient points you need to note about the PASCAL syntax are that:

• Individual statements are always separated by a semi-colon (;)

• The symbol ":=" is read as "becomes equal to"

• A group of program statements is lumped together into a block through the use of the key words called "Begin" and "End"

• Program comments are contained between braces

• The "$" symbol is used to indicate a hexadecimal value

• Sub-programs are referred to as "Procedures"

• Procedures are called up from a main program or another procedure simply by issuing the name of the procedure, together with a list of parameters that are passed to and from that procedure. Parameters are enclosed in brackets ().

Most of the program loops and structures you will find in the code are common to all modern, structured programming languages. You should also note that in the included program examples, global variables are used in place of local variables in order to make the programs easier to read for those not familiar with PASCAL syntax. In the program listings provided below, all PASCAL "reserved words" are highlighted in bold text


In order to make the HYPOLINK protocol function sensibly, each of the devices on the link needs a simple user interface, where either the transmit or receive modes can be selected. This is shown in Figure 6.10.

Communications Menu

Options:

1: Exit Program2: Set Serial Port Parameters3: Transmit a file4: Receive a file

Enter Required Option Number: __

Figure 6.10 - User Screen Interface on Communicating Devices

The main program executing on each device is called the "Applications Program" and is given the name "Serial_Communications". It is little more than a menu generation program which calls a number of high-level procedures that actually carry out the communications tasks. The structure of the main program is as follows:


Program Serial_Communications;

Const

Define All Communications Constants STX = Chr ($02); ETX = Chr ($03); EOT = Chr ($04); ENQ = Chr ($05); ACK = Chr ($06); DLE = Chr ($10); NAK = Chr ($15);

Var

Define All Communications Variables

Menu_Number : Integer; Main Menu Selection

Error_Code : Integer; Serial Port Error

Information_Field : String [250]; Data Packet Contents

Remote_BCS : Char; Block Check Sum

Local_BCS : Char; Block Check Sum

Character : Char;

EOT_Received : Boolean; Last Packet Flag

Begin Main Program Clear_Display_Screen;

Repeat Write_Main_Menu; Select_User_Option (Menu_Number);

Case Menu_Number of 1: Clear_Display_Screen; 2: Serial_Port_Set_Up; 3: File_Transmission_Mode; 4: File_Receive_Mode;

End Case;

Until Menu_Number = 1;

End Main Program. The main program looks straightforward, but what do high-level procedures such as "File_Transmission_Mode" and "File_Receive_Mode" actually look like? Clearly, such a program cannot execute until these procedures are defined.


Before we develop the high-level procedures used by the applications program, it is necessary to see how some of the lower level procedures are constructed. These procedures will firstly read in the information field of a single data packet (from the serial port) and secondly, execute the software hand-shaking and error checking sequence demanded by our protocol. The first of these procedures, which will take an incoming data packet, shed the link control characters (DLE, STX, ETX) and store the information field into the variable "Information_field" is as follows:

Procedure Read_Data_Packet;

Var Local Indexing And Character Storage Variables

String_index : Integer;

Character : Char; Begin Read_Data_Packet Procedure Information_field := ''; Initialise the information field to a null string Wait for a DLE-STX sequence or wait for an EOT

Repeat

Repeat

Read_Character_from_Port (1,Character,Error_code);

Until (Character = DLE) or (Character = EOT); If Character = DLE then

Read_Character_from_Port (1,Character,Error_code)

Else

EOT_Received := True;

Until (Character = STX) or (EOT_Received);

If NOT EOT_Received then

Begin Read Packet String_index := 1;

While (Character <> DLE) and (String_Index < 250) do

Begin Read information field Read_Character_from_Port (1,Character,Error_code); Information_field [String_index] := Character; String_index := String_index + 1;

End Read information field; Read_Character_from_Port (1,Character,Error_code); ETX

End Read Packet

End Read_Data_Packet Procedure;


The above procedure assumes that we are receiving through serial port number 1. The procedure also assumes that no DLE characters will appear in the ASCII data. If there was a possibility that a DLE character could appear in the data then the procedure would have to be modified. Also note that the above procedure checks for an EOT character as a first step and sets up an EOT_Received flag. At the moment the procedure is still very crude. If everything goes according to the protocol it will work - but what would happen if the DLE-ETX sequence didn't appear after 250 characters were read into the information field? The next procedure is the one which checks for errors in the information field of the packet that has been read by the Read_Data_Packet Procedure. This procedure compares the incoming Block Check Sum (BCS) with its own local calculation. If they are the same then it issues an ACK, otherwise it issues a NAK in order to request a re-transmission.

Procedure Read_and_Acknowledge_Packet;

Var

Local Transmission Counter Variable

Receive_counter : Integer;

Begin Read_and_Acknowledge_Packet Procedure Receive_counter := 0; Initialise

Repeat

Read_Data_Packet; If EOT Received then

Write_Character_to_Port (1,ACK, Error_code)

Else

Begin Check and Correct Transmission Errors Read_Character_from_Port (1,Remote_BCS,Error_code); Calculate_Local_BCS;

If Remote_BCS = Local_BCS then Write_Character_to_Port (1,ACK, Error_code);

Else

Begin error Write_Character_to_Port (1,NAK, Error_code); Receive_counter := Receive_counter + 1;

End error;

End Check and Correct Transmission Errors;

Until (Remote_BCS = Local_BCS) or (Receiver_counter = 3) or (EOT_Received); End Read_and_Acknowledge_Packet Procedure;


If we were serious about covering all the possibilities, then we should really be acting upon any error message that arises from either the "Read_Character_from_Port" procedure or the "Write_Character_to_Port" procedure. The sort of errors which can occur include parity, overrun, etc. One needs to keep in mind the cumulative effect of all the possible error conditions we have thus far neglected to flag. We have also failed to account for situations where the link is severed in the middle of the transmission sequence. The procedures provided are inadequate because they either fall into endless loops or else cause the program to crash entirely. However, accounting for possible link failure conditions complicates the structure of all the above procedures, and sometimes we may choose to ignore certain error conditions, with the expectation that they may be rare. Once we have established these two procedures (plus the minor procedures which performing menu selection, screen handling, etc.) we can look at the File_Receive_Mode procedure, which handles the entire hand-shaking sequence and data transfer. This could be developed in the following procedure form:

Procedure File_Receive_Mode:

Var Local Device Status Flags

Screen_OK : Boolean;

Disk_OK : Boolean;

Disk_Transfer : Boolean;

Begin File_Receive_Mode Procedure EOT_Received := False; Clear_Display_Screen;

Writeln ('Waiting to Receive a file...');

Repeat Read_Character_from_Port (1,Character,Error_code);

Until Character = ENQ; Write_Character_to_Port (1,ACK,Error_code); Read_and_Acknowledge_Packet; Incoming Command Packet


If Information_field [1] = 'C' then

Case Information_field [2] of

'S': Begin Screen listing

Disk_Transfer := False; Check_Screen_State (Screen_OK);

If Screen_OK then Transmit_Message ('A') Command Accepted

Else Transmit_Message ('S'); Screen Error

End Screen listing;

'D': Begin Disk store

Disk_Transfer := True; Check_Disk_Space (Input_File_Size, Disk_OK);

If Disk_OK then Transmit_Message ('A') Command Accepted

Else Transmit_Message ('D'): Disk Error;

End Disk store;

End case;

Repeat Read_and_Acknowledge (Packet);

If Disk_Transfer then Write_Information_field_to_Disk

Else

Write_Information_field_to_Screen;

Until EOT_Received;

Writeln ('End of File Transfer...');

End File_Receive_Mode Procedure; At this point we have established the structure for the file receiving procedure. We now need to look at the structure of the File_Transmission_Mode procedure, which will perform the complementary side of the protocol during transmission. The structure of this procedure would be in the following form:


Procedure File_Transmission_Mode;

Var Local_File_Name : String [8];

Remote_File_Name : String [8];

Transfer_Mode : Char;

Begin File_Transmission_Mode Procedure Clear_Display_Screen;

Write ('Enter file to be transmitted: '); Readln (Local_File_Name);

Write ('Transfer to remote Disk (D) or Screen (S): ');

Readln (Transfer_Mode);

If Transfer_Mode = 'D' then

Begin Get remote name

Write ('Enter target file name on remote device: ');

Readln (Remote_File_Name);

End Get remote name);

Writeln ('Transmitting file ',Local_File_Name,'...'); Write_Character_to_Port (1, ENQ, Error_code);

Repeat Read_Character_from_Port (1,Character,Error_code);

Until (Character = ACK) or (Time_Out); Transmit_Command (Transfer_Mode); Read_and_Acknowledge_Packet; Reply Message to Command

If Information_field [2] = 'A' then

Begin File Transmission

Repeat Read_Block_From_File_to_Info_Field (End_of_File);

If NOT End_of_File then Transmit_Data_Block;

Until End_of_File; Write_Character_to_Port (1,EOT,Error_code);

Writeln ('Transmission completed...); End File Transmission

End File_Transmission_Mode Procedure;


The "File_Transmission_Mode" procedure gives the basic structure for the transmission of a file under the HYPOLINK protocol. There are obviously a number of other procedures which need to be developed in order to realise transmission. Procedures such as "Transmit_Command", "Transmit_Message" and "Transmit_Data_Block" build up and send a packet through the serial link. The structure of the "Transmit_Data_Block" procedure is shown below and is typical of the packet transmission procedures:

Procedure Transmit_Data_Block;

Var Index : Integer;

Transmission_index : Integer;

Begin Transmit_Data_Block Procedure Transmission_index := 0;

Repeat

Write_Character_to_Port (1,DLE, Error_code); Write_Character_to_Port (1,STX, Error_code); For Field_index := 1 to length [Information_field] do Write_Character_to_Port (1,Information_field [index], Error_code); Write_Character_to_Port (1,DLE, Error_code); Write_Character_to_Port (1,ETX, Error_code); Read_Character_from_Port (1,Character, Error_code); Transmission_index := Transmission_index + 1;

Until (Character = ACK) or (Transmission_index = 3);

End Transmit_Data_Block Procedure; These procedures are only intended as a rough guide to how one goes about developing the software for a communications protocol. The procedures shown above are already showing signs of complexity, even though our hypothetical protocol is very simple. The more that you study these procedures the more scope you will find for program failure under abnormal circumstances. For example, what happens if a communications error causes an STX to appear as an ETX? What happens if a DLE and ETX appear as part of the data? The list of "what-if" scenarios is enormous.


We can continue to enhance procedures, such as those shown above, to take into account a much broader range of abnormal conditions. In the final analysis however we must accept that no protocol will account for every possible error that can occur. The final implementation is ultimately based upon a sensible calculation of risks and possible error conditions. A good way of determining how far one should proceed with error checking in a protocol is to ask the question:

"What can a device do to rectify a given problem through software?"

In many cases the answer is nothing except to flag an error. Take a good look at the Hypolink protocol for examples. What would happen if a receiver found that there were 251 characters in the information field of a packet? How would it resolve the problem? Would it assume that the entire packet is worthless and ask for a re-transmission? Would it assume that the first 250 characters are correct and that the 251st was a corrupted delimiter? The net result is that it is often too difficult to account for every error. There are many instances when the software must be designed to simply abort a transaction. The most obvious example of this is when an acknowledgment is not received to an enquiry, but there are numerous other combinations that need to be thought out by the protocol developer. The protocol software developed above is clearly just a crude beginning to what must inevitably be a demanding task for those who attempt to program protocols - even when the protocols themselves are not complex.


6.4 Communications Software Layering In section 6.3 we examined how the PASCAL source code for a hypothetical communications protocol could be developed. An important point to note about the exercise is the way in which various software modules or procedures interact with one another. We started the process of establishing a serial communication link by discussing the type of hardware (UARTs, cabling and hand-shaking) that could be used to facilitate the link - for example, RS-232 or RS-449. We then moved on to look at some basic pieces of software that would interact with that hardware in order to perform some meaningful communications task. In our case, these procedures were called:

• Set_Serial_Port_Parameters

• Write_Character_to_Port

• Read_Character_from_Port. Once the basic hardware and software procedures were put into place, it was then possible to develop other software procedures that could perform some data packet assembly and disassembly, error-detection, correction and hand-shaking between devices. Ultimately we developed two high-level procedures:

• File_Transmission_Mode

• File_Receive_Mode. These procedures could be incorporated into a user program (application) to perform a file transfer operation. We can schematically represent the structure that was achieved in our protocol development as shown in Figure 6.11. The diagram of Figure 6.11 is a "layered model" of the software and the hardware that we have put together in order to create a functioning communication link. Each layer in the system is a well-defined entity. It takes information from the layer above or below, processes that information and feeds the output to the layer below or above. A layer that is involved with the actual link hardware (including modulation, cables, connectors, etc.) is referred to as the "physical layer". At the other end of the spectrum, the layer that most closely interacts with the applications program is referred to as the "applications layer". However, there is no question of one layer being any more or less important than any other layer. For without all the layers present, the protocol is not satisfied.


Transmit & Receive

Main Program

File Transmit &

Receive Procedures

.

.

Error Detection &

Correction

Packet Assembly or

Disassembly

Character Transmit &

Receive Procedures

Hardware (RS-232)

Transmit & Receive

Main Program

File Transmit &

Receive Procedures

.

.

Error Detection &

Correction

Packet Assembly or

Disassembly

Character Transmit &

Receive Procedures

Hardware (RS-232)

ApplicationsPrograms

Application Layer(Program Support)

Physical Layer

Communications Medium

Figure 6.11 - Schematic of Communications "Layering" Concept

The advantage of looking at communications system development from a "layered" point of view is flexibility. Provided that the information flowing into or out of a layer (ie: the upper and lower interfaces) remains the same , then the internal operation of any one layer can be completely independent of the surrounding layers. Let us look at some examples of this point. Supposing that we replaced the communications medium and RS-232 hardware layer with a different standard - say RS-449. Provided that the RS-449 hardware on each device could supply the read and write procedures (of the layer above) with the same information as the RS-232 system, then these procedures could not detect the change. At the other end of the spectrum, we can look at the applications programs. It is irrelevant how we structure these programs or their user interfaces. It is irrelevant how we construct menus or screen displays. Provided that we call the file transfer procedures of the layer below in the correct way, then they can still function independently. We shall look more closely at layering of communications software and hardware in a subsequent chapter.


6.5 Terminal Emulation and the Kermit System One of the major applications for serial links (such as those defined by RS-232) is in communications between a mainframe (or workstation) computer system and a terminal. Originally, a computer terminal was little more than a Visual Display Unit (VDU) and keyboard. The device essentially had no processing or bulk storage facilities and so was referred to as a "dumb terminal". In today's computer environment however these so-called "dumb" terminals have often been replaced with Personal Computers (PCs). PCs can either act as intelligent devices in their own right or else mimic particular brands of (dumb) computer terminals. This provides the best of both worlds. The mainframe is relieved of tasks such as word-processing and spreadsheets, but is available for centralised data (file) storage and complex tasks (such as advanced CAD, MRP, etc.) A schematic for a typical computer to terminal arrangement is shown in Figure 6.12.

Dumb Terminal Personal

Computer

Personal

Computer

Personal

ComputerDumb Terminal Dumb Terminal

Mainframe

Workstation

or

Figure 6.12 - Typical Computer to Terminal Arrangement


Over the years, many of the major computer manufacturers have developed dumb computer terminals that can interact with their mainframe systems in a clearly defined way. A number of these terminals are in very common usage in industry and many multi-user operating systems, on computers, are specifically designed to facilitate communications with such devices. Normally, alpha-numeric characters on dumb terminals are represented by bit patterns corresponding to either 7 bit ASCII or 8 bit EBCDIC codes. However there are many other keys on a typical dumb terminal besides alpha-numerics. For example, the function keys, scroll lock keys, cursor movement keys, etc. The bit patterns for these are not defined by either the ASCII or EBCDIC system. Therefore, if we wish to replace a dumb terminal with a PC, it is necessary to have a piece of software that will make the PC read and write through its serial port in the same way as a dumb terminal. It is additionally necessary to convert the various bit patterns generated by special purpose function keys on a PC to the bit patterns that would be generated by a specific type of terminal. The software used to perform these functions is referred to as "Terminal Emulation" software. At its most basic level, a Terminal Emulator echoes data (coming from the mainframe) to the PC screen and transmits data (from the PC keyboard) through its serial port. However, commonly available Terminal Emulation packages tend to do far more than just emulate specific types of terminals. The reason for this is because the role of a PC acting as a terminal to another computer is totally different to the role of a dumb terminal. A PC acting as a terminal to a mainframe can do a vast amount of its own processing work - for example spreadsheets, word-processing, desktop publishing, micro-CAD, etc. In these situations, the PC generates data files that can then be fed into the mainframe for centralised storage and access. Conversely, files can be fed from the mainframe back to a PC as part of the retrieval cycle. Dumb terminals only read in data from a mainframe for display purposes. Data written on a dumb terminal is transmitted back to the mainframe as soon as it is keyed in. There are normally no local file generation or file transfer capabilities associated with dumb terminals. If PCs are to act as terminals and transfer files to and from a mainframe, then we need to have a protocol which checks and corrects for transmission errors. There are many such protocols available for communications between PCs and mainframes and they are not unlike the hypothetical ACK/NAK protocol that we examined in section 6.3. The more common protocols are often provided as a standard feature of a Terminal Emulation software package that one buys for a PC.


One of the most prolific of the protocols used for transferring data between a mainframe and a PC is known as the "Kermit" protocol. The Kermit protocol was developed by Columbia University in the United States specifically as a means for transferring files between mainframes and PCs. The Kermit protocol is essentially an ACK/NAK protocol, where files are transmitted in blocks, and error checking is through Block Check Sum calculations. The software for Kermit is available for a range of different computer platforms (in addition to PCs) and is therefore widely used. A number of Terminal Emulation packages, available for PCs, provide Kermit as a standard feature. Another protocol that has been developed for transferring data files between computer systems is the Ward Christensen system, referred to as "XMODEM". The XMODEM system was originally designed in 1977 as a protocol for transferring data between PCs, but has since been used for mainframe to terminal communication. Initially, the XMODEM system was a simple ACK/NAK protocol that used a single character Block Check Sum calculation for error detection, but more sophisticated versions utilising Cyclic Redundancy Check (CRC) polynomials have also become available. Unfortunately, it is not always possible to use common protocols such as Kermit or XMODEM to transfer data to and from PCs. Many programmable devices, such as serial printers, CNCs and PLCs cannot be equipped with the necessary software that will allow this to occur. Many industrial devices use their own peculiar protocols and therefore one has to develop the corresponding PC software as described in section 6.3. The worst-case scenario is where a device does not have its own protocol (with error checking) and cannot have such a protocol installed. Such devices often allow files or data to be simply "dumped" to or from remote devices through a serial port. In simple terms, file dumping means transmitting an entire file (character by character), from one device to another, without rules of protocol, error detection or correction. File dumping is not a secure means of transferring files between devices and the possibility of error must always be considered when using such a technique. It is often used as a last resort and if the transmitted data is important, then some manual checking of received data must always be performed. The most common example of file dumping, in the manufacturing environment, is where a CNC program, generated on a CAD system, needs to be down-loaded to an older style CNC machine. If the distance between the CAD system and the target controller is large, and noise-immune communications links are not in place, then a PC, running "Terminal Emulation" software can be used as a relay stage in the transmission process to minimise errors. This is shown in Figure 6.13.


Kermit Kermit

File

Dump

File

Dump

CAD

Mainframe PC CNC

Long RS-232 Link

Short

RS-232Link

Secure Protocol UnsecureProtocol

(Shielded)

Figure 6.13 - Using Terminal Emulation to Minimise Errors in Data

Transmission to Devices without Secure Protocols

The CNC machine program file is transferred from the CAD computer to the PC via a secure protocol such as Kermit, which can detect and correct communications errors. The PC is then located in close proximity to the target machine controller and the file "dumped" to the controller over a very short, shielded RS-232 link (with shielded connectors) in order to minimise chances of data corruption. Although this is clearly a "makeshift" solution, it may prove worthwhile for transferring long CNC program files that are generally related to the production of high cost products. Terminal Emulation software has become an extremely valuable tool in the manufacturing environment. A Comprehensive Terminal Emulation package for a PC must therefore be capable of performing the functions described above and needs to contain the following modules:

(i) Serial Port Parameter Set up (ii) Emulation of common dumb terminals (iii) Kermit Protocol (iv) XMODEM Protocol (v) File Dump procedures

Terminal emulation does not however, resolve the problem of transferring data according to specialised protocols, which must still be specially tailored for each application.

211

Chapter 7

Local Area Networks - Fundamentals

A Summary...

Basic concepts of Local Area Networks. Network topologies and characteristics.

Resolving contentions for use of network media. The seven layer ISO/OSI model.

Public Data Networks.


♦ You want to learn the fundamentals of computer networks

♦ You need to know about the function and application of Local Area Networks

in the industrial environment.

♦ You want to know about the framework in which Local Area Networking

standards are established.


7.1 Local Area Network Concepts

A data network is a mechanism by which many computer-based devices

(referred to as network nodes) can communicate with one another on an "any node to

any node" basis. A Local Area Network (LAN) is so named because the nodes on

that network are located within a reasonable proximity (less than a kilometre) of one

another. A point to point link between two nodes can therefore be considered as a

network with two nodes and it shares many of the characteristics of larger networks.

We already know that even a simple, point to point serial communication link

between two nodes needs to have many rules of protocol resolved before it can

function correctly. We need to use the common signalling techniques, common

character representations, complementary communications hardware and so on. We

need the communications interchanges between nodes to be strictly governed by

these rules of protocol so that conflicts can be resolved. All these issues are also true

of networks - except that now we need to coordinate the communications between

many nodes simultaneously.

The majority of networks use serial communication between nodes. With this

in mind, there are a number of ways in which we can physically interconnect these

nodes so that any one node can communicate with any other node in a serial form.

Three of these interconnections are shown in Figure 7.1.

In Figure 7.1 (a), a switching unit (multiplexer) physically connects the serial

cable from any one node to the serial cable from any other node. Once the switching

unit has made a physical connection, then two nodes can communicate with one

another as though the multiplexer was not present. Any node connected to the

multiplexer can request it to make a physical connection with a target node. The

multiplexer therefore needs to have some "intelligence", particularly if a conflict

(contention) situation arises, where several nodes request connection to the same

target node at the same time.

In Figure 7.1 (b) all the nodes are physically connected together on a central

cable (trunk). Whenever one node places data on the trunk cable, all the other nodes

receive that data. Since there is no intelligent switching device in this network, it is

necessary to establish a system (protocol) where each node can recognise relevant

data and ignore irrelevant data. This situation is the serial analogy to the parallel data

bus structure within a computer system. Although it is possible to have multiple

channels existing on a cable (through the use of modulation), a contention still arises

if two devices attempt to transmit at the same time on the same channel. Each of the

devices on such a network must therefore have the intelligence to independently react

to and resolve such contention situations.

Local Area Networks - Fundamentals 213

Node 1 Node 2

Node 3 Node N

Multiplexer

Node 1 Node 2

Node 3 Node N

Node 1

Node 2

Node 3

Node N

(a) Node Connection Through (b) Node Connection Through Common(Bus) CableSwitching Device

(c) Node Connection Through a Loop of

Point to Point Serial Links

Figure 7.1 - Interconnection Techniques for Creating Data Networks

In Figure 7.1 (c), nodes are connected to one another via "point to point" serial

links that together form a logical ring. Data is passed from one node to another

around the ring. As in the system of 7.1 (b), there is no intelligent "coordinating

node" and hence all nodes must have the intelligence to cope with contentions and

recognise appropriately targeted data.

In a point to point serial link there is only one possible destination for all

transmitted data - that is, the node at the other end of the serial link. However in a

network, each transmitting node must theoretically be capable of sending information

to any other node on that network. All the network forms therefore need to cope with

the fundamental issue of "addressing". All nodes need to be given a unique "address"

in order for data to be targeted correctly. The problem of network addressing is not

unlike the problem of addressing devices (sharing the same data bus) within a

computer system.


In the network of Figure 7.1 (a), a transmitting device needs to tell the

multiplexer the address of the target node to which it wishes to be connected. The

receiving device needs to know which device originated the message so that it can

address a response. In the networks of Figure 7.1 (b) and (c) all devices have access

to all messages. Therefore, a transmitter needs to know the address of the device to

which it is sending a message. A receiving device needs to know its own address and

the intended destination address of all incoming messages. Receiving devices in all

systems must be programmed to only respond to messages that are specifically

intended for them.

The need for addressing means that regardless of the physical network

arrangement, data must be placed into suitable packets for transfer. Each packet of

data moving through a network needs to contain some source and target addressing

information. This enables a receiving device know which device is transmitting to it

and where to send response messages. The concept of packet addressing is shown

schematically in Figure 7.2.

Node A Node B Node C

Node D Node E Node F

From: ATo: EData

From: FTo: BData

Figure 7.2 - Addressing Packets of Data on a Network

With the exception of traffic control (contention) and addressing functions, the

issues related to networks are essentially the same as those in point to point links.

We still need error checking mechanisms in the form of Block Check Sums (or more

commonly, Cyclic Redundancy Checks). We still need hardware to perform parallel

to serial (and vice-versa) conversion on each node. We still need layers of data

handling software that can provide our applications programs with powerful

communications sub-programs.


Another topic which sometimes causes confusion in regard to networks, is

cabling. People often believe that there is something unique about the cables used in

networks, as opposed to those used in point to point links. However, cable varieties

used in common networks are the same as those used in point to point links, and

include shielded-twisted-pair, co-axial and optic fibre. The major difference between

network media and point to point media is in the connectors. If we choose to have a

bus type network as in Figure 7.1 (b), then we need to have special connectors that

can tap into the transmission medium at selected points. On the other hand, if we

have a switched network such as that in Figure 7.1 (a), then we can often use the

same connectors as in point to point communication - for example RS-232.

One of the most common LAN media, in the bus network arrangement, is the

co-axial cable. One of the major reasons for this is because of the proliferation of

low cost connectors and adaptors that resulted from the introduction of the American

cable television system. Co-axial cable lends itself to "tapping" at any point so that

many devices can be connected to a central trunk, as shown in Figure 7.1 (b). When

co-axial cables are used in LANs, only one conductor is available for signal

transmission (plus another common return line). Therefore if we wish to achieve full-

duplex communications in LANs, we need to separate transmitted and received data

into "forward" and "reverse" channels, through the use of modulation.

Twisted-pair cables are also extensively used in networking, but are more

prone to electro-magnetic interference than co-axial cables. They are therefore better

suited to the office, rather than the industrial environment. However, twisted-pair

systems are low in cost and it is possible to simply have two pairs of wires for

transmission and receipt of information - thus abrogating the need for modulation.

Optic fibre cables are currently not as prolific in LANs as they are in point to

point links. The major reasons for this relate to the relative difficulty of tapping into

optic fibres, and in terminating them without the use of specialised equipment.

However, as optic fibre technology develops and the cost of connectors and adaptors

decreases, it is evident that the system will become the dominant networking medium

because of its superior noise immunity and higher bandwidth.

Cable types and connectors are not really a major issue in networking as far as

end-users are concerned. In general, we have to accept a transmission medium from

a limited range of commercial solutions that conform to an overall protocol. There

are however, many other issues to be resolved when we attempt to physically

interconnect a number of intelligent devices through a network. We shall look at

these as we progress through the chapter.


7.2 Network Topologies

In section 7.1 we looked at three different ways in which nodes could be linked

together to form a network. These physical arrangements are more commonly

referred to as network "topologies".

Figure 7.3 shows each of the network topologies (introduced in the previous

section) together with their common names.

Node 1 Node 2

Node 3 Node N

Multiplexer

Node 1 Node 2

Node 3 Node N

Node 1

Node 2

Node 3

Node N

(a) Star Network (b) Bus Network

(c) Ring Network

Figure 7.3 - Common Network Topologies

Each of the different network topologies has its advantages and disadvantages.

There is no single solution that is optimal for all applications.


The star network has an intelligent central node, referred to as the "star node".

The star node makes the decisions related to connecting any pair of nodes together. It

therefore needs to be able to resolve any contentions that may arise. The star node is

also responsible for tasks such as queuing requests for "link establishment" between

nodes.

A star network is composed of a number of point to point links emanating from

the star node. Several advantages stem from this. Firstly, the star node is transparent

to communicating nodes once a connection has been made. Provided that the

connected nodes agree on a software protocol, the nature of that protocol is of no

consequence to the star node and the remainder of the network. In other words,

devices 1 and 2 can talk to each other through "protocol A" and devices 3 and 4 can

talk to each other through "protocol B". It is then also possible that device 3 can talk

to device 1 through "protocol A". This has merits in manufacturing where it is not

always practical to have all nodes using a single protocol and yet it may still be

necessary to have all nodes capable of talking to one another. A good example of

this would be where devices 1, 2 and 3 are computers and device 4 is a robot or CNC

machine (with a fixed protocol).

Another advantage of the star network is that the physical medium used

between any one node and the star node can be varied to suit the operating

environment. For example, if device 1 is in the factory then it can be linked to the

star node through an optic fibre cable. If device 2 is in the office, close to the star

node, then it can be linked via a twisted-pair cable and so on.

There are also a number of disadvantages to the star network topology. All

communication is dependent upon the star node - if it fails then all communications

ceases. In a simple star network, the star node may be a microprocessor-controlled,

serial port PABX (a multiplexer). In this case it is feasible to maintain some

redundancy since the cost of the star node is minimal. At the other extreme however,

a large star network could have a mini-computer as the star node, with many

intelligent terminals communicating to one another through it. In this situation it is

not practical to maintain redundancy.

Another shortcoming of the star network system is the cost of cabling. It is

more cost effective to lay a single trunk cable through a networking area, and to use

short tap cables from each node to the trunk, rather than to have long cables all

meandering their way towards a central node. This is best visualised in terms of the

power supply within a home. A power supply bus runs throughout a house and

appliances tap into that bus at convenient points. It is a much neater solution than

having every appliance connecting to a single, central point.


Another significant factor that arises in the cost equation for star networks is

that of cable maintenance. In large star networks, many cables need to converge on

the central node. Hence the concentration of cables, within ducts near the star node,

is always very high. This makes trouble-shooting more difficult and time-consuming

than it would otherwise be with other network configurations. In a large industrial

environment, the problem of cable maintenance in star networks is severe. Often,

defective old links are simply replaced with new links, and the old links left in the

ducts, because the cost of removing them (or tracing problems in them) is so high.

The "dead" links then further add to the cable concentration near the star node.

The problems of high cable concentrations are automatically eliminated in bus

networks, where a central trunk of either twisted-pair, co-axial or optic fibre cable is

laid down throughout a networking zone. Each node is connected into the network

through a short tapping cable in a manner that is completely analogous to the

domestic power supply scenario cited earlier.

The bus network is perhaps the most common form of the networking

topologies - particularly in the industrial environment. A bus network is similar to

the internal bus structure used for communications within a microprocessor system

environment. The major differences are that in bus networks, data transfer is serial

(not parallel) and secondly that there is no simple "master-slave" relationship

between devices and therefore many contention situations can arise.

Bus networks offer a flexibility in terms of cable utilisation, which cannot be

achieved with other network topologies. The fact that a bus network is based upon a

trunk cable, which is laid throughout an entire area, means that video and voice

channels can share the same cable, through the use of modulation techniques. This

greatly increases the cost effectiveness of the bus network.

In a ring network, neighbouring nodes are interconnected with point to point

serial links until a complete ring is formed. Data in ring networks is passed uni-

directionally from node to node. Each device receives a message and then re-

transmits it. This is shown in Figure 7.4.

A device in a network ring originates a message that is passed around the loop

from node to node. Nodes in between the source and the destination do not alter the

message. However, when the destination node receives the message, it modifies the

control portion of the message packet and places it back onto the loop. The

originator of the message packet determines whether or not the message has reached

its target correctly by the modifications on the returning packet. Ring networks are

relatively commonplace in the office environment, where the area they cover is

relatively small. The response time of networks based upon the ring topology can be

very good with an appropriate protocol.


Node 1

Node 2

Node 3

Node N

OutIn

In

In

In Out

Out

Out

Figure 7.4 - Ring Network Message Transmission

A potential problem for the ring network topology arises because devices are

all interlinked with point to point links. Hence one is tempted to ask what happens

when a device fails - does the network stop? As it turns out, there are by-pass

mechanisms built into ring networks so that devices that are down (or just switched

off) provide a short-circuit path and do not result in network failure. However, the

ring network completely fails if any one of the point to point links is severed.

In terms of cabling in ring networks it is evident that if one node is far removed

from all other nodes then the cost of transmission medium will be higher than that in

the bus network. For this reason, ring networks are most commonly found in the

office environment for short-distance communications.

In theory, every node on both the bus and ring network topologies can have

access to all the binary data that is transmitted through the communications medium.

Nodes in these networks are normally selective about which data they respond to and

base their response upon addressing information on data packets. However, from a

more political point of view, bus and ring networks can be "tapped" into by

unauthorised users. A tapping point anywhere within these networks will provide

access to all network activity and information.


The bus and ring topologies are much more restrictive than the star in terms of

the devices that can be connected into the network. All devices connecting into bus

and ring networks must be capable of responding to a common communications

protocol - otherwise such a network can clearly not function. In terms of general

purpose (fully programmable) computer systems, it is feasible to link a wide range of

devices to a bus or ring network. However, many devices simply do not fit into this

type of communications structure. For example, few low-cost printers and many

older industrial controllers cannot be interfaced into bus or ring networks, because

they are not fully programmable and they do not have standard, internal bus

structures.

Bus and ring networks offer one major advantage over the star network. To

begin with, they are not dependent on a central, intelligent node to provide routing of

messages and resolution of contentions that arise when a number of devices wish use

the communications medium simultaneously. Each node in bus and ring network

topologies is responsible for adherence to rules of protocol. In both bus and ring

networks, the system can still continue to function even when one or more nodes

become inoperative.

Ultimately the selection of a networking topology is governed by a number of

factors including:

• the type of protocol selected to govern the network

• the availability of interfacing equipment

• the type of equipment being networked

• the environment in which the network is located.

It may be that, in the final analysis, the decision comes down to selecting the network

to which the most devices can be interfaced with the minimum amount of effort.

In the manufacturing environment, the most common high-level network

topology is the bus structure and the majority of protocols for this environment are

based upon this topology. Star networks are also in widespread use in manufacturing

to link CAD systems to a range of different CNC machines.

As with many engineering problems, there is no single solution that is correct

for all applications. Sometimes the decisions that need to be reached are based on

conformance or convenience rather than any technical reasons.


7.3 Contention Schemes

The technique of modulation allows us to utilise a transmission medium with a

high degree of efficiency. Modulation is all about changing the physical

representation of information, by creating communications channels, so that many

different information systems can share the same transmission medium. This gives

us the opportunity of using the same transmission medium for video, audio and

digital data transmission - however, within any one channel conflicts can still arise.

In terms of data communications, each channel is generally restricted to one

quantum of binary information at any instant in time. Sometimes this is for physical

reasons and sometimes this is for practical reasons. For example, it may be

impossible to decode a signal, which is the lump sum of a number of messages, back

into the original (individual) messages. In a network, or more specifically in a bus

network, we have a situation where there is the potential for many nodes to attempt to

place data onto the transmission medium at the same time. This uncontrolled

transmission could make decoding impossible. The physical conflict is called a

contention situation.

Figure 7.5 shows a bus network in which devices are all tied together through a

two wire conducting cable (signal + common line). Since all devices in this network

are "intelligent", they are capable of placing data (represented by voltage levels) onto

the bus at any time.

Node 1 Node 2 Node 3 Node N

V V2 3

Signal

Common

Figure 7.5 - Network with Devices Connected via a Conducting Bus

If we forget modulation for the time being (since we are considering

communications within one channel anyway), we can consider the ramifications of

two devices simultaneously trying to put binary data onto the line at the same time.


Consider the situation where both devices 2 and 3 put the same binary data

onto the line - say a high voltage. There is no physical conflict, but nevertheless

none of the other devices can detect that there are two devices speaking and not one.

However, if device 2 places a low voltage on the line whilst device 3 places a high

voltage on the line, then we have a physical conflict and a temporary short circuit on

the cable between these devices. In practice this short circuit is probably not

destructive, partly because the cable does have some resistance, but more importantly

because the outputs and inputs of devices are buffered and do not have rigidly fixed

voltage outputs. In any event the data that is now on the bus is meaningless.

Ultimately it doesn't really matter whether we are talking about transmission on

a conducting cable or optic fibre cable or high frequency transmission through the

air. The contention problem within any one channel always manifests itself in one

energy form or another. It is important to note that the phenomenon of modulation

does not cause the same physical conflict within the communications medium and

that the individual elements within a modulated system can be recovered.

All of the above discussion is well and good, but what techniques are available

to resolve the problem of contention on bus networks? Contentions can be resolved

in any number of different ways, but there are two generic techniques of contention

resolution that are in widespread use. These are the "CSMA/CD" system and the

"Token Passing" system.

(i) CSMA/CD

CSMA/CD is an abbreviation for "Carrier Sense, Multiple Access with

Collision Detection". The CSMA/CD system sounds complex but is

straightforward to implement in practice. It is used within a number of

different bus networks.

Each device in a CSMA/CD system is allowed to attempt to transmit on the

network bus at any time. In other words, multiple access. However, prior to

attempting a transmission, each device must monitor the bus for the presence of

a carrier signal, emanating from another node. This is called "carrier sensing".

If a carrier is already present on the bus (another node is already transmitting),

then the device must wait until that transmission has ceased before attempting

to place a message packet (frame) on the bus. Even when a device has the right

to transmit, it must still monitor the bus to ensure that the signal that is being

sent is the same as that on the bus.


It should be apparent, that two devices may simultaneously detect that the bus

is clear and simultaneously attempt to transmit a message frame. In this case a

collision will occur. Since all devices are monitoring the state of the bus, both

of the devices will detect the collision. The first device to detect a collision

must transmit a random bit pattern, referred to as a "jam sequence" for a short

period of time. The jam sequence is designed to last long enough for the other

colliding device/s to realise that a collision has occurred.

Since data is corrupted by a collision, both devices back-off for a random time

interval and attempt complete re-transmission of message frames later. The

CSMA/CD system is probabilistic in nature. In other words, there is no way of

knowing how long it will take for a message to get from source to destination.

A CSMA/CD network is therefore said to be non-deterministic.

The CSMA/CD system is not ideally suited to the industrial environment. The

irony of CSMA/CD is that the time delay for messages is longest when the

network is busiest and the network is generally busiest when abnormal or

emergency conditions arise. Since we demand the fastest response time under

emergency and abnormal conditions the network is often classified as

unacceptable in the factory. CSMA/CD is however an excellent system for the

office environment and is extremely efficient, where data transfer between

nodes is sparse, and occasional time delays are of little consequence.

(ii) Token Passing Schemes

In principle, the so-called "token passing" scheme sounds much simpler than

the CSMA/CD system. In practice it is more difficult to implement. The

scheme is based upon a binary bit pattern that is referred to as a "token".

Before any node is permitted to place message frames onto a network, it must

be in possession of the token. Once a node has the token, it is permitted to

transmit a message frame and must then pass the token on to another node. The

movement of the token from node to node forms a "logical ring" between

devices.

The token is itself a message frame (packet) with a special control section that

defines its characteristics. A node wishing to use the token modifies these

characteristics so that it can become a message frame. The node can then place

data into the message frame. The token passing scheme is deterministic,

because it is possible to precisely define the maximum delay that will arise in

transmitting a data frame. It is for this reason that the scheme is often

promoted as a basis for industrial networks.


There are a number of problems with the token passing scheme. Since it is

possible for a device to fail while it is in possession of the token, steps must be

taken to ensure that there is a mechanism for regenerating a lost token. This

makes the system much more complex than the CSMA/CD system. The token

passing scheme also introduces delays into the network even under light traffic

conditions. In other words, a token is still passed from device to device,

whether or not that device is to broadcast on the network. In the CSMA/CD

scheme, a transmitting device can export information immediately if the bus is

clear - with token passing the transmitter must always wait for the token.

Having introduced two of the more prolific contention resolution schemes, and

the expressions "deterministic" and "non-deterministic", it is important to qualify

their definitions. A network is the sum total of the communication medium, the

contention resolution scheme and all the other software functions that go together to

form applications support sub-programs. The fact that a contention resolution

scheme is deterministic does not mean that the total network is deterministic. All the

elements of a network need to operate in a complementary (deterministic) manner in

order to provide a fixed response time.


7.4 ISO / OSI Seven Layer Model

In order to make a number of computer controlled devices communicate with

one another, on a meaningful basis, there are many definitions that need to be

established, including:

• Electrical signalling methods

• Synchronous/asynchronous transmission mode

• Bit rates

• Error detection and correction techniques

• Cable types and connector types

• Modulation techniques

• Contention schemes

• Software structure to support applications programs.

As it happens, there are an enormous number of available techniques, hardware and

software systems that can be used to fulfil each requirement. It is little wonder then

that there are so many different networks available.

Whilst variety may be the spice of life, it is a curse to those who endeavour to

link computer based devices together. In the past, the major computer manufacturers

tended work in different directions in regard to networking. Each manufacturer

decided to choose their own specifications for each requirement in the networking

process. Some computer manufacturers pioneered new techniques in particular

aspects of networking - for example, in terms of software support modules or

contention schemes. The end result was that during the 1970s and 1980s we

experienced an explosion of different networks, many of which were proprietary in

nature.

Since different computer manufacturers tended to specialise in different aspects

of computing, users seldom had the luxury (nor the risks) of the single vendor

environment. It also became apparent that no, single networking solution was

universally applicable to all environments and hence a number of different standards

would always be in existence. The obvious course of action was to find a way to

rationalise the development of networking standards so that there may be some hope

of creating links between different networks. Unless there is a systematic approach

to network development, it is extremely difficult to link different networks together

and to create low cost networking hardware.


The problem with trying to rationalise networking standards is that it is a very

complex task to decide upon the scope of a standard for any individual networking

requirement. That is, should a standard define just cables or perhaps cables and

connectors or perhaps cables, connectors, signalling techniques and contention

schemes. Where does one draw the boundaries for standards?

The International Standards Organisation (ISO) tackled this problem by

developing a framework for what is referred to as "Open Systems Interconnection" or

"OSI". The objective of this framework was to place all the requirements, for

making a number of computers communicate with one another, into seven functional

groups called "layers". The end result of this work was the OSI 7-layer

Communications model that is shown in Figure 7.6.

Presentation Layer

Application Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer 1

2

3

4

5

6

7

1

2

3

4

5

6

7

Presentation Layer

Application Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Node A Node B

Applications Program Applications Program

Transmission Medium

Figure 7.6 - Seven Layer ISO/OSI Model for Communications

It is important to note that the OSI model is not a networking standard in its

own right. It is the framework, upon which, the development of communications

standards is based. The choice of seven layers is somewhat arbitrary but is based

upon many practical considerations. Each layer of the OSI model defines a number

of related functions that must be enacted in order to take information from the layer

below/above, process it and feed it to the layer above/below.


Some of the layers in the OSI model will naturally be more complex than

others. However, it is necessary to understand that no, single layer is any more or

less important than any other layer in realising a communication link. The layer

representation is only used to show the logical sequence of steps for transmission or

reception of information. The OSI model is therefore a seven layer shell in which the

individual steps of the communications process are defined.

To illustrate the layering of communications tasks, let us suppose that computer

A wishes to transmit a file to computer B through a network. The file must be

broken down into a number of smaller units that can be sent as packets through the

network. Each packet must be addressed to the target node. The source device, A,

must contend for use of the network medium, access the network, transmit the

information packets in either character or bit form and then transmit error checking

information. If an error occurs then device B must request a re-transmission and

device A must re-transmit appropriate information packets.

Without standardisation, the number of ways in which such a communications

sequence could be programmed and implemented on each device is almost limitless.

If, on the other hand, one takes the layered approach to implementing a

protocol, software and hardware can be developed in discrete modules. It is

irrelevant how software or hardware is generated within these modules - provided

that each module adheres to an accepted standard. The standard for each module

(layer) defines the precise form in which data must be fed into a module, how it is

processed and the exact form in which data is output from a module.

Schematically, the layer by layer packet (frame) assembly and disassembly that

occurs during a transmission sequence (when an application program on computer A

feeds data to the Application Layer for export to computer B) is illustrated in Figure

7.7.

In order to understand the concept of packet assembly and disassembly, it is

sometimes helpful to examine a human analogy. Consider the situation where the

director of large company A (Fred) wishes to send a simple note to the director of

large company B (Harry). Fred sends a simple note:

Dear Harry

Please attend a meeting in my office at 10 a.m. tomorrow.

Regards, Fred


Fred passes the note to his secretary , who places the note into an envelope and

addresses it. The secretary sends the note to the mail-room, where the people look at

the address and decide upon the most appropriate mechanism by which the note

could be sent - private courier (say). The courier decides upon the best medium for

transferring the note (ie: air/sea/land). The note is ultimately transferred to the mail

room of company B. The mail room extracts the address data from the envelope and

decides that it should be sent to Harry's office. Harry's secretary receives the note,

removes the envelope and places it into Harry's in-tray. Harry and Fred only see the

raw data and don't concern themselves with any of the other issues involved in

transferring the note.

Harry and Fred are analogous to the applications programs in the networking

world. The two secretaries are analogous to the applications layers in the OSI model

and so on. In company A, personnel are charged with the responsibility of building a

package for transmission to company B. The personnel in company B are charged

with the responsibility of disassembling the incoming package so that the original

data can be recovered. Figure 7.7 therefore shows how the OSI model provides a

framework for an analogous functionality in the networking environment.

Presentation Layer

Application Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Presentation Layer

Application Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Node A Node B

Applications Program Applications Program

Transmission Medium

(Transmit) (Receive)

Data

(Packet)

Packet

Assembly

Packet

Disassembly

Figure 7.7 - Packet Assembly & Disassembly in OSI Networks


Provided that all the OSI layers have been put into place on a computer, then a

user who wishes to program a device to transmit information through a network need

only be concerned with the Application Layer. This layer contains all the sub-

programs, related to network activity, which can be called up in any user's end

application program. The actual role of each layer is briefly outlined below:

(i) Physical Layer

This layer is concerned with the physical connection between devices. It

includes factors such as network topology, cable types, connector types, signal

modulation types and contention schemes. It is the physical layer that is

directly responsible for transmitting a stream of binary digits from one device

to another.

(ii) Data Link Layer

The Data Link layer is responsible for ensuring the integrity of the bit streams

that are transferred to/from the physical layer from/to the network layer. It is

the data link layer that takes care of error detection and correction through the

re-transmission of messages. Data link layers can provide both

"connectionless" and "connection oriented" services. In a connectionless

system, each information packet is treated as a self contained entity that is

transferred to a target node without a two-way dialogue (connection) having

been established. In a connection oriented system, devices try to establish a

physical link before attempting data transmission. Whilst the physical layer

puts the contention scheme into place, it is the Data Link Layer that is

responsible for accessing the communications medium (Media Access

Control).

(iii) Network Layer

The network layer is primarily concerned with message routing (or addressing)

functions. It is designed to establish and clear logical or physical connections

across the particular network in use. The network layer, to some extent, also

has responsibility for flow control between devices. The network, data link and

physical layers are all interdependent and hence the standards for each of these

need to be selected with a view to forming a cohesive system based on all three

layers.


(iv) Transport Layer

The transport layer is the one that interfaces the network dependent layers

below to the network-independent, applications layers above. It is responsible

for establishing a reliable message interchange service (between nodes) and

providing this service to the session layer above. Since the transport layer's

performance is restricted by the types of service available from the lower, three

layers it must also be designed to provide different levels of service - referred

to as "classes of service" or "quality of service". There are five classes of

service, the highest being "Level 4" and providing complete flow and error

control procedures. The lowest class of service is called "Level 0" and this

only provides the basic functions required for connection establishment and

data transfer.

(v) Session Layer

The session layer, as its name implies, is responsible for coordinating a

communications session between nodes on a network. In other words, it

establishes a logical connection between two nodes and controls the entire

message interchange process that takes place between them during a

communications session.

(vi) Presentation Layer

The presentation layer is the one that takes incoming data, which arrives in a

common pseudo form and converts it to the form required by the application

layer in the local device. Similarly, the presentation layer takes data from its

local application layer and converts it into a common pseudo form for

transmission. The pseudo form for data is referred to as the "transfer" or

"concrete" syntax. The form in which data is presented and used within the

application layer is referred to as the "abstract data syntax". Two

communicating nodes may have different abstract data syntaxes.

(vii) Application Layer

The application layer is the one that provides direct support for applications

software. The software developer has access to a set of "primitives" that

transparently provide all the network services by interaction with the lower

layers. The applications layer allows a user to call up these primitives and

access information and files from remote nodes as though they were hardware

within the local device. For example, the capture of a file from a remote device,

on the network, is analogous to fetching a file from a local hard disk.


7.5 A Summary of Key Points Related to Networks

At this time it is appropriate to provide a summarised list of fundamental points

related to Local Area Networks:

(i) A Local Area Network is a collection of intelligent devices (nodes) that are all

interconnected via a star, bus or ring topology. In theory, any node should be

able to communicate with any other node.

(ii) The majority of commercially available networks are based upon the use of

serial communications techniques. Each node must have a conversion circuit

to transform data from the parallel form, used on the internal data bus, to the

serial form used on the network.

(iii) Many commercially available networks operate at very high bit rates (5 - 10

Mbits/sec) and therefore use synchronous serial communications, because of

the difficulties involved in using asynchronous communications at these

speeds.

(iv) In some networks all nodes have access to all information. It is therefore

important that each node be given an address, that each node is aware of its

address and that all messages contain a source and target address.

(v) Data transfer in networks can either be bit-oriented or character-oriented,

depending upon the communications protocol in use.

(vi) Networks generally use cyclic redundancy check polynomials for error

detection, but may also use Block Check Sums where data transfer rates are

lower and noise immunity is high.

(vii) All data that is transferred on a network must be in a packet (frame) form so

that addressing and error detection information can be included with the data.

The fundamental features of a data packet are shown below:

Direction of Transmission

CheckData

DataControl

Field

Source

Address

Target

Address


(viii) Within any one communication channel on the network, whenever two or more

nodes attempt to use the transmission medium simultaneously, a contention

occurs. Contentions can lead to data corruption and therefore a number of

contention schemes have been put into place. The form of these schemes

depends upon the nature and environment of the network, but the two most

common are the CSMA/CD and the Token Passing schemes.

(ix) The three basic network topologies are the star, bus and ring.

(x) The star network topology is composed of a number of point to point links

between peripheral nodes and a central, star node. The intelligent "star node" is

used to connect any one peripheral node to any other peripheral node. The star

node also resolves contentions for resources.

(xi) The Bus Network consists of a central trunk cable, which is generally a two

conductor (signal + return) or two optic fibre media. Nodes on the network all

have access to the same data and must selectively ignore or act upon data

packets, depending upon the addressing. Since bus networks do not have an

intelligent node to resolve contentions, each node must be capable of handling

contention situations.

(xii) The ring network topology is made up of a number of devices that are

connected via "point to point links" to form a physical ring. Messages are

generally sent around a ring from a source node to a destination node.

Messages usually only travel in one direction around the ring. Nodes on the

network all have access to the same data and must selectively ignore or act

upon data packets, depending upon the addressing. Ring networks do not have

an intelligent node to resolve contentions.

(xiii) The International Standards Organisation (ISO) has defined a 7 layer model for

Open Systems Interconnection (OSI) in data communications. The purpose of

the model is to break the communications process up into discrete modules so

that standards can be clearly defined for each module. The OSI model is to be

considered as a framework for communications standards.


7.6 Data Packet Forms on Networks - BSC, HDLC and

SDLC

We have already examined many aspects of the OSI model's physical layer.

The issues that are covered by this layer include network topology, communications

media, modulation techniques, contention schemes and so on. We shall now

examine some of the data link layer (OSI layer 2) protocols that are in common use

with various types of networks.

You will recall that the data link layer of the OSI model is concerned with

maintaining the integrity of data that is transmitted between nodes on a

communications network. There are a number of protocols that are commonly used

to implement data link control. It is important to examine these in some detail, since

the acronyms used in relation to the data link layer protocols are prevalent in

networking literature. Some of these protocols are character-oriented and some are

bit-oriented.

(i) Basic Mode (BSC) protocol

The Basic Mode protocol, defined by the ISO, is primarily designed as a

character-oriented protocol for synchronous serial transmission. It can also be

used to transfer bit-oriented data in what is referred to as "transparent mode".

Basic Mode is more commonly referred to by its IBM given names "BiSync" or

"Binary Synchronous Control" or "BSC".

Under the Basic Mode protocol, each block (packet) of information is preceded

by sending two, or more, synchronising characters, known as "SYN". After a

prolonged idle period, a receiver synchronises itself to a transmitter when it

detects the bit patterns of these synchronising characters. Since the BiSync

protocol is commonly used with IBM computers, characters are usually

represented in EBCDIC form. However the protocol also allows for ASCII and

Six Bit Transcode representation.

The BiSync protocol allows for single-block or multiple-block messages, with

or without headers (containing addressing information). This is because the

protocol can be used for both point to point and multidrop (network)

applications. A typical single-block message is shown in Figure 7.7. However,

in a multiple-block message, the data in Figure 7.7 would be terminated with

an "ETB" (End of Transmission Block) character, rather than an ETX

character, to signify that more packets are to follow.


BCC ETX Data STX Header SOH SYN SYN

Direction of Packetised Data Flow

SYN = Synchronous Idle Character

SOH = Start of Header Character

STX = Start of Text Character

ETX = End of Text Character

BCC = Block Check Character/s

Figure 7.7 - Typical Block (Packet) in BiSync Data Link Protocol

The BiSync protocol also defines the following packets:

• ENQ (Enquiry)

• ACK (Acknowledge)

• NAK (Negative Acknowledge)

• EOT (End of Transmission)

These consist only of the single communications characters plus the

synchronising characters (SYN).

The BiSync protocol is then essentially a synchronous ACK/NAK type

protocol, with a receiver performing the same block check calculation on data

as the transmitter. When a locally calculated block check character is the same

as the block check character received from a remote device, a receiver returns

an acknowledge packet - otherwise a negative acknowledge packet is returned

to the originator of the packet.

If the data transmitted in a BiSync block is bit-oriented rather than character-

oriented, then it is possible that some of the control characters (DLE, STX,

etc.) could coincidentally be contained within the data. The rule used in

BiSync (and many other protocols) is that if a "DLE" bit stream coincidentally

occurs in data then an additional DLE is inserted. A receiving device performs

the same check on the data field of an incoming block and strips out additional

DLEs where necessary.


The form of the check character/s in the BiSync protocol depends upon the

form of the data that is being transmitted. When BiSync is used to transfer

character-oriented data then a simple Block Check Character is used for error

detection and correction. If however, the protocol is used to transfer pure

binary data in, what is referred to as "transparent mode", then a 16 bit Cyclic

Redundancy Check is used in place of the BCC.

The primary advantage of BiSync is that it is relatively simple to implement in

terms of hardware and software. As a result of this, and its nexus with IBM, it

has therefore gained a broad acceptance in the communications world.

One of the shortcomings of the BiSync protocol is that it is half-duplex in its

operation. Since many network installations now provide cables with sufficient

bandwidth for full-duplex transmission, BiSync effectively "wastes" the

bandwidth that is provided for the return channel.

(ii) HDLC / SDLC

The International Standards Organisation has defined the "High Level Data

Link Control (HDLC)", which is a bit-oriented, synchronous protocol. It is

almost (but not exactly) identical to IBM's Synchronous Data Link Control or

SDLC. Like BiSync, HDLC is a protocol for the data link layer of the ISO

model.

The HDLC protocol allows for full-duplex communications on either a simple

point to point link or a multidrop network arrangement. Under the HDLC

protocol, data can only be transmitted within a packet defined by a standard

format. In HDLC parlance, a packet is more commonly referred to as a

"frame". The structure of the bit-oriented HDLC frame is shown in Figure 7.8.

EndFlag

CRC CheckInformation(Data) Field

Control

FieldAddress

Field

StartFlag

8 Bits 16 Bits 0 to N Bits 8 Bits 8 Bits 8 Bits

Direction of Data Flow

Figure 7.8 - HDLC Frame Format


The start and end flags for a HDLC frame are composed of unique bit patterns

that are used to synchronise the receiving device. The integrity of each frame is

checked through a Frame Check Sequence (FCS) which is a Cyclic

Redundancy Check polynomial. The generator polynomial for the HDLC

protocol is given by:

x16 + x12 + x5 + x0

An HDLC frame can be one of three types (classes):

• Unnumbered

• Information

• Supervisory

The frame class is defined by the bit pattern contained within the control field

of the HDLC frame. Unnumbered HDLC frames are used for functions such as

link set up and disconnect (analogous to Enquiry and Acknowledge in

character-oriented protocols). Information frames, as the name implies, are the

ones that carry actual data during an information transfer session. Supervisory

frames are used for flow control and error checking purposes.

There are two modes of operation for an HDLC link. These are:

• Unbalanced Normal Response Mode (NRM)

• Asynchronous Balanced Mode (ABM)

The mode in which the link is to operate is defined during the initial set up of

the link.

In NRM links, there is generally only one master (primary) station and a

number of slave (secondary) stations. Secondary stations may only transmit

when instructed to do so by the master station. This arrangement could

correspond to a "mainframe to many terminals" arrangement. In ABM links,

all stations have an equal ranking and therefore act in both primary and

secondary roles. The ABM mode is most commonly used in point to point

links.

A key feature of the HDLC protocol is the addressing of frames for a

networked environment. Addressing is predominantly used for the NRM mode

of link operation. Each secondary node on an NRM network can be given a

unique address. When a primary node transmits a frame to a secondary node,

then the address of the target node is placed into the address field of the frame.


It is also possible to provide a common address for a number of secondary

nodes, so that all the nodes within the common address group receive a

message from a primary node. This is referred to as "group addressing" and

individual groups of secondary nodes can be specified. When the address field

of an HDLC frame contains all ones, then the link is said to be in a "broadcast

mode" and all secondary devices receive the broadcast frame from the primary

node. An address field with all ones is referred to as a "broadcast address".

In principle, the HDLC link protocol is not unlike any other protocol and

contains the normal transaction phases including:

• link establishment

• packet transmission

• error check transmission

• acknowledgment or negative acknowledgment of packets

• termination of transmission.

The HDLC protocol is however, relatively sophisticated because the control

field not only contains link establishment and supervisory functions, but also

frame sequencing information. The HDLC sequencing system allows for a

number of frames to be transmitted to a target node without waiting for the

target node to acknowledge each individual frame. A receiving device can

therefore track the order of incoming frames and correct for those frames that

arrive out of sequence.


7.7 PSTN / PSDN / CSDN / ISDN

Up until now we have only examined networking within a local area, be it in a

single building or single factory. However, it is important from a communications

point of view to be aware of the networks that link computer-based devices across

the world. These Wide Area Networks (WANs) clearly have important

consequences for large manufacturing and financial organisations where international

data transfers need to occur on a regular basis.

Initially data communication between computer systems, separated by large

distances, was carried out through the normal lines on the Public Switched Telephone

Network (PSTN). Computers transmitted data to one another on these public

telephone lines via modems. Unfortunately because of the channel bandwidths on

public lines and the switching delays, data transfer rates were generally low

(normally less than 4800 bps) and the timed charges imposed by the telephone

companies were high. Many large computer organisations and financial institutions

therefore chose to introduce their own private networks by leasing dedicated public

lines from telephone companies and providing their own exchanges (switching

nodes). These allowed companies to decrease the switching delays, maximise

transmission bandwidth and therefore transmission speed.

Private data networks functioned well within a single organisation or within a

single network, but problems arose when one organisation wanted to transfer its

computer data to another organisation that was on a different, private network. It

became evident that a public, wide area data transfer system, analogous to the

switched telephone network, had to be introduced. This system is referred to as a

Public Data Network or PDN. Public Data Networks are generally established and

operated by a national administrative body in order to maintain standards. The

traditional, switched telephone network is still widely used for data communications,

and therefore, it too is a PDN.

There are essentially two different forms of Public Data Networks. These are

the "Packet Switched Data Networks" (PSDNs) and the "Circuit Switched Data

Networks" (CSDNs). The standards that are used in conjunction with both these

types of Public Data Networks are those which occupy the "Network Layer" of the

OSI 7-Layer model. A circuit switched network is one in which a group of

intermediate exchanges set up a direct physical (electric circuit) connection between

a transmitting device and a receiving device by short-circuiting appropriate incoming

lines to outgoing lines. The circuit remains connected for the duration of a

transaction (call). In other words, in an ideal environment, the transmitter and

receiver are linked by a lossless cable. This is shown schematically in Figure 7.9.


Exchange

Exchange Exchange

Exchange Exchange

Exchange

Device A Device B

Users

CSDN

Circuit

Figure 7.9 - Circuit Switched Data Network (CSDN) Operation

The PSTN is a good example of a circuit switched network, where exchanges

perform either mechanical or electrical switching of transmission lines.

In a packet switched data network, all messages (regardless of length) are

divided into discrete units (packets), which are transmitted from a source station to a

destination through intermediate exchanges. Each packet contains a source and

target address that intermediate exchanges use for routing the packet. A transmitter

sends a packet to its local exchange. The local exchange reads the destination

address and uses its "routing directory" to determine the next exchange to which the

packet must be sent. Each exchange is said to perform a "packet store and forward"

operation. Unlike the CSDN there is no direct, physical connection or

communication between a transmitter and receiver - only between consecutive

exchanges. This system is shown schematically in Figure 7.10.

Many transmitters can access the same exchange and hence the exchange will

not necessarily forward packets in the consecutive order in which they are received

from any one transmitter. The data travelling from one exchange to another is

generally a mixture of packets from different transmitters. The maximum length of

any one packet is restricted by the network protocol and hence no single transmitter

can block the network with long messages.


Device A Device B

Users

PSDN

Exchange

Exchange

Exchange Exchange

Exchange

Exchange

= Data Packet

Figure 7.10 - Packet Switched Data Network Operation

When packets are transmitted as individual entities, as described above, the

packet switched network is said to be operating in a "datagram" mode. However, it is

also possible for the exchanges to set up packet transfer so that two communicating

devices believe they are talking to one another through a physical circuit. This is

referred to as a "virtual call" or "virtual circuit" mode of operation. Although the two

user devices are never directly communicating, the exchanges make it appear as

though this was the case.

The widely adopted standard for the format of a packet on a packet switched

network is the CCITT X.25 standard. You will come across this standard regularly

when reading material related to Packet Switched Wide Area Networks. X.25

defines the rules for connecting terminals to a packet switched exchange system, the

format of the network packet header (containing addressing information) and the data

section of the packet. The data-link layer of the OSI model treats the total X.25

packet as the data segment for its frame format. For example, the X.25 packet can

form the data segment for the HDLC data link frame. This is shown in Figure 7.11.

The very nature of a packet switched data network indicates that error detection

and correction on each packet must be performed after every transfer segment from

one exchange to another. This error checking and correction is performed over and

above any error checking carried out by the data link layer. In the circuit switched

system, the exchanges act only as switches and so error detection and correction are

performed by the two communicating users only, through the data link layer.


EndFlag

CRC CheckInformation(Data) Field

Control

Field

Address

Field

StartFlag

8 Bits 16 Bits 0 to N Bits 8 Bits 8 Bits 8 Bits


(HDLC Frame)

Packet

HeaderData

Data Link Layer

Network Layer

(X.25 Packet)

Figure 7.11 - Interaction of Network and Data Link Layers for Packet Switched

Networks

While the data-oriented CSDN and PSDN serve the needs of computer users

extremely well, the Public Switched Telephone Network is also regaining acceptance

as a viable form of computer network. This has been largely due to the replacement

of mechanical exchanges with digital exchanges that dramatically decrease call set-

up times and provide a digital interface to all users. Once a total digital exchange

system becomes fully operational on an international basis, there are many benefits to

be attained, in a system that combines voice and data communications. The

combined system is referred to as an Integrated Services Digital Network or ISDN.

The digital interface to ISDN allows users to transfer data over the links, without the

use of modems, at moderate bit rates (64 kbps) which were not available with

traditional PSTNs.


7.8 The Role of Networking in Manufacturing

We have now examined some of the basic concepts of computer networking,

but how do these complex structures fit into our perceptions of the manufacturing

industry? Despite the fact that computer-based systems have been an integral part of

manufacturing since the 1960s, networks sit very uncomfortably with manufacturing

organisations. The reason for this is that the focus of engineering within

manufacturing has changed dramatically with the introduction of specialised

computer-controlled production equipment. The availability of low-cost

microprocessors has led to a proliferation of intelligent, electronic control and

feedback systems for mechanical devices. Until recently, there have been few

professionals who have been able to successfully cope with the heavy demands of

unifying these two, complex engineering disciplines.

The advent of intelligent manufacturing equipment has however caused

professionals in industry to re-evaluate traditional manufacturing methods and

consider the concept of Computer Integrated Manufacture (CIM). CIM is little more

than the rationalisation and automation of the collection and distribution of

computer-based manufacturing data. One of the major benefits of CIM is that the

efficiency of an organisation can be readily monitored and its response time to

changing demands minimised. In terms of computer networking, CIM can be

visualised through the idealistic, "plug-in-compatible" network shown in Figure 7.12.

It would appear that the introduction of computer controlled equipment is

therefore an ideal catalyst for CIM, but in the real world, CIM is far easier said than

realised. On the other hand, if it was possible to simply plug each piece of computer

controlled manufacturing equipment into a standard Local Area Network ("plug-in

compatibility"), then there would at least be a sound basis for integrating and

utilising manufacturing data so that we could ultimately optimise plant efficiency.

However, we now know that the concept of "plug-in compatibility" is difficult to

achieve because of the enormous diversity of computer control architectures and

equally diverse needs within the manufacturing environment.


ManufacturingManagementComputer

CAD SystemPayrollComputer

ProductionCell Controller

ProductionLine Controller

AssemblyCell Controller

CNCMachine 1

Robot 1CNCMachine N

Local Area Network

Figure 7.12 - Achieving CIM Through "Plug-in Compatible" Networks

In this chapter we have examined just a few of the many standards that can be

used to fill the framework of the OSI model. As we have seen, there is no single,

optimal solution to the networking problem. The network performance requirements

of the office environment and the factory environment, even within a single

manufacturing organisation, can be so different, that it is often impractical to

implement the single network solution of Figure 7.12.

During the early 1980s, the problems of interfacing a diverse range of industrial

controllers to a single network were so large that the original "nebulous" concept of

CIM became little more than a pipe-dream. The ugly reality of CIM often began to

resemble the ad-hoc sort of networking structure of Figure 7.13.

1980s CIM became a jumbled mixture of commercial, proprietary networks in

the office environment, proprietary RS-232 ACK/NAK protocols between CAD and

CAM and proprietary bus type networks between industrial control systems. Whilst

the ideal network of Figure 7.12 was not feasible in the 1980s, it was also apparent

that the proprietary systems were totally unacceptable for the long term.


At best, the proprietary networks in the factory provided interfacing units for

only a limited range of industrial controllers (made by the larger manufacturers of

automation control equipment). Smaller manufacturers of automation controls just

didn't fit into the CIM picture and nor could they afford to, since there was no single,

standard for industrial networking. The cost of an original equipment producer

manufacturing interfaces to the entire range of differing proprietary networks is

prohibitive.

Manufacturing

Management

ComputerCAD System

Payroll

Computer

CNC Machine 1 Robot CNC Machine 2

Cell

Controller

Proprietary LAN 2

Proprietary LAN 1

RS-232 Links with Individual

Protocols & Hand Shaking

Figure 7.13 - Realities of 1980s CIM

To make matters even worse, bridging between different, proprietary networks

is even more difficult than interfacing any single device to a network. To emphasise

the enormity of the total networking problem, it is perhaps best to recall how a large

manufacturing company viewed the situation from their own perspective in the

1980s.


Mike Kaminsky, of the General Motors' MAP task force, which was

established to standardise industrial communications, made the following

observation of the networking problem (as it existed at General Motors) in a 1986

issue of the IEEE Spectrum magazine:

"Only 15 percent of the 40000 programmable tools, instruments, controls

and systems already installed at General Motors facilities are able to

communicate with one another. When such communication does occur, it

is costly, accounting for up to 50 percent of the total expense of

automation because of the wiring and the custom hardware and software

interfaces needed".

We shall examine the role of proprietary networks and major attempts at

industrial networking standards (such as MAP) in the next chapter.

247

Chapter 8

Local Area Networks - Applications And

Standards

A Summary...

Interfacing to networks. Standards activities in Local Area Networks - the IEEE

"802" Committee. The Ethernet network. MAP and TOP networks. File Server

systems.


♦ You would like to learn about the most common LAN systems

♦ You would like to learn about file-servers

♦ You need to know how emerging networking standards will affect industry

plans for integration


8.1 Interfacing Computers to Networks

Interfacing the internal computer data bus structure to an external network, that

is based upon the OSI 7 layer model, is a complex task. At the most basic level, the

interface to the network generally needs to perform parallel/serial and serial/parallel

conversion. However an interface may additionally need to perform signal

modulation and demodulation, contention resolution, data framing, error checking

and correction and other sundry functions. The role of the interface is shown


Internal Data Bus

Computer Device 1

Network Interface

Internal Data Bus

Computer Device N

Network Interface

Data Line

Common Line

DataFlow

Figure 8.1 - Interfacing a Data Bus to a Network Bus

The exact role of the network interface depends as much on the interaction with

its local computer as on the standards chosen for the OSI model. In other words, the

network interface may fulfil some or all of the 7 functional layers which are needed

to connect a computer to an OSI network. All the functional layers that are not

provided by the network interface must be performed by the computer system in

software.

Local Area Networks - Applications and Standards 249

Provided that each computer, its software and interface card are all matched,

then the distribution of OSI layer functions (between hardware and software) is

transparent to the network. This is shown schematically in Figure 8.2.

7 Application

6 Presentation

5 Session

4 Transport

3 Network

2 Data Link

1 Physical

7 Application

6 Presentation

5 Session

4 Transport

3 Network

2 Data Link

1 Physical

Computer 1

Interface 1

Computer NSoftware

Interface NHardware

Software

Hardware

Data Line

Common Line

Network Bus

Figure 8.2 - OSI Networking of Devices using Different Interfacing Structures

After examining Figure 8.2, one may be tempted to ask why all 7 layers of the

OSI model are not always implemented "in hardware" on a network interface card.

In other words, why should the computer system be burdened with any of the

networking layer functions? In theory this would appear to be the sensible solution

and in some cases it is actually achieved. However, the complexity of 7 layer

protocols may be such that "complete" interfaces can only be implemented using

specialised VLSI circuitry. The costs involved in circuit development, coupled with

the enormous range of available networks and protocols, have tended to discourage

interface manufacturers from providing 7-layer hardware solutions. It is therefore

common to find interfaces which provide only the first two layers in hardware. The

upper layers are often supplied to users in the form of pre-compiled software libraries

which can be linked into end-user application programs.


Despite the wide range of network protocols, there is generally a high degree of

commonality between the lower layers (1 and 2) of the OSI model. For example,

HDLC is a very common specification for the data link layer of a communications

protocol - it is used within a number of different networks. The CSMA/CD

contention scheme is another specification that commonly forms part of the physical

layer of a number of different networks. There are also a number of modulation and

demodulation techniques that are widely used within the physical layer. It is

therefore commercially prudent for Original Equipment Manufacturers (OEMs) to

implement only the lower layers of a network interface in hardware. These lower

levels of the interfacing unit are shown schematically in Figure 8.3.

Data Line

Common Line

Serial Data Bus (Network)

Data Link Control

State Machine

Network Access

Control

Modulation /

Demodulation

Parallel/Serial

Conversion

Parallel Internal Data Bus

Computer

NetworkInterface

Unit

Figure 8.3 - Implementing the Lower Levels of a Network Interface in Hardware


It should be clear from Figure 8.3 that a fundamental requirement of the

interfacing hardware is that it must be tailored to each, different computer bus

architecture. In the case of general-purpose computers, internal bus architectures

have evolved into a manageable number of common systems, so that the problem of

diversity is not as great as one might imagine. A limited range of common bus

structures are also becoming well accepted in the industrial environment.

However, once we go above the network layer of the OSI model, we tend to

find that the specifications for each layer are as diverse as the networks themselves.

Additionally, we find that the role of the higher layers is inherently more complex

than that of the lower layers. These factors have, in the past, provided good reasons

for implementing the upper layers entirely in software on the computers themselves.

The distribution of functions between a network interface and a computer

sounds much simpler in theory than it turns out to be in practice - particularly in the

industrial environment. The key reason for this is "programmability". Many

industrial control systems (most notably CNCs) are marketed in a "closed

architecture" form. Such systems are normally only programmable in terms of

machine hardware and not for normal data processing and Input/Output functions.

Therefore, many industrial systems cannot be "software-adapted" to provide the

upper layer functionality needed for OSI communications. Since it is often equally

impractical for interface manufacturers to provide the equivalent network

functionality in hardware, the net result has been that a substantial proportion of

industrial controllers have been unable to connect to a factory bus network. As a

result, star networks composed of point to point RS-232 links (each with their own

protocol) have remained in place for a good deal longer than has been desirable.


8.2 Network Performance - Transfer Rates

Now that we have examined some of the basics of connecting to networks, it is

appropriate to examine some of the key issues related to the performance of the

LANs themselves. We will use the typical bus network of Figure 8.4 as the basis of

our discussion.

Device 1

Network

InterfaceUnit

Device 2

Network

InterfaceUnit

Device N

Network

InterfaceUnit

...

A B

Figure 8.4 - A Bus Type Communications Network

The most commonly quoted Figure for data communications performance is

the "link speed" in terms of the bit-rate. This Figure can be somewhat misleading if

one does not fully appreciate its limited scope. In terms of Figure 8.4, the link speed

defines the number of bits per second which flow along the network bus (between A

and B say) when data is actually flowing.

In itself, the link speed does not define the average rate at which messages are

actually transferred between two network nodes. In other words, the time taken to

transfer a file (say) from one node to another is NOT equal to:

file size (in bits)

link speed

There are clearly a number of other factors which will determine the rate at

which a message can actually be transferred from one device to another.


The appropriate quantity to use in defining the performance of a network, is

called the "Link Response Time" (LRT). This quantifies the amount of time taken to

transfer a meaningful message from one network node to another and to receive an

acknowledgment message. The factors which influence the LRT include:

• Link speed

• Time taken for a node to access the network medium (contention)

• Delays involved in each device preparing the data into suitable packets or

frames,

• Size of network data frames (including overheads such as error checking

bits, addressing bits, etc.)

• Number of times a frame has to be re-transmitted in the event that a

transmission error has been detected

• Time taken for a receiving node to send an acknowledgment message

• Signal transfer time through the modem in a network interface unit

• the number of frames in each message.

Many of these factors are governed by the protocols that are in use on the network.

In the final analysis, the delays caused by contention for use of the network

medium could have the greatest effect on the Link Response Time. This is especially

true in the case of the non-deterministic CSMA/CD scheme, where repeated

collisions during a busy period could seriously affect the time taken for the transfer

of a single message. Moreover, the fact that the CSMA/CD system is non-

deterministic makes it difficult to make meaningful calculations on the LRT. On the

other hand, in token-passing contention schemes, the maximum delay in accessing

the network medium is known and therefore a meaningful value for the LRT can be

determined.

The quality of the transmission medium is another factor which will affect the

performance of the network. A link which is affected by electro-magnetic

interference will require frequent re-transmission of erroneous data frames, thus

degrading its response time. The overheads involved in "framing" or "packetising"

data for transmission over a network can also affect the Link Response Time. If the

actual data field of a transmitted frame is small, then the framing bits (including error

checking) can constitute the major proportion of the total number of bits transmitted

in a frame. This factor is dependent upon the data link level protocol in use and has

an influence on efficiency.


Over and above all of these factors, we need to consider the "device latency" of

the network nodes themselves. In other words, the amount of time that it takes each

node to gather data (say from disk storage) and assemble it into frames for

transmission. Similarly, the amount of time needed to disassemble frames and

process incoming data may also be of significance.

The diagram in Figure 8.5 shows some of the time delays involved in

transmitting a frame from one node to another. We can derive simple formulae from

diagrams such as these, which will allow us to sensibly determine the Link Response

Time (and performance) of a computer network.

Device 1

MediaAccess

Modem

Tdl

Tma

Tmt

Device 2

MediaAccess

Modem Tmt

Tdl

Sf

Ls

Tdl

= Time delay due to device latency

Tma

= Time taken to access transmission medium

Tmt

= Modem transit delay

Sf

= Frame size in bits

Ls

= Link speed in bits per second

Figure 8.5 - Delays Involved in Transmitting Node to Node


Using information, such as that shown in Figure 8.5, we can attempt to assess

the Link Response Time (LRT) of a particular network. In the assessment that

follows, we make the assumption that the two communicating nodes are identical and

generate the same time delays. In general, this will not be the case and we would

need to substitute different parameters for each device.

As a starting point, we can see that the time taken to transmit a frame, of size St

from one device to another is given by:

Ttrans

Tdl

Tma

Tmt

St

Ls

Tmt

Tdl

Tma

Tdl

Tmt

St

Ls

= + + + + +

= + ⋅ + ⋅ +2 2

Similarly, the time taken for the receiving node to transmit an acknowledgment (or

negative acknowledgment) frame of size Sa is:

Tack

Tma

Tdl

Tmt

Sa

Ls

= + ⋅ + ⋅ +2 2

The time taken for the complete transmission and acknowledgment sequence is then:

Tseq

Ttrans

Tack

= +

If erroneous frames are detected, then Nt sequences may be required to successfully

send one frame:

Tframe

Nt

Tseq

= ⋅


A complete message may be comprised of Nf frames and therefore the Link

Response Time is:

LRT Nf

Nt

Tseq

seq

St

Sa

Ls

Tdl

Tmt

Tma

= ⋅ ⋅

=

+

+ ⋅ + ⋅ + ⋅

where

T 4 4 2

Once formulae, such as those above, are established for a specific network, it is

possible to make assessments on the realistic (best and worst) times required for

transferring files and other information through that network.


8.3 Networks Standards Activities - IEEE 802 Committee

We have already seen that there are many networking standards available to

fulfil each layer of the Open Systems Interconnection model. Unfortunately, as fate

would have it, there are also many, different organisations which are responsible for

establishing these standards. Some of the standards for data communications are

established by special interest groups and professional engineering bodies, whilst

others are established by federal governments in different countries.

Many standards organisations choose to adopt standards defined by other

standards organisations, particularly where the cost of establishing complex standards

is very high. This is true in many aspects of data communications and so we have a

number of standards organisations specifying identical standards. However, each

standards body likes to classify standards according to its own coding system. The

net result is that it is often difficult to determine which standards are identical in

structure and different in name only. A typical example of this is the RS-232C

standard, which is also known by its "V.24" nomenclature.

We will now examine a few of the major standards organisations which

develop and issue standards related to data communications.

On a global basis, the major standards body is the International Standards

Organisation or ISO. This is made up of representatives from the national standards

bodies of participating countries. Two of the most notable members of the ISO

include the American National Standards Institute (ANSI) and the British Standards

Institute (BSI). Like many standards bodies, the ISO is divided into a number of

technical committees, which produce standards for a diverse range of entities. The

ISO committee which is responsible for information processing systems is known as

Technical Committee 97 or TC97. As previously noted, the ISO was responsible for

the development of the 7 Layer, Open Systems Interconnection model (which is

referred to as ISO82). The ISO is also responsible for the establishment of protocol

standards for layers within the OSI model.

The Comité Consultatif Internationale de Telegraphie et Telephonie (CCITT) is

another international standards body concerned with data communications. The

major role of the CCITT is in the establishment of standards related to public

communications networks (rather than Local Area Networks). In particular, CCITT

is involved in standards for Public Switched Telephone Networks (PSTN) and

Integrated Services Digital Networks (ISDN).


At a federal level, the United States has a number of major standards bodies in

addition to the American National Standards Institute. These include the National

Bureau of Standards (NBS), which provides standards for information processing

equipment purchased by the US government, the Electronics Industries Association

(EIA) and the Institute of Electrical and Electronic Engineers (IEEE). The IEEE is a

professional engineering body and the EIA is a special interest group established by

American electronics organisations. Both these national groups have made

significant contributions to the development of standards for Local Area Networks.

These standards are often adopted by ANSI and the NBS.

Finally, one European version of the EIA is called the European Computer

Manufacturers Association (ECMA). Another special interest group, the ECMA is

primarily comprised of members who manufacture computers within Europe.

The data communications standards which are adopted in the majority of

countries around the world are based upon a combination of those laid down by:

•••• ANSI

•••• BSI

•••• CCITT

•••• ECMA

•••• EIA

•••• IEEE

•••• ISO

•••• NBS.

A large number of local standards are little more than re-titled versions of standards

generated by the above-named bodies.

As we have already noted, Local Area Networks and interfacing are vital to

manufacturing data communications. Since a great deal of standardisation work has

been carried out for the two, lower layers of the OSI model, it is worthwhile to

examine these standards a little more closely. The IEEE committee, referred to as the

"802 Committee" was established to work towards the development of LAN

standards. Of particular interest are those standards which describe the first

(physical) and second (data link) layers of the OSI model.

To begin with, the IEEE has defined the 802.1 standard, which is referred to as

the Higher Layer Interface Standard or "HILI". This standard is used to embrace

those specifications which are chosen for the physical and data link layers of the OSI

model and ensure that their development leads to compatibility with the upper 5

layers.


As far as the physical layer of the OSI model is concerned, the IEEE has

defined network topologies and contention schemes with which we are already

familiar. That is:

• CSMA/CD Bus (IEEE 802.3)

• Token Passing Bus (IEEE 802.4)

• Token Ring (IEEE 802.5)

These standards define the network topology, contention schemes,

communications media, allowable modulation types, physical connectors and plugs,

etc.

Up until now we have only looked at the data link layer of the OSI model as a

single unit. As it turns out, the data link layer can actually be broken down into two

sub-layers. These sub-layers are for:

• Logical Link Control

• Media Access Control.

The Logical Link Control sub-layer (abbreviated LLC) is the one which is

actually responsible for framing data bits and maintaining data integrity through the

use of Cyclic Redundancy Checks, etc. It is this sub-layer which is described by

protocols such as HDLC, BiSync, etc.

The IEEE has defined another standard known as IEEE 802.2 to fulfil the

requirements for the Logical Link Control sub-layer. This standard provides for two

different optional modes of operation for:

• Connectionless Networks

• Connection-Oriented Networks.

In the connectionless (packet-switched) network mode, the data link layer of

the OSI model assumes that the higher layers will provide error control, flow control

and sequencing (refer to section 7.7). This connectionless mode can also be used in

situations where data integrity is not vital. The connectionless mode of operation is

essentially a "lazy" mode of framing data. It minimises demands on hardware in

situations where error checking is better performed by other layers.


The connection-oriented mode of the IEEE 802.2 protocol is based upon the

HDLC protocol, and generates very similar data frames that contain Cyclic

Redundancy Checks (Frame Check Sequences), sequencing information, etc. As its

name implies, the system is intended for connection-oriented networks (circuit-

switched systems) where the upper layers of the OSI model do not provide error

checking of their own. It is also used when a high degree of error checking is

required. This mode of operation clearly requires a more sophisticated piece of

interfacing hardware in order to function.

As its name implies, the Media Access Control sub-layer (abbreviated MAC) is

the one which is responsible for resolving contentions for use of the network media.

The specification for the OSI physical layer will determine the type of contention

scheme in use and therefore the MAC sub-layer must be matched to that

specification. We now find (seemingly contrary to the original aims of the OSI

model) that the IEEE 802.3, 802.4 and 802.5 standards effectively cover the entire

physical layer plus the MAC sub-layer of the data link layer. As it turns out, despite

the modularised intentions of the "layer" system, the lower three layers of the OSI

model are interdependent.

The structure of the major IEEE standards and their relationship to the OSI

model is shown in Figure 8.6. Another commonly cited IEEE communications

standard is IEEE 802.6. However, this is not shown in the diagram because the

standard governs Metropolitan Area Networks and is outside the scope of our

discussions.

DataLinkLayer

Physical Layer

Logical LinkControl

Media AccessControl

IEEE802.3

Bus

IEEE802.4TokenBus

IEEE802.5TokenRing

IEEE 802.2Logical Link Control (LLC)

IEEE 802.1 - HILI

Upper Layers of OSI Model

CSMA/CD

Figure 8.6 - IEEE 802 Networking Standards


It can be seen from our discussion of IEEE 802.2, that even when we have a

single standard, such as this, there is still scope for a number of different options

within the specification. Another example is the IEEE 802.4 standard, which

specifies a number of different, optional cable types and modulation schemes. We

must now note, that in order to make devices communicate with one another on a

network, it is not sufficient for them to both simply adhere to the same layer standard

- they must also be configured to the same options within each standard specification.

We will look at IEEE specifications a little more closely as we progress

through this chapter and see how they are applied within emerging networking

standards.


8.4 Bridges, Routers and Gateways

We have thus far noted well that standardisation of communications networks

has been difficult to realise because of an early lack of support from major computer

and control systems manufacturers. We have also noted that differing environmental

requirements make it difficult to have one network standard because no single,

configuration is optimal for all environments. We therefore need to accept that, in

the foreseeable future, we will have the prospect of trying to make different networks

communicate with one another.

It is a difficult enough task to make a number of devices meaningfully

communicate with one another on a single network. It is even more difficult to make

devices which are attached to totally different networks communicate with one

another. Schematically, the dilemma is shown in Figure 8.7.

Device A Device B Device C Device D

Device W Device X Device Y Device Z

Inter-Network

Interface

Local Area Network 2

Local Area Network 1

Figure 8.7 - Interconnecting Different Networks

If we assume that networks 1 and 2 of Figure 8.7 are totally different in terms

of framing, contention, modulation, etc., then we can see the enormity of the

problems for the inter-network interface device. A typical example might be where

Device B (network 1) wishes to communicate with Device Y (network 2). The inter-

network device must simultaneously satisfy the physical requirements and access

requirements of both networks, whilst performing a translation of data frames from

one form to another. If the two networks are OSI based, then at least there is some

scope for breaking this problem down into layers of compatibility and functionality.


There are three, commonly used devices which perform the role of the inter-

network interface between OSI systems. These are referred to as:

• Gateways

• Routers

• Bridges.

In physical terms all these devices should be considered as computers with

varying degrees of sophistication. The most complex of these systems is the

Gateway, which is designed to translate all seven layers from the protocol of one

network to the seven layers required by another network. This is shown


User A User X

7

6

5

4

3

2

1

7'

6'

5'

4'

3'

2'

1'

7'

6'

5'

4'

3'

2'

1'

7

6

5

4

3

2

1

Gateway

Node on

Network 1

Node on

Network 2

Figure 8.8 - A Gateway Between Two Different OSI Networks

The upper layers of an OSI network are relatively complex (particularly in the

applications layer) and therefore the amount of time required for a Gateway computer

to perform a protocol translation may be significant. In addition to the inter-network

time delays involved with Gateways, their cost is substantial and clearly they are a

"last alternative" solution for communication between totally dissimilar networks.


If the upper layers (4, 5, 6 and 7) of two, OSI networks are the same, then it is

possible to use a "Router" to perform protocol translation for the lower 3 layers.

Routers can be used to connect a number of such networks together at a common

point as shown in Figure 8.9. Packets are "routed" from one network to another

based upon the destination address specified within the network layer (3) of the

packet.

1

2

3

1'

2'

3'

1"

2"

3"

Network 1

Network 2

Network 3

Router

Figure 8.9 - Routing Networks at a Common Point

The OSI networks which are easiest to interconnect are those which are

completely identical or those which differ only in the lower one or two layers. In

these situations a Bridge can be used to interconnect the systems as shown


We now appreciate that whilst in theory it may be desirable to have all devices

connected to a common network, in reality this is unlikely to occur. We realise that

environmental and performance features are the major reasons for using different

network philosophies (leaving aside vendor marketing strategies). We also

appreciate that the easiest way to interconnect networks is to ensure that the networks

are as similar as possible.

The physical and data link layers of the OSI model are the ones which are most

closely related to environmental factors. As a corollary, it is therefore logical to

attempt to achieve common, upper layer standards for the OSI model, whilst varying

the lower 2 layers to suit differing user requirements. This is in fact the way in which

some organisations have approached the problem of industrial network

standardisation.


User A User X

7

6

5

4

3

2

1

7

6

5

4

3

2'

1'

2'

1'

2

1

Node onNetwork 1

Node onNetwork 2

Bridge Acting as Nodeon Networks 1 and 2

Network 2Network 1

Figure 8.10 - Bridging Similar OSI Networks


8.5 The Ethernet System

We now move on to examine one of the earliest, and most commonly used,

specifications applied in Local Area Networking. The Ethernet system, which was

developed by Xerox, in conjunction with Intel and the Digital Equipment

Corporation, came into being as an experimental system in the early 1970s.

Ethernet is very frequently and very incorrectly referred to as a Local Area

Network. The Ethernet system defines only the lowest, two layers of the OSI model

and hence it does not represent a network in itself. In other words, one can't simply

buy an "Ethernet Network" and expect to have applications support routines

available. The Ethernet specification is however used as the foundation (backbone)

for a range of commercial networks that provide the additional, upper five layers of

OSI model functionality needed to support communications.

The Ethernet specification for the physical and data link layers of the OSI

model is based upon a baseband, CSMA/CD bus. Referring to the IEEE terminology

introduced in section 8.3, we can say that Ethernet effectively defines the physical

layer and the data link layer of the OSI model, although emphasis is usually given to

its Media Access Control. It should also be noted that the development of the IEEE

802.3 specification, for baseband communications on a bus network, was based upon

the Ethernet specification and not vice-versa (as one may be tempted to assume).

This was essentially done in the early 1980s as an IEEE response to the then growing

acceptance of Ethernet as a defacto standard.

Ethernet was designed to provide a bus network of 2500 metres maximum

length, established from cable segments of 500 metres maximum length. The cable

segments themselves are joined together with "repeaters" which do not interfere with

the CSMA/CD contention on the network. Ethernet allows for data transmission

rates of up to 10 Mbits per second, with as many as 1024 network nodes. The system

is shown schematically in Figure 8.11.

Although the Ethernet system was designed for baseband transmission over

coaxial cable, the CSMA/CD contention scheme will function over any multi-access

broadcasting medium. Radio, twisted-pair and optic fibre systems have all been

successfully used in conjunction with the Ethernet CSMA/CD system.


EthernetInterface

Third-Party

Software

Network

Computer

EthernetInterface

Third-Party

Software

Network

Computer

EthernetInterface

Third-Party

Software

Network

Computer

Repeater Repeater

500 m

10 Mbps

2 OSI Layers

5 OSI Layers

Figure 8.11 - Ethernet as the Basis for Networking

The actual Ethernet data frame is shown in Figure 8.12. It is not unlike the

HDLC frame in its form. It consists of a 7 byte preamble, followed by a single byte

Starting Frame Delimiter (SFD), two or six byte Destination and Source Addresses

(DA and SA), data length specification field, data and padding bits and finally a

Frame Check Sequence (FCS). The length of the preamble is designed to allow for

receiver synchronisation and consists of alternating 1s and 0s. The padding bits are

added if there are insufficient bytes in the data (provided by the LLC) for the protocol

to operate.

PreambleSFDDASALengthLLC Sub-Layer

Data FieldPADFCS


Figure 8.12 - The Ethernet Data Frame

The Ethernet system is relatively simple and it functions extremely well in the

office environment. This is why it is in such widespread use. However, it has already

been noted that the CSMA/CD system is "non-deterministic" in nature and as such

may be undesirable within an industrial environment because message delays cannot

be predicted with any certainty.


Another serious shortcoming of the 802.3 standard is the length limitation,

brought about by the maximum round-trip propagation delay permissible for collision

detection to operate. This restricts the length of the CSMA/CD system. Whilst this

is generally an acceptable restriction in a typical office environment, it can present

problems in large industrial sites.

In addition to the above factors, we now also appreciate that industrial

environments will ultimately need the multi-channel, multi-function facilities of

broadband communication systems in the coming years. These factors have led

many people to believe that single-channel, baseband systems, such as Ethernet, are

not suitable for long term industrial networking strategies. However, as we have

seen with RS-232, suitability has never been a major criterion for the proliferation of

data communications standards. It may well be that the existing user acceptance of

Ethernet based networks may ultimately lead to its adoption and modification for

industrial applications.


8.6 The General Motors / Boeing MAP & TOP Networks

The General Motors (GM) Corporation was one of the first end-users to launch

a major international drive for standardisation of industrial data communications,

based upon the OSI network model. The GM initiative is a prime example of how

difficult and complex a task it is to achieve standardisation of communication in the

factory environment.

The GM MAP Task Force was established in 1980 with a charter to identify

data communications standards that would provide for multi-vendor communications

in manufacturing environments. The Task Force was comprised of representatives

from 15, different GM divisions to ensure that all plant needs were discussed and that

all appropriate control system and computer vendors were involved. It was decided

by the Task Force, from the earliest stages of investigation, that all new networking

strategies would be based upon the ISO/OSI 7 layer model framework.

It may seem rather ironic that an automobile manufacturer should be the first

organisation to launch a major assault on networking standardisation, but it must be

remembered that GM was one of the largest users of computer-based equipment in

the world when it initiated the Task Force. It should also be noted that the problem

of communications standardisation in manufacturing was so large and so chronic that

it could not have been tackled without the driving force of such a large organisation

(and end-user). Few other organisations in the world had the same level of industrial

authority to influence trends in factory network development.

The term "MAP", in the networking context, is an acronym for "Manufacturing

Automation Protocol". In short, it is a layer by layer specification for every layer in

the OSI communications model. The specification for each layer has been chosen

with due consideration for its suitability to the manufacturing environment.

We have already noted that no single networking strategy is optimal for all

environments. So how did GM manage to find a universal, "plug-in compatible"

networking strategy where others had failed? The simple answer is that they didn't

and nor did they attempt to. The objective of MAP was to rationalise standards to the

extent where a limited number of identifiable and compatible, standard networks

could be established.


From a strategic point of view, MAP development relied upon defining

different data communications environments - office, factory, national and

international. Networking specifications for each environment could then be

systematically identified so that it would ultimately be possible to bridge individual

networks (and environments) with low level interfaces. This is shown in Figure 8.13.

Node A Node B Node C Node D

Bridge

Node W Node X Node Y Node Z

Environment 2 - LAN Specification 2

Environment 1 - LAN Specification 1

Figure 8.13 - Bridging Complementary Networks

Although this form of network rationalisation sounds perfectly feasible, the

objectives are quite massive in their scope and they could not be achieved through

the operation of General Motors on its own. General Motors therefore chose to

dedicate its efforts towards the definition of standards for the factory environment.

The work of the GM MAP Task Force was then greatly augmented through the

cooperation of the Boeing Corporation, who appreciated the benefits that network

standardisation would bring to their manufacturing. Boeing chose to assist GM

through the development of a complementary networking specification for the office

environment. The acronym chosen for the Boeing specification was TOP, which is

an abbreviation for Technical Office Protocol. In terms of the simplistic diagram of

Figure 8.13, we could say that LAN specification 1 represents the TOP protocol and

LAN specification 2 represents the MAP protocol.


It must be clearly understood that the primary objective of the GM/Boeing

MAP/TOP combined Task Force was to rationalise networking standards and not to

introduce unnecessary new standards. Wherever possible, the MAP and TOP

specifications were both based upon existing standards, established by ISO, IEEE and

CCITT for Local and Wide Area Networking. Figure 8.14 illustrates the various

standards which are defined in MAP V3.0 and TOP V3.0 for each layer of the OSI

model. Note that wherever applicable, these specifications use the ISO nomenclature

for standards, rather than their IEEE or CCITT forms.

ISO 8571 FTAM

*ISO 9506 MMSISO 8649/50 ACSEISO DP9595/96 Management

ISO DP9594 Directory Services

ISO 8571 FTAM

*CCITT X.400 MHSISO 8649/50 ACSEISO DP9595/96 Management

ISO DP9594 Directory Services

ISO 8822/23 Presentation

ISO 8824/25 ASN.1

ISO 8822/23 Presentation

ISO 8824/25 ASN.1

ISO 8326/27 Connection Oriented ISO 8326/27 Connection Oriented

ISO 8072/73 Transport Class 4 ISO 8072/73 Transport Class 4

ISO 8348 CLNS

ISO 8473 Network Layer ProtocolISO DIS9542 ES-IS Exchange

ISO 8348 CLNS

ISO 8473 Network Layer ProtocolISO DIS9542 ES-IS Exchange

ISO 8802.2 LLC 1,3 ISO 8802.2 LLC 1,3

ISO 8802.4 Token Bus ISO 8802.4 Token Bus

*ISO 8802.3 CSMA/CD Bus*ISO 8802.5 Token Ring

* Denotes differences between MAP and TOP specificatons

7

6

5

4

3

2

1

OSI

LayerMAP V3.0 Specification

7

6

5

4

3

2

1

OSI

LayerTOP V3.0 Specification

Figure 8.14 - MAP V3.0 and TOP V3.0 Specifications

The similarity between the MAP and TOP specifications is self evident, with

the only major differences occurring in the first and seventh layers. The MAP

network, having its primary role on the factory floor is based upon the deterministic

(and more complex) token passing bus arrangement (IEEE 802.4). The TOP network

is generally based on the low cost ISO 8802.3 (IEEE 802.3) CSMA/CD bus, but can

optionally be run on a token bus or token ring network.


The other major difference between MAP and TOP is in the services which are

provided to end-user programs by the application layer. The major objective of

modern factory communication is to enable computers, CNC machines, process

controllers, PLCs and robots to communicate with one another. It is therefore

necessary for the MAP system to provide services which will allow a diverse range of

such devices to talk to one another in real time. This is a major task in itself and is

over and above the normal file transfer and management services provided by a

typical application layer for the office environment. The generic standard which

describes this facility is referred to as the Manufacturing Message Specification or

MMS.

MMS is a complex standard that defines entities known as Virtual

Manufacturing Devices or VMDs. VMDs are used to describe devices such as PLCs,

CNCs, etc. The MMS is then tailored, through a set of MMS companion standards,

for interaction with VMDs. One companion standard could define (say) robotic

devices, another CNC devices and so on. In other words, MMS is the kernel

specification around which companion specifications are developed as needs arise.

The MMS services to the end-user include the following:

• Virtual Manufacturing Device (VMD) support

• File access

• File management

• Operator communication

• Variable access

• Program invocation management

• Semaphore management

• MMS operating environment management

• Domain management

• Event management

• Journal management.

As with other standards we have already examined, MMS defines a number of

different classes of service. This is done so that implementations which do not need

all the above services are not burdened with unnecessary overheads. The actual

number of services provided depends upon which conformance "class" is selected for

network operation. The concept of the VMD is directed specifically towards factory-

floor systems. MMS is a very comprehensive specification which is too complex and

cumbersome for technical office applications.


The networking requirements of the technical office are not unlike those of any

other office and include:

• File transfer and access

• Distributed database interfacing

• Electronic mail systems

• File, directory, print and plot servers

• Document, data and graphics interchange.

These services can be provided by the CCITT X.400 Message Handling Specification

(MHS), which is an electronic mail facility that is used in place of MMS in the

technical office.

The other important elements, which are common to the applications layers of

both MAP and TOP, include:

• FTAM

• ACSE

• Directory Services

• Management.

FTAM is an acronym for File Transfer Access and Management. This service,

as its name implies, is designed to facilitate a simple common access scheme for

network files.

ACSE is an acronym for Association Control Service Elements. ACSE allows

an application on one network node to set up an association with an application on

another network node. This is achieved through the session layer on each node. In

order for an association to be set up, it is necessary that every application has a

mechanism for discovering the location of every other application on the network.

This is done through the Directory Services to the application program.

Management services are provided to applications programs so that they can

access or configure the current status of any node in the network. Since these

services are not only dependent upon hardware, but also upon the required network

operation and security, they must be provided by the network vendor.

As one can clearly see, even from a brief discussion of the specifications, MAP

and TOP are very sophisticated networks. Having seen these standards, the obvious

question to ask is, does manufacturing need this level of sophistication? The answer

is probably not in the short-term. However, network standardisation is such a

complex task that designers need to think of long-term requirements. As major

specifications proliferate, they gain such a momentum that it is very difficult to

change direction even after ten or twenty years (eg: RS-232). It is therefore essential

that initial specifications attempt to address future issues as far as practical.


The IEEE 802.4 physical layer specification for MAP is another standard which

addresses both present and future requirements. This token bus specification defines

three, different modulation options comprising:

• Single-channel Phase-Continuous, Frequency Shift Keying (FSK)

carrierband at 1 Mbps

• Single-channel Phase-Coherent, Frequency Shift Keying (FSK)

carrierband at 5 or 10 Mbps

• Multi-channel Duo-binary, Amplitude Modulated (AM) Phase Shift

Keying (PSK) broadband at 10 Mbps.

In terms of future expansion, the logical modulation option is broadband,

which allows for multiple voice, video and data channels to exist on the same, semi-

rigid coaxial backbone cable. However, the cost of providing broadband

communications interfaces and cabling for low cost or unintelligent devices is

unacceptably high. MAP therefore provides both the broadband and phase-coherent

carrierband options.

The total, MAP/TOP OSI architecture is shown schematically in Figure 8.15.

This network begins to resemble our ideal, plug-in compatible network. Bridges are

used to interconnect the TOP network and the broadband and carrierband MAP

networks. Note also the presence of the "Headend Remodulator" on the broadband

MAP network. In order to achieve full-duplex communications within a single cable,

broadband system, transmit and receive paths are assigned different frequency bands.

Transmitted signals are sent toward the headend device which converts these

frequencies into the receive band.

The OSI based MAP/TOP scheme shown in Figure 8.15 does not address all

manufacturing communications needs. Whilst a 7 layer OSI network is suitable for

CNCs, robots, computers, guided vehicles, etc., this form of interfacing is

unacceptable for devices such as sensors. Not only is a 7 layer protocol far too

expensive, but it may also be far too slow. For this reason, the MAP protocol also

incorporates an Enhanced Performance Architecture (EPA) format. The EPA is a

reduced platform (2½ layer scheme) which uses only the physical layer, the data link

layer and MMS portion of the applications layer. It is not OSI compatible. The EPA

scheme is shown in Figure 8.16, where some devices are equipped with only 2½

layer networking, whilst others provide both 7 layer and 2½ layer networking.

Although the 2½ layer networking scheme is faster than a full 7 layer OSI

arrangement, it is still unable to satisfy the high-speed demands of real-time

continuous process control.


PLC Robot CNC 1 CNC 2

Headend

Remodulator

MAP - IEEE 802.4 Carrierband 5 Mbps Bus

MAP - IEEE 802.4 Broadband 10 Mbps Bus

Plant

Supervisor 1

Factory

Control

System

Plant

Supervisor 2

CADSystem Workstation

MRPSystem Workstation

TOP - IEEE 802.3 Baseband 10 Mbps Bus

Bridge

Bridge

Figure 8.15 - MAP/TOP Architecture for OSI Networking

7 Layer Interface

CNC

2.5 Layer Interface

Sensor

2.5 Layer Interface

7 Layer Interface

Robot

2.5 Layer Interface

PLC

2.5 Layer Interface

7 Layer OSI MAP Carrierband Network

2.5 Layer Enhanced Performance MAP Network

Figure 8.16 - Enhanced Performance Architecture for MAP


An examination of Figures 8.15 and 8.16 leads us to examine the issue of

MAP/TOP and OSI network conformance. As one may have gathered from the

above discussions, each specification for every layer may offer a number of different

options (classes / modes) for services. Two network nodes, which each conform to

the same specification for each layer of the OSI model, may not necessarily be able to

communicate with one another directly.

A good example of conformance problems is illustrated by the IEEE 802.4

specification, which allows for different modulation techniques, different

communications media and so on. Clearly then, the criteria for conformance to an

OSI protocol is NOT just the use of equivalent specifications for each layer of the

OSI model. In order for two devices to effectively communicate, they must be set up

to use matching (or complementary) classes of service for each specification of each

layer of the OSI model. A specification for a 7-layer OSI based network that

explicitly defines all the relevant options for each standard in every layer of the

model is sometimes referred to as a "Profile".

It is evident from the complexity of each specification chosen for each layer of

the MAP/TOP system, that the development of interfacing hardware and software

needs to be carried out in consultation with specialised MAP/TOP conformance

testing centres. The traditional standards bodies alone are not structured to provide

such support and testing. An important preliminary role for the MAP/TOP Task

Force, Steering Committee and User Groups was therefore to establish conformance

testing centres for these complex protocols.

The path to plug-in network compatibility in the manufacturing environment

has been a difficult one. Even with the resources of General Motors and Boeing and

worldwide support from user groups, standards bodies, computer companies and

equipment suppliers there have been many problems. The complexity of an OSI-

based industrial networking standard is such that it discourages interface

manufacturers from investing in specialised VLSI circuits until specifications

become stable. As a result of major specification changes that occurred between

MAP/TOP version 2.1 and version 3.0, a great deal of uncertainty was created

amongst Original Equipment Manufacturers. This caused the implementation of the

MAP/TOP scheme to falter until it was decided by the MAP/TOP committees to

effectively freeze the specification at version 3.0 for a number of years. The freeze

was seen as a sensible action that would encourage third-party, interface

manufacturers re-enter the MAP/TOP product market and thereby assist in the

proliferation of the specification.


It is also important to note that the MAP/TOP specification was not

immediately embraced as a standard in any country. The General Motors and Boeing

MAP/TOP Task Force and their associated user groups expended a great deal of

effort in order to have the total specification recognised as a networking standard.

However, despite the fact that all the constituents of MAP and TOP were already

considered as standards, the total specification was the subject of lengthy reviews by

standards related bodies in North America, Europe and Japan. Ten years after the

original inception of the MAP concept, there was still a lack of consensus in regard

to its adoption as a universal networking standard for manufacturing.

The irony of computer based developments is that sometimes the standards

most carefully designed to fulfil an existing need are usurped by less-suitable, defacto

standards that proliferate through an explosion of low cost devices in another area.

RS-232 is a good example of this phenomenon. It therefore remains to be seen

whether the time delay in bringing a MAP/TOP type strategy to fruition is long

enough to allow other standards, such as those emerging in office networks to the

fore. In either event, the introduction of 7 layer OSI networks into the factory

environment is ultimately necessary to minimise the ever increasing cost of

equipment integration.

Whilst it may be that in the long term, a MAP/TOP strategy will become the

panacea for industrial networking, it must be realised that short term implementation

of such an OSI networking scheme is difficult for many manufacturing organisations.

The reasons for this are that:

• It is not feasible to provide OSI network interfaces for the majority of

programmable controllers built prior to the mid-1980s. Many of these

controllers have "closed-architectures", do not have standard internal bus

structures and cannot be readily be adapted for communications

• The cost of developing one-off OSI network interfaces for uncommon

and exotic industrial controllers is prohibitive

• It is often not practical to retrofit "old technology" systems with new

controllers because this requires an unacceptable down-time for

production equipment and complete re-commissioning

• The replacement cost of manufacturing equipment is very high and so too

is the replacement cost of the industrial control equipment. It is therefore

highly unlikely that manufacturers will discard existing equipment simply

to achieve network integration.


In simple terms, these factors mean that OSI based networks can only be

phased in as existing industrial equipment and controllers are phased out and

replaced with more modern devices. In the interim period, manufacturers are still

faced with the prospect of developing onerous communications protocols, based

upon RS-232 type hardware links.

On the other hand, the very nature of technical office computer systems makes

OSI networks such as TOP feasible even in the short term. Unlike the shop-floor

environment, the technical office only uses a relatively small range of computer

architectures of similar vintage and with a limited number of internal bus structures.

These devices are generally open-architecture and can readily be networked within an

OSI environment. The major impediment to TOP implementation is that there are

already many competing office networking strategies that have already been applied.

In the final analysis, regardless of which specifications are chosen for

networking in the manufacturing environment, it is to be hoped that the concept of

"plug-in compatibility" will be realised.


8.7 SNA

The IBM Systems Network Architecture, commonly known as SNA, is very

briefly introduced herein because of its widespread use in conjunction with the

company's own equipment. SNA is IBM's proprietary protocol architecture. Its

structure precedes the OSI 7-layer framework, but it does contain a number of

similarities. The OSI model and SNA model are shown side by side in Figure 8.17.

Physical Layer

Data Link Control - SDLC

Path

Control

Virtual Route Control

Explicit Route Control

Transmission GroupControl

Data Flow andTransmission Control

Function ManagementData Services (FMDS)

1 Physical Layer

2 Data Link Layer

3 Network Layer

4 Transport Layer

5 Session Layer

6 Presentation Layer

7 Application Layer

SNA Network Architecture OSI Network Architecture

Figure 8.17 - IBM Systems Network Architecture vs OSI

The SNA protocol is based upon synchronous serial transmission, with framing

and error control carried out by the IBM implementation of HDLC, known as SDLC

(Synchronous Data Link Control).

The basic entities within SNA are called Logical Units (LUs) and these can

represent either end users or applications programs. Communications within the

SNA system is between these Logical Units. It is the Logical Units which are

assigned addresses and not the end users as such. Logical Units are therefore referred

to as Network Addressable Units or NAUs.


Although the levels of functionality differ between OSI and SNA, the end

results are not dissimilar and consist of a large range of services that are available to

application programs and end users. SNA not only preceded the OSI framework, but

also the push for manufacturing networking, capable of handling industrial control

systems. The FMDS layer therefore does not provide services for communications

with the majority of manufacturing devices.

Although SNA is IBM's proprietary networking system, there are a range of

networking gateways that will enable other computer manufacturers to interface their

systems to SNA.

The SNA strategy was not unlike the GM MAP strategy except that it was

vendor-driven rather than end-user-driven. The fact that SNA was not universally

adopted is another illustration of how difficult it is, even for very large organisations,

to develop networking standards that gain widespread acceptance.


8.8 File Server and Office Networks

The proliferation of Personal Computers (PCs) and Workstations throughout

the office environment has changed the way in which data is processed and stored.

Where mainframe computers once performed both processing and storage, PCs and

workstations now carry out a significant proportion of both activities.

In many instances, mainframe computers have disappeared altogether to make

way for PCs, which more adeptly perform word-processing, desktop-publishing,

accounting, spreadsheets, etc. A major problem with PCs and workstations however

is that, unless they are networked, they tend to discourage centralised data storage

and "resource" sharing. The resources that tend to be most inefficiently utilised with

individual PCs are hard-disk capacity and printers. For example, ten stand-alone PCs

running the same word-processing package use up ten times the disk space that

would be used if the application program could be kept in a centralised store. With

stand-alone PCs, individual users tend to have their own printers, and these are idle

for a large proportion of the total time spent at a computer terminal.

A number of sophisticated Local Area Networks have been introduced into the

office environment to facilitate resource sharing, centralised file storage and

distribution between multiple PC workstations. These turn-key systems are called

file server networks and are based on the principle that one workstation is used to

store and distribute files for other workstations, thus minimising hard-disk and

printer requirements. File server systems are commonly based on an Ethernet or

Token Ring Network backbone and provide all the software that is necessary to share

application programs and data files between nodes with security. A typical PC file

server arrangement is shown schematically in Figure 8.18.

In the network of Figure 8.18, the file server PC holds all the applications

programs on its own bulk-storage unit (hard disk drive/s). If PC 1 wishes to run a

particular application program B (say a word-processor), then it makes a request to

the file server to "capture" that program file. The file server down-loads the program,

through the network, into the memory of PC 1. The application program executes

exactly as if it had been retrieved from a local hard disk unit.

Let us say that the application program on PC 1 is a word-processor. Once the

end-user has completed the development of a document, it is transferred back to the

file server. If the user-defined security arrangements permit, then other nodes can

then call up the document to examine or modify it. The file can also be sent through

the network to the file server for printing on the file server's printer.


Ethernet I/F Ethernet I/F

File Server

Application

Program A

Application

Program B

Application

Program C

PC 1

Application

Program A

Ethernet I/F

PC 2

Application

Program B

Ethernet I/F

PC 3

Application

Program C

Ethernet Backbone

Printer

Figure 8.18 - A File Server Network

The file server node is not unlike any of the other workstations on the system,

except that it is generally equipped with high capacity hard disk drives so that it can

store a wide range of application programs and user data. However, in order for the

file server system to operate, each workstation needs to be loaded with a special piece

of software that will capture and send files through the backbone network. The

software on the file server itself needs to be more comprehensive and take into

account file security and access, etc. All the complexities of the network are

generally transparent to the end user who only needs to issue simple commands (not

unlike those found on any PC Operating System) in order to capture and store files

through the network.

The file server itself can either be "dedicated" or "non-dedicated". A dedicated

file server is used only for handling network requests for files. A non-dedicated

server performs file serving in background mode whilst a user can run an application

program in the foreground. However, the trade-off is that the non-dedicated system

sacrifices the performance of the entire network for extra functionality in the server.

This is clearly undesirable and unnecessary given the low cost of personal computers.

It is also possible to use more than one node as a file server for the network. This is

referred to as a distributed file server network.


A simpler version of the file server is called a "disk server", which simply

provides a centralised disk storage system for all the network nodes. In such a

system, each node treats the disk server as though it were another local hard disk

drive. In the DOS environment for example, each PC may know the disk server as

drive "F:". In order for a node to run a program called "FRED.EXE", which exists on

the disk server, the node user would simply key in:

F:FRED

The use of the drive prefix "F:" would be a command to the network software that

indicated that a file transfer from the disk server had to take place.

Since one of the objectives of the file server system is to minimise the amount

of hard-disk space required to run a range of office applications, it is now possible to

purchase network PCs which have no internal hard-disk. These PCs can be equipped

with special Read Only Memory (ROM) chips, that contain a program which loads

the Operating System from the file-server (via the network). This not only saves

hard-disk space but (in conjunction with file server security systems) also eliminates

the spread of computer viruses in public computer areas such as classrooms. The

problem with this option is that it severely restricts the flexibility of any individual

PC, since it can no longer run as a stand-alone device.

There is much written about the tremendous savings that file server systems

and office LANs can provide through the use of shared printers. While in theory it

may sound attractive for any user to be able to direct files through a network to any

printer, in practice the scheme has a number of problems. The idealistic

arrangements take little cognisance of the fact that in practice:

• printers do not have an unlimited supply of paper

• offices normally use a range of different papers (letterheads, memo

sheets, envelopes, etc.)

• printers do jam paper

• people invariably realise part way through the printing of a document that

their pagination is incorrect or that they have selected inappropriate fonts

and then wish to abandon print-outs.

Although commercially available networks can handle such occurrences, they

do illustrate the fact that ultimately there needs to be some human intervention in

systems that endeavour to network intelligent mechanical devices (printers) to remote

host computers.


The printer problems in the office are completely analogous to those faced by

engineers on the factory floor, when networking intelligent production equipment

(such as CNCs or robots) to host-design-computers. Even if the network is error-free

and the source files are error free, there is no guarantee that the target machines have

been fitted with the correct tooling. With all the sophistication that networks can

offer, sometimes there is simply no substitute for a person standing directly next to a

mechanical device and switching off the power when things go wrong.

File server networks have traditionally suffered from the same problem as all

other networks - they required experienced personnel for installation and

maintenance. Without such personnel, file server networks could generate far more

problems than they resolved. However, if correctly implemented and coordinated, a

file-server system and Local Area Network can provide a sound mechanism for

information flow and resource sharing in the office environment.

The emergence of new, Windows-based operating systems for personal

computers and workstations has also changed the way in which we look upon file

server networks. Newer versions of operating systems (such as Microsoft Windows

for Work-groups and Windows NT) are being designed with built-in networking

functionality and the ability to not only share files but processing power amongst

personal computers and workstations. The maintenance problems associated with

networks will gradually decline as the network becomes more and more integrated

into the computer operating system environment.

What we are now wittnessing therefore, is the fact that the network is becoming

an integral part of the most prolific operating systems. This has enormous

ramifications that will almost certainly spill over into the manufacturing

environment. As with most computer based developments, standards are inevitably

driven by volume far more effectively than they are by Government standards bodies

and committees. So, while endless committees have been arguing over the future of

manufacturing standards, the high volume personal computer market may have

already made the decision for the manufacturing world.


8.9 What Will Our Computers Say Once they are

Networked?

All through our discussions on networking within manufacturing we have

discussed the kinds of data that we should be transferring, the kinds of data that we

would like to transfer and the kinds of data that we do transfer through

communications networks.

In a larger sense however, it is not the communications network that will

initiate the flow of information around the manufacturing environment. This kind of

systems integration can only occur when applications programs begin to make use of

the services which are provided by data communications networks. In order for this

to happen, much work will need to be done in standardising the formats in which

data is stored and the way in which applications programs access that data.

In the final analysis, we should not look upon the emergence of industrial

networking standards as the end to all our integration problems, but rather as the

beginning of a completely new set of problems. These much larger problems of

software, database and data format standardisation will ultimately need to be

overcome in order to integrate management, control and monitoring systems in the

factory environment.

287

Chapter 9

Real-Time Networks

for Distributed Control

A Summary...

Basics of networking in relation to distributed control. Issues involved in using

networks for real-time control purposes. Proprietary control networks - the

Controller Area Network (CAN) and the Local Operating Network (LON).


♦ You want to learn how computer networks relate to real-time control and what

their limitations are.

♦ You need to know why LANs could not be used for low level devices until

VLSI chip solutions were developed.

♦ You want to know about commercially available LANs for control purposes.


9.1 Introduction

Most discussions about Local Area Networks and networking theory do not

relate directly to engineering control systems. It would be quite reasonable to suggest

that the majority of networks, currently in existence, have been designed primarily to

transfer files from one node to another. Even in situations where we refer to

networks as being "deterministic" and predictable, we still don't generally expect that

they will transfer data in the sort of time-frames that we would normally associate

with control functions. In this chapter, we will examine the special attributes

required in a network in order for it to be deemed suitable for real-time control

purposes. We will also examine a few proprietary systems that are available at the

time this book has gone to press.

In order to understand the limitations of the traditional network, one really

needs to understand the way in which control systems typically function. There are

essentially three forms of control that we will examine. These are:

(i) Hierarchical

(ii) Distributed

(iii) Heterarchical.

Since there is always some heated debate as to the meaning of these terms, we shall

define them herein in our own way so that you can then equate them to whatever

equivalent form you have been brought up to recognise. Our definition of these

control systems is shown in Figures 9.1 (a), (b) and (c).

The hierarchical control structure is perhaps the oldest of the three forms of

control. Prior to the advent of microprocessor technology, hierarchical structures

were the only viable means of controlling systems such as machines, power

generation systems, etc. The host system was typically a very expensive device, with

relatively little power by modern terms. The host exercised closed loop control over

systems via intermediate actuators, sensors and transducers.

The distributed control structure is a hybrid between the hierarchical system

and the heterarchical system. It is called distributed because the total processing

work associated with controlling a system is distributed over a number of intelligent

devices which, in turn, interact with local sensors transducers and actuators.

The heterarchical control structure is a completely distributed system, where a

number of intelligent devices all interact with one another in order to control a

system. In a well designed system, the failure of one device should not cause an

uncontrollable situation to arise.

Real-Time Networks for Distributed Control 289

Host

Sensors Transducers Actuators

(a)

Intelligent

Host

Intelligent

Slave 1


IntelligentSlave N


Intelligent

LAN

Hard-Wired Signals

Hard-Wired Signals

...

(b)


Local

Host N


Real-Time LAN

Hard-Wired Signals

...

(c)

Host 1

Local

Figure 9.1 - Possible Control Architectures

(a) Hierarchical; (b) Distributed; (c) Heterarchical

Hierarchical control systems have always been far easier to comprehend than

heterarchical systems. In particular, hierarchical control systems are closely aligned

to classical analogue control theory. Distributed control systems are also relatively

easy to come to terms with, in the sense that one can see great advantages in

devolving control functions into local blocks and relieving the load upon the host

system. The heterarchical control system, on the other hand, is one which intuitively

appears to have a great deal of potential, but normally suffers from practical

implementation problems.


The distributed and heterarchical control systems both emerged with the

development of powerful microprocessors and Digital Signal Processors (DSPs) and

both depend upon a reliable LAN to transfer data. In both these systems, we are

concerned with the throughput of the network in terms of the number of messages

that can be transmitted over a given time, rather than the number of bytes. This is

because control information in distributed and heterarchical systems tends to be short

in length, but needs to be transmitted very quickly.

In the distributed system, the throughput of the network is actually dependent

upon the distribution of control functions. In other words, if the slave processors in

the system are very intelligent, then the information flow may be relatively sparse

under normal circumstances. A good example is a Flexible Manufacturing System,

where a host computer controls robots, CNC machines and PLCs. The slaves in this

case only require a preliminary down-loading of program files and then occasional

start messages issued by the host. Unless a serious error occurs in the slave devices,

there is little need for them to transmit information (other than simple

acknowledgement messages) back to the host. On the other hand, the slave

processors may be little more than microprocessor or DSP controlled transducers

which require a constant flow of information from the host. In these instances, the

throughput of the network needs to be very high in terms of the number of messages

transmitted per second.

A heterarchical control system is a fully decomposed architecture that is

normally critically dependent upon its network for success. Since the network

messages are an integral part of the control structure, the throughput of the network

must be high enough to enable the total control algorithm to execute. However, if we

have a situation where each of the local host processors are very intelligent in their

own right, then we can still minimise the demands upon the network as we do in the

distributed system.

The hierarchical control system, as we have shown it in Figure 9.1 (a), has no

network associated with it. However, this is a historical restriction that we have

always assumed to be insurmountable as a result of technical limitations in

networking. In fact, thus far, we have always assumed that networking was only for

"intelligent devices", such as computers and other processor controlled devices. We

have never considered the possibility that simple transducers, switches, actuators, etc.

should be connected to a network.


In the light of our traditional understanding of networks, it would appear to be

rather ludicrous to suggest that a switch or a transducer should be connected to a full

seven layer OSI network. The cost of the interface would be prohibitive. In fact, the

interface would need to be a complete computer system composed of a multi-tasking

processor, RAM and EEPROM. The processor would need to power a transceiver

device that provided the line-drivers for the communications medium on the network.

So, in terms of our traditional understanding we would have never contemplated the

idea of reorganising and redistributing our concepts of control through networks.

What we have failed to consider in terms of our traditional approaches to

control is that the cost of the network interfaces will diminish substantially with:

• Increased processor power

• Increased production volumes

• Standardisation of networks.

We already know that standardisation in networking is a difficult concept and we

also know that it generally comes through defacto usage of a given system more than

it does by Government specification and regulation - the Microsoft DOS system is

the classic example here. The logic we therefore need to consider is that if we can

generate low cost network interfaces for simple devices (such as switches, etc.), then

production volumes will dramatically increase, costs will reduce even further and the

normal technology spiral will ensue.

The interesting point to note is that since the early 1990s, a number of

companies have been pursuing just such a course of action. This is a radically

different approach to the end-user-specification method tried by General Motors in

the 1980s, with only limited success. In this chapter we shall briefly examine some

of these proprietary networks and their implications for control. We shall do this

with the assumption that eventually, one of these systems will ultimately achieve a

defacto standard status and perhaps, change the way in which we structure our

control systems.


9.2 Typical Control Applications for Real-Time Networks

At the time that this book had gone to press, there were no networks which

could justifiably be called "real-time" in the classical analogue control sense of the

word. When we talk of analogue control, we are generally dealing with what could

be classified as instantaneous response - or more appropriately, devices which can

provide output signals within nanoseconds or microseconds of having received some

input energy. The very nature of the networking process, encompassing media access

(contention resolution), modulation, demodulation, packetisation (framing) and

depacketisation (de-framing) of data, error detection and correction, does not yet lend

itself to nanosecond or even microsecond response times. However, since most

modern control systems are computer or processor based, we have come to accept

that some small delays can be tolerated by an appropriate structuring of the control

architecture.

If a network is sufficiently well designed, then there are many instances where

it would be possible to use such a network for system control. In this section, we will

only examine a few basic areas to demonstrate the current scope for real-time

networks.

(a) Vehicle Control Systems

Most modern cars feature one or more microprocessors and/or DSP devices

that are used to coordinate a range of functions, including:

• Engine management and fuel injection

• Electric, programmable seats

• Climate control

• Safety systems (air-bags, seat-belt utilisation, etc.)

• Body management (suspension stiffness, body distortion, etc.)

systems.

Modern vehicle management systems are in fact based upon distributed control

systems, receiving feedback from hundreds of sensors, transducers and

switches and actuating solenoids, relays, stepper and servo motors.

It would be reasonable to suggest that if the control functions are carefully

distributed then small delays, caused by networking, could be tolerated in order

to provide drivers with a sophisticated control system, capable of monitoring

all important vehicle activities.


The alternative to using a network in a vehicle is to simply hard-wire all

sensors back to their relevant controllers and eventually feed this information

back to the driver via some intermediary processor. The problem with this

approach however, is that it tends to generate enormous amounts of wiring,

leading to reliability problems with harness connectors, spurious signals due to

electromagnetic interference and space and interference problems due to

moving harnesses. Another point of concern is the enormous cost of building

the wiring looms required for vehicles whose complexity is constantly

increasing.

These problems are obviously not restricted to cars and are in fact magnified

when one considers the complexity of modern buses, tram cars and aircraft,

where dozens or hundreds of seats need to be supplied with a range of different

functions including seat control, air-conditioning control, etc. Clearly

networking needs to be considered for all these control applications.

(b) Machine Control Systems

Modern production machines and robots are composed from a collection of

servo motors, each feeding back information to a central computer, which

coordinates axis movement. However, recent developments in servo

technology have changed the nature of control systems from the traditional

hierarchical approach shown in Figure 2.3, to one where the servo controllers

are provided with intelligence and can be scheduled by the host.

A number of servo motor control systems are now available with limited

communications facilities such as RS-232 and RS-422 based point-to-point

links or RS-485 based multi-drop networks. Even modern stepper motors

(indexers) are becoming available with communications links. The problem

with all these devices is that there are no standard or even common

communications protocols to which they adhere. Moreover, the

communications protocols often chosen for these networks are generally not

optimised (that is, fast enough) to enable these devices to form a networked

structure with the CNC or robot control.

A low level "real-time" network, capable of transmitting small packets of data

at very high speed is required in order to facilitate a re-think on the basic design

of CNC and robotic control systems.


(c) Intelligent Building Control

Commercial and domestic buildings, like cars, are becoming more and more

complex. Zone-controlled air-conditioning systems, lighting control systems,

fire protection systems, security systems, access control systems and the like

are all features of modern office buildings. Around the home, most appliances

are developed with some form of processor control and timing circuitry and

office security and protection systems are gradually making their way into

domestic situations.

Until recently, one of the only alternatives in combining these systems into

cohesive controls was to use hard-wiring. Needless to say, this is quite

expensive, particularly when one considers that each (fire protection, access

control, etc.) system has traditionally been treated as an "island" of control and

that little interaction between systems normally occurs. There is clearly a need

for networking in this environment, but we are again confronted with the

problem of interfacing low level devices (switches, air-conditioning baffle

controls, etc.) to sophisticated networks. In other words, the cost of interfacing

these devices may be orders of magnitude higher than the cost of the devices

themselves. The provision of a network interface worth several thousand

dollars for each light switch worth several dollars is clearly not a feasible

solution to the problem.

(d) Manufacturing Management Systems

Production and inventory control systems and materials and requirements

planning systems are notorious for the problems caused by "old" factory floor

data. It isn't simply a question of extracting information from intelligent

devices such as CNC machines, robots and PLCs, but also a question of

acquiring data from simple sensors, bar-code readers, part identification

systems and so on. Many factories still acquire this data manually because it

has been too difficult to provide networked feedback systems that can

satisfactorily provide an automated solution.

In this environment, a low-level network that could provide feedback from

simple devices, at low cost, could improve the problem of planning with "old"

data. The time response in such a network is not the crucial factor, since a

delay of milliseconds is clearly better than a manual delay of one hour, day or

week. The real issue here is low-cost interfacing of low-level devices.

In each of the above situations where networks can be applied, the same issues

arise. First and foremost is cost. Second is the ability to integrate low level devices

into the network. A network which only includes some devices and sensors is not

really a solution, but an exacerbation of the existing problem.


9.3 Proprietary Real-Time LANs - CAN and LON

The need for so-called real-time networks that can provide low cost interfaces

to low level devices has not gone unnoticed. The problem, as usual, is non-

standardisation of networks. Just a few of the proposed solutions (standards) to the

problem include:

• Enhanced Performance MAP (factory automation)

• CAN (factory automation and automotive)

• Fieldbus (SP50) (factory automation)

• SAE (J1850) (automotive)

• BacNet (ASHRAE) (building control)

• IBI (building control)

• TRON (building control)

• Home Bus (building control)

• CEBus (EIA) (building control)

• LONWorks (building control, automotive and automation).

The problem with most of these "solutions" comes in terms of implementation.

There is nothing new about this problem and it is common to nearly all networks.

The difficulty that system designers and developers have is that manufacturers tend

to equate the provision of semiconductor devices, which implement the physical and

data link layers of the OSI model (to some specification), to the provision of a

network. This simply isn't the case, because the developer is left to implement the

upper layers of the OSI model.

From a system developer's point of view, The real issue in networking can be

summarised in the following terms:

"Given a transducer, sensor, switch, microprocessor or DSP controller, how

much hardware and software development work needs to be carried out in

order to interface the device to a network?"

Very few commercially available networks are able to provide a satisfactory answer

to this question and, from the above list, we will briefly examine two relatively

promising proprietary systems. The two systems we shall briefly examine are the:

(i) Controller Area Network (CAN) Bus

(ii) Local Operating Network (LON) Works.


(i) CAN Bus

The Controller Area Network was developed by the Bosch corporation,

specifically for the automotive industry and for factory automation purposes.

The objective of the CAN system is to provide a network which can transfer

small packets of data at relatively high speed over a range of media. The

system can be classified with the term "real-time" as far as that terminology can

be stretched for control purposes.

The Philips corporation has created the semiconductor devices that implement

the lower layers of the network protocol in hardware. At the time of writing

this text, the upper layers of the CAN system had to be implemented in

software. The major application of CAN is in automotive control systems and

the network has reportedly already been used by European car manufacturers,

such as Daimler-Benz, in complex car control systems.

There is nothing remarkable about the CAN protocol itself as it is composed of

network layers similar to those found in other networks. The lower network

layers are designed to provide reliable high-speed data transfer for small

packets and to handle network contentions via a special CSMA/CD scheme

that provides prioritised packet handling for urgent messages. The special

CSMA/CD scheme overcomes most of the traditional problems associated with

the non-deterministic nature of this media-access scheme. Its development

clearly follows on from the acceptance of the Ethernet system as a defacto

standard in office-networks. Error checking in CAN is implemented through

Cyclic Redundancy Check algorithms.

Given that the CAN system has already received some acceptance in the

European community, as a result of its implementation in the car industry, it is

anticipated that a number of third party products will emerge in order to

simplify the networking process. At this point in time, the upper layers are a

sticking point in implementation. Although software is available for a range of

different microprocessors and DSPs, the real issue that needs to be resolved is

how the network can be interfaced to simple, low-level devices.

(ii) The LON Works Architecture

This is perhaps one of the most interesting and promising networking

developments to have emerged in recent times. The LON system was

developed by the Echelon corporation in the United States, with semiconductor

support devices implemented by the Motorola corporation. It is amongst the

very first, complete OSI networking systems to be implemented almost totally

in hardware.


The basis of the development is the so-called Neuron chip, produced by

Motorola. The device is shown in Figure 9.2, which has been reproduced (with

permission) from Motorola literature.

Processor

1

Processor2

Processor

3

ROM

10 kBytes

EEPROM512 Bytes

RAM

1 kByte

Communication

Port

I/O

Section

Address Data

Bus Bus

Timing

& Control

CP.0

CP.1

CP.2

CP.3

I/O 10

I/O 9

I/O 1

:

:

Clock & TImer

ControlServiceReset

Clock

2

General I/OParallel Port

Serial Port

Timer/Counter

Neuron 3120

Figure 9.2 - Motorola 3120 Neuron Chip

(Reproduced from Motorola Original Diagram)


The Neuron chip contains all seven layers of an OSI communications protocol

within a single chip, which is produced by Motorola at a very low cost. The

3120 chip, shown in Figure 9.2, contains three processors, which together

implement the LON-Talk protocol and interact with user hardware via the

input/output lines in the I/O section of the chip. The LON Works architecture

is based upon a prioritised CSMA/CD media access system, which facilitates

real-time networking. The system developer links their device to the Neuron

chip via a short program, written in a special implementation of the C

language, and stored in EEPROM on the Neuron chip.

Each Neuron device has its own unique 47-bit address, which is preconfigured

during production. The system developer does not really need to become

involved in the addressing, contention resolution or other technical networking

issues, which are all handled by the Neuron device. The main tasks of the

system designer are then to:

• Connect the local device (switch, transducer, DSP, microprocessor,

etc.) to the neuron chip via the I/O lines

• Connect the Neuron chip to the network medium via a matching

transceiver chip (which can drive twisted-pair, powerline or radio-

frequency media)

• Program the Neuron chip to interact with the network via the

special Neuron programming language.

The overall network structure then becomes as shown in Figure 9.3.

LocalSensor

orController

NeuronChip

Transceiver

LocalSensor

orController

NeuronChip

Transceiver

Communications Medium - Powerline / Twisted-Pair / etc.

I/O Port

Comms. Port

I/O Port

Comms. Port

Figure 9.3 - System Design Using LON-Architecture


The benefits of the LON system are predominantly in the development stage,

where the Neuron programming system isolates the developer from the

majority of networking functions. The sophisticated network programmers

interface even alleviates the need for system developers to concentrate on

addressing problems, since these can readily be accounted for in the high level

Neuron "C" language syntax.

Of particular interest with the LON Works architecture are the range of

transceivers that have been made available. These include powerline

transmission and radio frequency transmission. The powerline system is of

particular importance to the building industry where cabling costs can be

substantially reduced by having intelligent Neuron-based nodes (light fittings,

light switches, alarms, etc.) networked to one another through the normal

building power supply bus. The radio frequency transmission system is also of

interest to manufacturing installations where it may be necessary to network

devices which are located on rotating or moving machinery and are otherwise

difficult to connect with cables, etc. Unfortunately, both of these alternatives

offer relatively low data transmission rates and are not suitable for control

environments that are network intensive.


9.4 Conclusions

The development of the proprietary systems such as the CAN system and the

LON system have been included herein because they are amongst the first systems to

turn control networking into a commodity that can readily be exploited by system

developers.

These are the first signs that networking for control applications can be

achieved for a low cost, in terms of individual interface hardware and development

time. They are certain to form new trends in distributed control structures for both

manufacturing systems and building control systems. What remains now is for us to

see which of these emerging systems will ultimately gain the status of defacto

standards and how these systems will tie into the more traditional office-type

networks to which we have already become accustomed.

A-1

Appendix A

Industrial Data Communications Dictionary

A Summary...

This dictionary contains a list of words, phrases, terms and acronyms commonly

associated with data communications in the manufacturing environment. It is

structured so that these entities appear in alphabetical order, according to their most

commonly used form. In situations where both acronyms and full names are used

interchangeably, both are listed.

A-2 D.J. Toncich - Data Communications and Networking for Manufacturing Industries

ACK

The mnemonic for the ASCII character generally sent as an acknowledgment to

an enquiry or message. Normally, the character with an ASCII value of

decimal 6.

ACSE

Association Control Service Element. The portion of the OSI application layer

that is responsible for establishing associations between application programs

on network nodes.

Active Token Monitor

In the IBM token ring network, this is the name given to the node which

assumes responsibility for network management.

Address

The identifier by which a node (computer) on a network is accessed.

AGV

The common abbreviation for Automated Guided Vehicle. A computer

controlled device used to ferry parts around a manufacturing plant.

ANSI

American National Standards Institute - an official body dealing with

standards.

Application

A piece of software that runs on a computer system.

Application Layer

Layer 7 of the OSI model. Services provided in this layer directly support

user/application tasks by providing "generic" services such as remote file

access, file transfer, etc.

ASCII

American Standard Code for Information Interchange. Defines all 8 bit

patterns corresponding to a standard terminal character set. The standard

ASCII set uses only 7 of the 8 bits in a byte, whilst the extended ASCII set

defines additional characters using the 8th bit.

Asynchronous Transmission

A serial transmission scheme where the clock on the transmitter and the clock

on the receiver are not directly synchronised to one another.

Appendix A - Industrial Data Communications Dictionary A-3

Backbone

The trunk media (physical layer) of a multi-media LAN separated into sections

by bridges, gateways or routers. Also the main physical medium used in a

network.

Background Mode

In a multi-tasking computer operating system, it represents an active task which

is not visible to the user.

Band

A range of frequencies in the spectrum between two limits. Frequencies are

expressed in kHz up to and including 3000 kHz; in MHz from there up to and

including 3000 GHz. Thereafter tHz (teraHertz) are used.

Bandwidth

The difference in frequency between the highest and lowest frequency in a

transmission channel.

Baseband

Transmission of a signal at its original frequency with pulsed modulation.

Baseband signalling systems are limited to a single channel.

Basic Mode

An ISO specification for a character-oriented link level protocol.

Baud Rate

The signalling rate on a communications link. This is often confused with the

number of bits per second (bit rate) because in some instances the Baud rate

and the bit rate have the same value.

BCS (Block Check Sum)

A check character which represents a mathematical combination of data bits. It

is transmitted following the data and is used for error checking by the recipient.

Bit Stuffing (Zero Bit Insertion)

A scheme which enables pure binary data to be transferred on a synchronous

link. Data is delimited by special bit patterns and if the same patterns appear

within the data then additional zero bits are inserted (stuffed) into the data by

the sender.

BPS

Bits per Second - Transfer rate of a serial or parallel transmission.


Bridge

Transparent devices used to connect similar LANs together. Networks

connected by bridges would logically appear as one network.

Broadband

Use of multiple channels over the same media via frequency division of the

bandwidth.

Broadcast

Transmission of a message to multiple nodes.

BSC / BiSync

Binary Synchronous Control - IBM version of the ISO Basic Mode protocol

BSI

British Standards Institute.

Bus

A collection of electrical conductors grouped together for a common purpose.

Bus Network

A topology in which information is made available simultaneously to all nodes

CAD

Acronym for Computer Aided Design

CAN

Acronym for Controller Area Network developed by Bosch and implemented

in semiconductor form by Philips for automotive use.

Carrierband Transmission

Transmission of a signal at its original frequency, with frequency modulation.

CASE

Acronym for Common Application Service Elements. Service elements are

entities that are used to build an applications layer (in OSI terminology). Those

elements that are common to a number of applications are known as Common

Application Service Elements.

Catanet

An interconnected set of networks using bridges, routers and or gateways

CCITT

Comité Consultatif Internationale de Telegraphie et Telephonie - An

international consultative committee on communications standards


Centronics Port

A common type of parallel communications port generally used in conjunction

with printers

Channel

That part of a communications medium that connects a transmitter to a receiver

or receivers. A path for electrical transmission between two or more points.

CIM

The acronym for Computer Integrated Manufacture. The ideology which

suggests that all computer based production and manufacturing management

equipment should operate cohesively.

Circuit Switched Network

A network in which switches cause a physical (electrical) circuit to be

established between devices for communications.

CMM

Co-ordinate Measuring Machine - A device used for metrology.

CNC

Computer Numerical Control - A specialised computer control system used to

co-ordinate the operation of a machine tool such as a lathe or mill. Computer

Numerical Control is also used for surface-mount technology in electronics and

for sewing machine control in textiles industries. The CNC is distinguished

from the older Numerical Controller (NC) by the fact that it contains an

operating system, program editing and storage facilities.

Co-Axial Cable

A two-conductor cable in which a central "data-carrying" conductor is encased

in a dielectric material, and then enclosed by the outer conductor in order to

minimise EMI.

Connection

The communication dialogue of a pair of communication entities in the same or

different processors.

Connectionless

Message transmission without the establishment of an electrical circuit.

Sometimes abbreviated with CLNS (for Connectionless Network Service).

Connectivity

A characteristic of open systems such that they have the ability to pass data

from one communicating entity to another.


CPU

The common acronym for Central Processing (Processor) Unit. Normally the

microprocessor chip or main processing board within a computer system.

CRC

The acronym for Cyclic Redundancy Checksum - An error detection scheme in

which the check character/s are generated by taking the remainder after

dividing all the serialised bits in a block of data by a predetermined binary

number (CRC polynomial).

CSMA/CD

Carrier Sense Multiple Access with Collision Detection. A scheme to resolve

contentions for use of communications media in a network.

Data Link

A logical connection between two stations on the same circuit. In the case of a

multi-point link such as MAP, multiple data links can exist on a single circuit.

Data Link Layer

Layer 2 defined in the ISO seven layer OSI model. The data link layer

establishes an error free communications path between network nodes over a

physical channel; frames messages for transmission; checks the integrity of

incoming messages; ensures proper sequencing of transmitted data and

manages access to and use of the channel.

Data Highway

Allen Bradley proprietary Local Area Network for the manufacturing

environment.

Data Units

Messages passed over connections.

DCE

Acronym for Data Communications Equipment or Data Circuit Terminating

Equipment. This is a term given to modems (or other equipment provided by a

public networking authority) for the attachment of user equipment to that

network.

DEC

Acronym for Digital Equipment Corporation.

DECNET

Digital Equipment Corporation's proprietary Local Area Network.


Deterministic

A type of network in which delays in transmission response can be accurately

predicted.

Directory Services

The LAN System function, found in the applications layer, which converts

symbolic names used by applications programs into physical network

addresses.

DLE

Acronym for Data Link Escape character. This character is sometimes sent to

separate message data from other link control characters. It normally has the

ASCII value of decimal 16.

DNA

Digital/Distributed Network Architecture - the networking architecture of the

Digital Equipment Corporation.

DNC

Totally confused acronym for Distributed or Direct Numerical Control. DNC

can simply refer to a CNC that can be linked to a host computer for unchecked

file transfers. DNC can also infer that a Computer Numerical Control can be

remotely controlled by a host computer, through a communications protocol.

DTE

Acronym for Data Terminal Equipment. The name given to devices which are

connected to a network or point to point communication link.

EBCDIC

Acronym for Extended Binary Coded Decimal Interchange Code. An

alternative to the ASCII code and used mainly by IBM computers other than

their PC series.

ECMA

Acronym for European Computer Manufacturers Association.

EIA

Acronym for Electronics Industries Association. A US organisation

specialising in the electrical and functional characteristics of equipment

interface.

EMI

Acronym for Electro-Magnetic Interference. Electrical noise which is induced

into a system as a result of magnetic fields surrounding current carrying

conductors.


ENQ

A mnemonic for the ENQuiry character, which is generally issued to establish a

link. It normally has the ASCII value of decimal 5.

EOT

An acronym for the End Of Transmission character, which is sent to conclude a

communications sequence. It normally has the ASCII value of decimal 4.

EPA

Acronym for Enhanced Performance Architecture. A General Motors, MAP

specification for high-speed communications between low cost devices such as

sensors.

Error Rate

The ratio of the mean number of corrupted data bits to the total number of

transmitted data bits.

Ethernet

A XEROX, DEC and Intel implementation of the CSMA/CD contention

scheme. Ethernet was the basis of the IEEE 802.3 standard. Ethernet is not a

network in itself, but it is used as the basis of commercial networks which

provide the upper layers of the OSI model.

ETX

A mnemonic for the End Of Text character, which is normally sent after the

data portion of a message. It normally has the ASCII value of decimal 3.

Fibre Optics or Optic Fibre

Transmission of data by frequency modulated light energy within the media of

a micro-diameter glass filament.

Flip-Flop

A binary storage element whose outputs can be latched into a high or low state

by an external signal.

FMC / FMS

Acronyms for Flexible Manufacturing Cell or Flexible Manufacturing System.

A production system in which the constituent parts are programmable,

normally consisting of CNC machines, Robots, AGVs, etc.

Frame

The name sometimes given to a unit of data on a network. Packet, block and

message are also used.


Frame Check Sequence (FCS)

The generic name for a bit-oriented error checking string used to trap errors in a

communications link. A specific form of the FCS is called the Cyclic

Redundancy Check or CRC.

Frequency Division Multiplexing (FDM)

The technique of dividing the total bandwidth of a communications medium

into a number of discrete channels.

Frequency Shift Keying (FSK)

A modulation technique used to transmit binary ones with a given frequency

waveform and zeros with a waveform of another frequency.

FTAM

Acronym for File Transfer, Access and Management (Manipulation). In the

application layer of the OSI model, a function for file movement between open

systems.

FTL

Acronym for Flexible Transfer Line. A production line with a conveyor

transport system and programmable (CNC) machine tools.

Full-Duplex

A type of communication link capable of simultaneous, two way data transfer.

Gateway

A processor which acts as an interface, and protocol translator, between two

totally dissimilar networks.

GPIB / HPIB

General Purpose Instrumentation Bus or Hewlett Packard Instrumentation Bus.

These are implementations of the IEEE-488 parallel communications

instrumentation network.

Half-Duplex

A type of communication link capable of two way, alternate data transfer. In

other words, two way data transfer can occur but not simultaneously.

HDLC

Acronym for High Level Data Link Control - A Data Link Layer Protocol.

Hertz

A unit of frequency equal to one cycle per second.


Host

The term normally used to describe a superior computer.

IEEE

Acronym for the Institute of Electrical and Electronics Engineers.

IEEE-488

The Standard specifying a parallel communications bus structure for

instrumentation in the laboratory environment. Also known as HPIB or GPIB.

IEEE-802

A committee formed within the IEEE to establish LAN standards. The 802

standard has sections as follows:

• 802.1 - Higher Layer Interface

• 802.2 - Logical Link Control

• 802.3 - CSMA/CD

• 802.4 - Token Bus

• 802.5 - Token Ring

• 802.6 - Metropolitan Area Network

ISDN (Integrated Services Digital Network)

An international digital telecommunications network supporting both data and

voice communications.

ISO

Acronym for International Standards Organisation

LAN

Acronym for Local Area Network. A privately owned network, offering

reliable high-speed communications channels for connecting information

processing equipment over a limited region.

Layer or OSI Layer

The overall networking architecture as defined by ISO is subdivided into

layers. Each layer provides a set of network related services to the layer above

or in the case of the top layer, to the application program. These services are

provided by each layer via its programs and by the services available from the

layer below or in the case of the bottom layer from the physical

communications media. Messages moved between application level programs

in different processors must traverse all the layers in both nodes. However, a

layer may be a null layer if its services are not required.


LLC

Acronym for Logical Link Control. In IEEE terminology, the LLC constitutes

the upper half of the data link layer. It is responsible for the framing of

messages and the detection and correction of errors.

LON

Acronym for the Echelon/Motorola developed Local Operating Network.

MAC

Acronym for Media Access Control. In IEEE terminology, the MAC

constitutes the lower half of the data link layer. It defines the techniques used

to resolve contentions for use of the communications medium. Schemes

include token passing and CSMA/CD.

Manchester Encoding

A technique used to encrypt timing information into data in a synchronous

communications scheme.

MAP

Acronym for Manufacturing Automation Protocol. A General Motors

specification based around existing and emerging international standards and

based upon the OSI seven layer model

Media Access

Means by which a node gains access to a network for transmission.

Medium

Material over which information is passed (wire, optic-fibre, etc.).

MHS (Message Handling Service)

A general protocol for the applications layer that is used to facilitate electronic

message interchange. It is also referred to as X.400.

Migration Path

Methodology allowing step by step implementation of emerging technology.

MMFS

Acronym for Manufacturing Message Format Standard. A complex

specification for the applications layer of the OSI model. MMFS was specified

for the application layer of the MAP V2.1 protocol.

MMS

Acronym for Manufacturing Message Standard. A modular specification for

the OSI application layer, based upon the definition of Virtual Manufacturing

Devices. MMS is specified for the application layer of MAP V3.0.


MODBUS

Gould-Modicon Corporation's Industrial Local Area Network.

Modem

Modulation/Demodulation device. A device that translates signals from digital

form to a form suitable for transmission over communications lines and then

back to digital.

Multidrop

A communications scheme in which a single transmission medium supports

multiple nodes (compared with point to point links).

Multiplexer (MUX)

Electrical Engineering term for a switching device.

NAK

Mnemonic for Negative Acknowledgment. Normally sent by a device which

has detected an error in message reception. It generally has the ASCII value of

decimal 21.

NAU

Acronym for Network Addressable Unit. A basic node in IBM Corporation's

SNA networking structure.

NBS

Acronym for National Bureau of Standards. An American standards body.

NC

Numerical Control. An early form of machine control system generally based

upon paper-tape programming. The precursor to CNC.

Network

An interconnected group of computer-based nodes.

Network Layer

Layer 3 of the OSI model. Controls message flow between nodes and performs

addressing, routing and path set-up services.

Neuron Chip

A multi-processor VLSI device which is Motorola's implementation of all

seven layers of the Echelon LON Works network protocol.

NIU

Acronym for Network Interface Unit. Translates from device bus structure or

protocol to the network protocol.


Node Address

A unique address for each device on a LAN.

Noise

(i) Term given to spurious electrical signals induced in a communications link.

(ii) The signal level at which there is no discernible information

NRZ/NRZI (Non-Return To Zero)

Two similar schemes for encoding clocking information into data within a

synchronous communications link.

Null Layer

A layer in the OSI system which provides no additional services and exists only

to provide a logical path for the flow of network data and control.

Ones' Complement

In binary arithmetic, the one's complement of a number is achieved by

reversing the status of every bit in the number. For example, the one's

complement of binary 01100011 is binary 10011100.

Open System

(i) A computer based apparatus which is fully software programmable. (ii) A

computer processor or connected set of processors with software support that

allows an application entity running in the open system to communicate with

other application entities running on the same or other open systems.

Open Systems Network

A series of connected open systems whose applications have connectivity with

each other in a peer to peer relationship. Each system in an open systems

network provides common services and related protocols.

Optic Fibre Cable

A glass filament cable in which data signals (pre-converted from electrical

signals into light pulses) can be transmitted without susceptance to EMI.

OSI

Acronym for Open Systems Interconnection - An ISO developed, seven layer

model for communications.

OSIE

Acronym for Open Systems Interconnection Environment.

PABX

Acronym for Private Automatic Branch Exchange. A device used to

electronically interconnect different nodes.


PAD

Acronym for Packet Assembler-Disassembler. Used in conjunction with the

X.25 packet switched network.

PAL

Acronym for Programmable Array Logic. A digital technology that enables

complex Boolean circuits to be implemented on a single chip by end users. A

similar (but not identical) technology to PLA.

PBX

Acronym for Private Branch Exchange - usually associated with telephones

PC

Acronym for Personal Computer

PD

Acronym for Programmable Devices (PLCs, Robots, CNCs, PCs)

PDU

Programmable Data Unit - A unit of data specified in a protocol and consisting

of protocol control information and possibly user data. The total information

that is transferred between peer entities as a unit.

Peer Network Device

Any device directly attached to the MAP local area network which contains a

system manager and has transport layer functionality.

Phase Shift Keying (PSK)

A modulation technique in which ones are represented by a waveform of a

given phase and zeros are represented by a waveform of a different phase.

Physical Layer

Layer 1 of the OSI model. The physical layer defines the electrical and

mechanical aspect of interfacing to a physical medium for transmitting data, as

well as setting up, maintaining and disconnecting physical links. Physical

hardware in this layer includes interface devices, modems and communications

lines. Software to control the communications devices is also included.

PLA

Acronym for Programmable Logic Array. A digital technology that enables

complex Boolean circuits to be integrated on a single chip by end-users.

Similar (but not identical) to PAL technology.


PLC

Programmable Logic Controller. An industrial computer control generally used

for sequential systems.

Point To Point Link

A single communication link with a device at each end.

Presentation Layer

The sixth layer of the OSI model, designed to control the presentation of data to

the application program.

Print Spooler

Software or hardware that creates a buffer where files to be printed are held

until they are processed.

Protocol

In communications, a set of rules (specifications) which strictly define the way

in which data transfer is to occur between devices on a link or network.

Public Switched Data Network (PSDN)

A communications network established by a public body for the purpose of

interchanging digital data over large distances.

Public Switched Telephone Network (PSTN)

An analogue communications network set up for voice communications and

capable of supporting data communications through the use of modems.

QPSK

Acronym for Quadrature Phase Shift Keying. A modulation technique

derivative of PSK.

Register

A collection of flip-flops grouped together for some common purpose.

Response Time

Waiting time between request for use of a network and the time at which

requested service is provided.

Ring Network

A topology in which information is passed from node to node in a logical loop.

Router

A device that performs translations between the lower 3 layers of multiple,

dissimilar LANs.


Routing

A function within a layer that translates the name of an entity, or the service

access point address to which it is attached, into a path by which the entity can

be reached.

RS-232

Electronics Industries Association standard governing hardware and hand-

shaking for serial devices.

RS-422

A balanced wire-pair signalling system that can be used for serial

communication with greater noise immunity than RS-232.

RS-449

A communication standard based upon RS-422 signalling.

SDLC

Acronym for Synchronous Data Link Communication. IBM version of

synchronous, serial data-link level protocol which is almost identical to HDLC.

Services

The functions offered by an open system to communicating entities in adjacent

layers.

Session Layer

Layer 5 of the OSI model. Establishes and controls system-dependent aspects

of communications sessions between specific nodes, bridging the gap between

services provided by the transport layer and functions provided by the operating

system of the node.

Simplex Link

A link which is only designed for one way data transfer.

SNA

Acronym for Systems Network Architecture - the IBM Networking

architecture.

Star Network

A topology consisting of a central node with radiating link elements.

Statistical (Non-Deterministic) Network

A network in which response varies probabilistically with data traffic

conditions.


STX

Mnemonic for the Start of Transmission character, which usually precedes the

data field in a message. It normally has the ASCII value of decimal 2.

Sub network (MAP)

A MAP compatible, bridge accessible sub network. Logically both the

backbone and the sub network look like one network.

Synchronous Communications

A serial communications scheme in which clocking information from a

transmitter is either encrypted into data or else fed directly to a receiver for

extraction and synchronisation.

System Manager (MAP)

Resides in all MAP nodes and is responsible for interfacing with Network

Management to provide information or to execute network management

functions. The level of functionality resident within a system manager is

dependent on the class of node and the specific vendor implementation.

Terminal

Text input/output device - VDU/Printer, etc..

Throughput

Measure of the aggregate amount of data a network can carry in a given time.

TIM

Token Bus Interface Module. An external processor which provides layers 1

and 2 of the MAP protocol.

Time Division Multiplexing (TDM)

A scheme in which the total bandwidth of a communications medium is shared

by multiple channels, through time-slicing of data.

Token

Special bit patterns or packet that travels on a token access network (token bus

or ring) from node to node, giving the node in possession of the token

exclusive access to the network for transmission. The token is passed on if it

has nothing to transmit, otherwise it is held until transmission finishes or a

time-out occurs.

Token Bus

A network architecture based on a bus topology and using a token based media

access method.


Token Ring

Network architecture using ring topology and a token based media access

method.

TOP

Acronym for Technical Office Protocol. Developed by Boeing, in line with the

OSI seven layer model, and designed to complement the GM MAP protocol.

Topology

Basic shape of an interconnection scheme for a network.

Transport Layer

Layer 4 of the OSI model. Providing end to end control of a communication

session once a path has been established, allowing processes to exchange data

reliably and sequentially, independent of systems communicating or their

location in the network.

Twisted-Pair

A cabling system in which internal conductors are twisted around one another

(in pairs) to minimise cross-talk interference effects.

Two's Complement

In a computer system, the two's complement of a number represents the

negative of that number. The two's complement is obtained by reversing the

status of every bit in a binary number and then adding 1 to the result. For

example, the two's complement of binary 01100011 is binary 10011101.

UART

Acronym for Universal Asynchronous Receiver Transmitter. A circuit used for

serial/parallel and parallel/serial conversion in an asynchronous

communications link.

UNIX

A widely used multi-tasking, multi-user operating system from which the DOS

system was initially developed.

USRT

Acronym for Universal Synchronous Receiver Transmitter. A circuit used for

serial/parallel and parallel/serial conversion in a synchronous communications

link.

User Program

A computer program running in a processor that performs information

processing for some specific use.


Virtual Terminal (VT)

A part of the protocol of the applications layer. It allows an application

program on one node to communicate with a remote terminal in a standardised

fashion.

VLSI

Acronym for Very Large Scale Integrated Circuit. A semiconductor fabrication

technology by which a high component density can be achieved on the bulk

material.

Wide Area Network (WAN)

Any public or private network which covers a large region.

X.25

CCITT communications recommendation defining the connection of a

computer to a packet switched network.

XOFF

Mnemonic for the "Stop transmission" character. It normally has an ASCII

value of decimal 19.

XON

Mnemonic for the "Resume transmission" character. It normally has an ASCII

value of decimal 17.

B-1

Appendix B

References

A Summary...

For basic concepts and direct instruction on RS-232 communications and hardware

hand-shaking, the following book is recommended as a good handbook:

CAMPBELL, J.

The RS-232 Solution.

Sybex Computer Books, 1986.

For advanced concepts and theory in computer networking (Local and Wide Area

Networks) the following book is recommended as a high quality text:

HALSALL, F.

Data Communications, Computer Networks and OSI.

2nd Edition, Addison Wesley, 1988.

B-2 D.J. Toncich - Data Communications and Networking for Manufacturing Industries

[1] BLANC, R.P., "Local Area Network Standards", Proc. IEEE Computer Society

COMPCON Spring 1984, pp252-260.

[2] BUCZKOWSKA, T. "Computer Networks",Journal of Electrical and

Electronics Engineering, IE Aust. & IREE Aust., Vol. 6, No. 4. December

1986, pp259-269.

[3] CAMPBELL, J., "The RS232 Solution", Sybex Computer Books, 1986.

[4] CLEAVELAND, P., "Local Area Networks for Industrial Control", The

Industrial and Process Control Magazine, August 1984, pp31-56.

[5] COHEN, P.A., "Trends in Flexible Manufacturing Systems",

Proc.CIMCOM'85 Conference,Anaheim California, April 1985, pp1-14.

[6] CROOKS, P., "Chip and Board Level Support for Token Bus and GM MAP",

Electronic Engineering, March 1986, pp37-42.

[7] CROWDER, R.S., "Enhanced Performance MAP", SME MAP/TOP Interface,

August 1986 & November 1986.

[8] CROWDER, R.S., "Putting MAP/TOP Products in Perspective", I&CS

Magazine, November 1986, pp49-69.

[9] FAROWICH, S.A., "Communicating in the Technical Office", IEEE Spectrum,

April 1986, pp63-67.

[10] GOFTON, P.W., "Mastering Serial Communications", Sybex Computer Books,

1986, pp135-137.

[11] HALSALL, F., "Data Communications, Computer Networks and OSI", Second

Edition, Addison Wesley, 1988.

[12] HAMMOND, J. L. and O'Reilly, P.J.P., "Performance Analysis of Local

Computer Networks", Addison Wesley, 1986.

[13] HOLLAND, J.R. "Factory Area Networks - The Key to Successful Factory

Automation Strategies", Proc. SME AUTOFACT Europe Conference 1983,

pp35-51.

[14] HUGHES, K. and Floyd, R., "Data Communications Standardization within

Manufacturing", Proc. IEEE Computer Society COMPCON Spring 1984,

pp266-269.

[15] IEEE, "Logical Link Control - IEEE 802.2", IEEE Publication 1985.

Appendix B - References B-3

[16] IEEE, "CSMA/CD Access Method - IEEE 802.3", IEEE Publication 1985.

[17] IEEE, "Token Bus Access Method - IEEE 802.4", IEEE Publication 1985.

[18] IEEE, "Token Ring Access Method - IEEE 802.5", IEEE Publication 1985.

[19] KAMINSKY, M. A., "Protocols for Communicating in the Factory" IEEE

Spectrum, April 1986, pp56-62.

[20] KAMINSKY, M., "MAP and TOP Information Package", GM MAP/TOP Task

Force Publication, 1986.

[21] KOLODZIEJ, S., "MAP Moves off the Drawing Board", The FMS Magazine,

October 1986, pp185-187.

[22] MICHELETTI, G.F., "Some Problems in Design of Flexible Manufacturing

Systems", Annals of the CIRP, Vol. 32/1/1983, pp417-421.

[23] MOTOROLA CORPORATION, "LONWORKS Product Line Brief", 1990,

Echelon Corporatioin, USA.

[24] NICOLETTI, G.M., "CIM: LAN Communications, Protocol Standards and

Real-Time Control", Proc. AUTOMACH 86, Sydney Australia, May 1986,

pp1-36.

[25] RAAB, A., " CAN - Controller Area Network", Elektor Electronics,

International Electronics Magazine, Volume 18, Number 203, September 1992

[26] RANDAL, D., "The Industrial Implications of Flexible Machining", Robotics

Magazine, November/December 1985.

[27] SCHATT, S., "Understanding Local Area Networks", Howard W. Sams and

Company, 1988.

[28] SINGH, I.M., "Implementation of Standard LAN Protocols - Tools for

Development and Verification", Proc. IEEE Computer Society COMPCON

Spring 1984, pp261-265.

[29] STRASSER, T.D., "MAP/TOP - Overcoming Barriers to Integration", Journal

of Electrical and Electronics Engineering Australia, IREE, IE Aust College of

Electrical Engineers, Volume 9, No. 4, December 1989

[30] TONCICH, D.J., "CNC Philosophy Outmoded", Process and Control

Engineering Magazine, September 1988, pp66-70.

B-4 D.J. Toncich - Data Communications and Networking for Manufacturing Industries

[31] TONCICH, D.J., "Development of a Flexible Transfer Line for Australian

Industry, Based Upon the Use of Standardised Machining Modules", Proc.

MECH. 88 Conference, Brisbane, May 1988.

[32] VAUGHN, R.L., "Integration at Work", Computers in Mechanical

Engineering, November 1985, pp43-49.

C-1

Appendix C

Index

C-2 D.J. Toncich - Data Communications and Networking for Manufacturing Industries

A

ACK/NAK protocols, 187

Acknowledgement of a Command, 64,66,192

Address bus, 24, 25

Address bus / data bus differences, 29

Address bus decoding logic, 25

Addressing, 25-28

Alpha-numeric characters, 14-17

American National Standards Institute (ANSI), 257, 258

American Standard Code for Information Interchange (ASCII), 14-17

Ampere's Law, 74

Amplitude Modulation (AM), 130

Annual production volumes against part variety, 52

Application Layer, 226, 228, 230

ASCII, 14-17

Asynchronous Balanced Mode (ABM), 236

Asynchronous communications, 107-110

Automated Guided Vehicles (AGVs), 52, 55

B

Bandwidth, 128

Base 16 (hexadecimal) number system, 9, 11

Base 2 (Binary) number system, 4, 6, 9, 10

Base 8 (Octal) number system, 8, 9, 10

Baseband, 128, 129

Basic Mode (BSC) protocol, 233-235

Baud Rate, 172

Bi-polar encoding technique, 104

Binary addition, subtraction, multiplication and division, 13

Binary Coded Decimal (BCD) system, 11, 12

Binary digit (Bit), 6

Binary number system, 9

Binary Synchronous Control, 233-235

Binary to hexadecimal conversion, 11

Binary to octal conversion, 10

Bisync Protocol (BSC), 233-235

Bit Error Rate (BER), 118

Bit-Oriented, 100

Block, 116

Block-Check-Sum (BCS), 116

Block-Check-Sum calculation, 117, 189, 191

Appendix C - Index C-3

Boeing, 270

Boole, George, 18

Boolean Algebra, 18-22

Expression Simplification, 21

Laws and Postulates, 22

Break-out box, 162-163

Bridges, 264-265

British Standards Institute (BSI), 257, 258

Broadband, 129

Bulk program storage facilities, 49

Bus Network, 212-213, 216, 218, 220

C

Cable concentrations, 218

Cable maintenance, 218

CAN Bus, 295-296

Carrier Detect CD line, 152-153, 157, 158

Carrier frequency, 128, 131

Carrier Sense Multiple Access with Collision Detection (CSMA/CD), 222-223

Central Processing Unit (CPU), 2, 62

Centronics Parallel Interface, 82-86

Channels (forward and reverse), 133

Character-oriented, 138

Character-Oriented systems, 100

CHIP ENABLE, 26-28

Circuit Switched Data Networks (CSDNs), 238-239

Circular buffer, 185-186

Clear to Send CTS, 145, 147, 149, 152

Clock encoding and extraction, 104-106

Closed architecture controllers, 251

Co-axial cable 133

Command packet, 190-193 Commité Consultatif Internationale de Telegraphie et Telephonie (CCITT), 144, 257, 258

Common Signal Ground COM (RS-232), 147

Communications protocol, 62-67

Computer Aided Design system, 49

Computer Integrated Manufacture (CIM), 242

Computer Numerical Control (CNC) machine tools, 43-48

Conducting cage or "shield", 77

Conducting communications link, 68-77

Constant System Monitor (CSM), 55

Contention (Network), 212


Continuous (analogue), 4

Conversion from Human form to computer form, 6-7

Conversion of base 10 numbers to different bases, 8-13

Convolution, 112

Cost effectiveness of dedicated production systems, 54

Cross-talk, 74-77

CSMA/CD, 222-223

Current loop (20mA), 177

Cyclic Redundancy Checks (CRCs), 119

D

Data bus, 2

Data Communications Equipment (DCE), 136

Data corruption, 50

Data frame, 108

Data Link Layer, 226, 229

Data Network, 212

Data packet, 158

Data packet assembly and disassembly, 228

Data Set Ready DSR, 145, 147

Data Signal Rate Selector DSR, 147

Data Terminal Equipment (DTE), 136,144

Data Terminal Ready DTR, 145, 147

DB25, 146

DB9, 146

Dedicated in-line transfer machine, 53

Dedicated manufacturing systems, 54

Demodulators, 133

Desktop publishing, 281

Device latency, 254

Differential communications system, 173

Differential encoding, 106

Digital circuits, 4

Digital Equipment Corporation, 266

DIN plugs, 146

Direct Numerical Control (DNC), 45

Dissection of Messages, 65

Double Side-Band Modulation (DSB), 128

Dumb terminals, 206-207


E

EBCDIC, 14

Echoing, 111-112

Electro-Magnetic Interference (EMI), 50,76

Electro-mechanical transmission, 108

Electronics Industries Association (EIA), 258

Enhanced Performance Architecture (EPA) MAP, 275

Error burst, 118

Error detection techniques, 111-120

Establishment of Link (Communication Phase), 64

Ethernet system, 266-268

European Computer Manufacturers Association (ECMA), 258

Even parity, 114,115,116

Expansion I/O modules (PLCs), 41

Extended Binary Coded Decimal Interchange Code, 14

F

Faraday's Law, 76

File dump, 51, 208

File server networks, 281-284

Filtering in the frequency domain, 125, 126

First-In First-Out (FIFO) Buffers, 185

Flexibility in production systems, 55

Flexible Manufacturing System (FMS), 55-58

Flexible parts transport techniques, 55

Flexible Transfer Line (FTL), 55

FMS control, 56, 57, 58

Fourier Transform, 121, 122

Frame, 108

Frame assembly and disassembly, 227-228

Frame Check Sequences (FCSs), 119

Frequency domain representation of signals, 122-129

Frequency spectrum, 122-129

Frequency-Shift Keying (FSK), 130, 131

Full-duplex link, 100

Fully programmable machining modules, 55


G

G-Code, 44

Gates (Boolean logic), 20

Gateways, 263

Gender (DCE or DTE), 144, 154

General Motors, 245, 269

General Purpose Instrumentation Bus (GPIB), 87

Generator polynomial, 119

GM MAP Task Force, 269

H

Half-duplex link, 100

Hand-shaking lines on communications links, 88

Hard-wire inter-locking, 47, 54

Hard-wired relay-ladder-logic control, 93

Hardware hand-shaking, 81; Hand-shaking in RS-232 links, 151-153

Hewlett Packard Instrumentation Bus (HPIB), 87

High Level Data Link Control (HDLC), 235

High-current cables, 76

Host computer, 41, 45

Human to computer interface, 11

HYPOLINK, 189

I

IEEE 802 committee, 258

IEEE 802.1, 258, 260

IEEE 802.2, 259, 260

IEEE 802.3, 259, 260

IEEE 802.4, 259, 260

IEEE 802.5, 259, 260

IEEE 802.6, 260

IEEE-488 "Instrumentation Bus", 87

Infinitely long parallel conductors (cross-talk), 74

Institute of Electrical and Electronic Engineers (IEEE), 258

Instruction set (CPU), 23

Integrated PLC Control, 49

Integrated Services Digital Network (ISDN), 241, 257

Intel, 266


Interfacing (to networks), 248, 249

Internal parallel data transfer, 87

International Standards Organisation (ISO), 226, 257

Interrupt programming, 32

Interrupts, 32, 33

Inverse Fourier Transform, 122

Issue of a Command and Command Qualifier, 64

J

Jam sequence (CSMA/CD), 223

K

Kaminsky, Mike, 245

Kermit" protocol, 206

Kirchoff's voltage law, 96, 121

L

LAN in a multi-vendor FMS environment, 58

Large Scale Integrated (LSI) circuits, 18

Light Emitting Diodes, 134

Line-Analyser, 163

Line-drivers, 95-96

Line-receivers, 95-96

Link control characters (DLE,STX,ETX), 188

Link Response Time, 253

Local Area Network (LAN), 212

Logical Link Control (LLC), 259

Logical ring, 223

Logical Units (LUs), 279

LON Bus, LON Works, 295 - 300

Lumped-parameter approximation, 69


M

Machining modules, 53

Magnetic flux-density, 75

Manchester Encoding, 105

MAP, 245, 269-278

Mapping (Memory), 26-28

MARK condition, 108

Mark parity, 139

Media Access Control, 259-260

Medium Scale Integrated (MSI) circuits, 18

Memory chip, 24-28

Metropolitan Area Networks, 260

Microprocessor chip, 2-4

Microsoft Corporation (Windows, Windows NT), 284

Millimetre wave, 168

MMS, 271, 272

MNEMONIC, 23

Modems, 133, 144

Modulation, 121-133

Mother-board, 2

Motorola Corporation (LON Works), 295 - 300

Multi-user, multi-tasking operating systems, 207

Multiplexer (Serial Port), 213

N

NAK, 188

National Bureau of Standards (NBS), 258

Network Addressable Units or NAUs, 279

Network Layer, 229

Network topologies, 216

Non Return to Zero (NRZ) encoding, 105

Non Return to Zero Inverted (NRZI), 106

Null Modem, 156-157


O

Octal number system, 8

Odd parity, 139

Open Systems Interconnection (OSI), 226-231

Optic fibre cables, 134, 135, 167

Original Equipment Manufacturer (OEM), 41

OSI Gateways, 263

OSI Networking, 260

P

PABX (Serial Port), 217

Packet, 116

Packet Switched Data Networks (PSDNs), 238, 241

Paper (mylar) tape, 49

Parallel data transfer, 87, 95-97

Speed advantages, 97

Parallel Exchange Network Units, 85

Parallel Network, 88

Parallel to serial conversion, 98

Parity checking, 114

PASCAL, 194

PC based ASCII word-processor, 49

Performance of a protocol, 183

Performance of Local Area Networks, 252-256

Permeance, 75

Phase Encoding (PE), 105

Phase-Shift Keying (PSK), 130-131

Physical Layer, 226, 229

Plug-in Compatibility, 37-38

Point to point serial links, 94

Post Telephone and Telecommunications (PTT) modem, 144

Presentation Layer, 230

Profile (Network), 276

Program execution in a microprocessor, 23-31

Programmable Logic Controllers (PLCs), 40

Protective Ground GND, 147

Public Data Network or PDN, 238

Public Switched Telephone Networks (PSTN), 238, 257


R

RAM chips, 26

Random Access Memory (RAM), 4

Read Only Memory (ROM), 4

Receive Data RXD, 145, 147

Request to Send RTS, 145, 147

Resource sharing, 281

Return-to-Zero waveform (RZ), 104

Ribbon cable, 162

Ring Indicator RI, 145, 147

Ring Network, 216, 218

Robot control systems, 45

Robots (Gantry), 55

Rotary transfer machines, 54

Routers, 264

RS-232C

Specification, 144-161

RS-422, 173

RS-423, 175

RS-449, 175

S

Selection of a networking topology, 220

Servo-drive controller, 43, 44

Session Layer, 226, 230

Shift-Registers, 98

Signal modulation, 121-133

Signal Quality Detector SQD, 147

Simplex Communication, 100

Skin effect, 73

Small Scale Integrated (SSI) circuits, 18

Software protocols, 80

SPACE condition, 108

Space parity, 139

Spreadsheets, 281

Star Network, 216, 217

Star node, 217

Start and stop bit/s, 108

Strobe signal, 84

SYN, 233


Synchronism, 102

Synchronous and asynchronous (induction) motor, 44

Synchronous Data Link Control (SDLC), 235

Synchronous serial transmission, 102-106

Synchronous/Asynchronous links - differences, 110

Systems Network Architecture (IBM) SNA, 279-280

T

Telegram, 116

Terminal Emulation, 206

Termination of Transmission, 65

Time domain representation, 123

Token passing scheme, 223

TOP, 269, 270, 271, 272

Total bandwidth of cables, 129

Transistor Logic (TTL) voltage levels, 83

Transmit Data TXD, 145, 147

Transparent mode, 233

Transport Layer, 226, 230

Travelling waves, 73

Truth tables, 20

TTL (Transmission Limitations), 95

TTL digital circuits, 108

Twisted-Pair Cable, 77, 165

U

UART control circuits, 169

Unbalanced Normal Response Mode (NRM), 236

Universal Asynchronous Receiver Transmitter (UART), 32, 138-141

Universal Synchronous Receiver Transmitter (USRT), 138-141

V

V.24 standard, 144

Very Large Scale Integrated (VLSI) circuits, 18, 276

Virtual Manufacturing Devices or VMDs, 272


W

Ward Christensen Signalling, 208

Windows, Windows NT, 284

Word-processing, 208

X

X.25, 240, 241

X.400 Message Handling Specification (MHS), 273

Xerox, 266

XMODEM, 208

XON/XOFF protocol, 184

WordPress.com · Author Dario Toncich was born in Melbourne Australia in 1960. He graduated (with...

Documents

Transcript of WordPress.com · Author Dario Toncich was born in Melbourne Australia in 1960. He graduated (with...