F T ra n sf o F T ra n sf o

PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
BNCE PUSAD
2.0

2.0
to

to
re

re
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c

'OPEN
ARCHITECTURE ROBOT
CONTROLLERS
ANDWorkcell
Integration'
Ritesh Bhusari

2006
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
1
he

he
k

k
lic

lic
C

C
11..00 IINNTTRROODDUUCCTTIIOONN
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c

New PC based open architecture robot controllers and the demand for

improved Man Machine Interfaces (MMI), increased flexibility, and lower

purchasing and operating costs are forcing a paradigm shift in the design,

integration, and servicing of robotic workcells. Improved MMI can reduce the

operator's programming time, shorten system error diagnostic times, and allow for

common user interfaces across many different systems. Lower purchasing and

operating costs can be achieved along with increased flexibility by using standard

hardware and software components. The use of standard PC components in a

robot controller opens the door for third party venders and allows for new workcell

development and customization opportunities. Robot and controller manufactures

have already begun to respond to customer demands by developing "open

architecture" controllers. Note the word "open" is not synonymous with the word

"universal." The phrase "open controller" refers to a controller that is based on

known or published specifications whereas; a "universal" controller refers to a

controller that can be used with several different robot arms. The degree of

"openness" may vary from one manufacture to the next. One definition of an open

architecture controller is "a controller with standard hardware and operating

system with open interface specifications." The PC is an example of an existing

open architecture system that is based on the original IBM® personal computer.

The PC hardware architecture is now a standard piece of computing hardware

that can be found in commercial products and industrial machine tools. The

Microsoft Windows® software is a standard operating system used in millions of

PC systems. Robot controller systems built around the PC hardware and the

Windows® operating system have numerous advantages over closed proprietary

robot control systems.

 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
2
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c
Proprietary (i.e., closed) robot controllers have improved over the years,

but still have many disadvantages relative to an open architecture controller. Most

proprietary systems are often viewed as "islands of automation" because of the

"closed" nature of these machines and their very limited compatibility and

connectivity with other systems. Some controllers use one or more common

CPU's (i.e., Intel 8088, Motorola 68000) in each system, but the rest of the

hardware and interface specifications are proprietary. Hardware performance

upgrades (i.e., CPU's, memory, etc.) are limited if even possible. Proprietary

system I/O peripherals and interface configurations are also used, which

compound the compatibility and connectivity problems of closed systems. For

example, one controller used a standard floppy drive and diskette. However, it

wrote the data to the disk using a proprietary format (i.e., did not use the standard

MS-DOS format), which prevented the operator from reading the data using

standard software on an office PC. Given these and numerous other limitations of

proprietary robot controllers, the request for open architecture control systems has

been made by end-users such as the "big three" automotive companies as well as

system integrators.

In the remainder of this paper, the integration of PC based open

architecture robot controllers and the Windows® operating system with robotic

workcells is presented. In Section 2.0, a comparison between open architecture

controllers and propriety controller systems is provided. Outlined in Section 3.0 is

an overview of new workcell development and servicing opportunities for the

system integrator of open architecture controllers.

 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
3
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c

22..00 O
OPPEENN A
ARRCCHHIITTEECCTTUURREE CCOONNTTRROOLLLLEERR SSYYSSTTEEM
MSS

Hardware and software developers of an open architecture controller

system open themselves to more market resources. They can experience lower

hardware development costs while enjoying a greater number of relatively

inexpensive configuration options. Likewise, software development groups can

benefit from the use of standard software development tools to give them more

flexibility and portability.

The hardware development cost of a proprietary robot controller can easily

outpace the development cost of an open system with the same functionality. The

basic components of a robot controller system are illustrated in the block diagram

in Figure. Shown in this figure, is a robot arm, power supply for the arm, teach

pendent, and controller.

The degree of openness in a robot controller may vary from one system to

the next. The robot system in the block diagram shown in Figure illustrates one

form of an "open architecture" system. For this system, the robot arm, power

system, and teach pendent are considered as proprietary components. The

 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
4
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c
controller and communication interface hardware and specifications are labeled as

the open architecture components. The "Open" label refers to the PC's open

hardware architecture, a standard operating system (e.g. Windows®), and

standard software libraries. The quotations around the word open signify that

there is a degree of openness (i.e., open relative to other systems, but how

open?). In this example, the external I/O communication interface is also based on

open architecture hardware (i.e., can-bus, Ethernet, com ports, parallel ports).

A PC based controller system can more easily integrate many

commercially available add-on peripherals such as; modems, Ethernet cards,

mass storage devices, card scanners, sound cards and other I/O and multimedia

devices. These types of peripherals are readily available at the household

consumer price level. Depending upon the controller cabinet design, commercial

rather than industrial PC equipment can be utilized. Well-ventilated, air filtered,

shielded cabinets help provide a "safe" electronic environment. Note, electronic

PC equipment is relatively no more susceptible to problems as electronic

proprietary equipment. Developers of a PC based controller system benefit from

development expenditures and resources spent by other companies.

In other words, by using PC technology in the robot controller, developers

are able to minimize costs by capitalizing on current and future hardware devices

in the market and on the drawing boards. The PC hardware is relatively

inexpensive and readily available (i.e., motherboards, CPU's, memory, etc.) and is

usually supplied by numerous venders (i.e., no more single source venders going

out of business). In addition, this hardware did not have to be individually

designed and tested by the developers of the controller. As a result, the human

resources and technical talent requirements to build and update a controller are

reduced.
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
5
he

he
k

k
lic

lic
C

C
om
The software developer of an open architecture system has an equally om
w w
w

w
w. w.
A B B Y Y.c A B B Y Y.c

great number of available market resources to take advantage of as the hardware

developer. Software development on a PC based system can be less expensive,

faster, and more portable than with proprietary systems. Standard development

tools (e.g. Visual C++®, Visual Basic®, Delphi®, etc.) can be utilized. These tools

are less expensive, allow for rapid prototyping techniques, and allow existing

source code to be recompiled and optimized for different CPU's and PC platforms.

In addition, the talent resource pool of people who are experienced with using

these programming tools and the PC platform is greater than the number of those

who are knowledgeable about a particular microprocessor and associated

compiler tools (i.e., proprietary development tools).

Portable controller software running on a PC based system can simplify

system emulation hardware, given that a PC is a PC. Simplified emulation

hardware leads to reduced training costs, improved simulation, and off-line testing

and debugging capabilities.

33..00 W
WOORRKK CCEELLLL IINNTTEEGGRRAATTIIOONN
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
6
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c

The system integrator is a company that designs and manufactures robotic

workcells and lines. They purchase a robotic system (i.e., arm and controller) and

integrate these arms with positioners, application specific technologies (i.e.,

welders, laser systems, water jet systems, vision systems, etc.), and safety

devices (i.e., light curtains and beams, fences, gates, etc.). System integrators

have limited opportunities to cleanly add custom hardware and software

components to proprietary robot control systems. However, the integrator has

relatively many opportunities to add components to open controller systems.

33..11 IINNTTEEGGRRAATTIIOONN OOFF W

WOORRKKCCEELLLL CCOOM
MPPO
ONNEEN
NTTSS

A PC based open architecture controller can be used with or without a

traditional programmable logic controller (PLC) hardware (i.e., SLC500, etc.).

When a PLC function is required for a given system, it can be integrated with the

controller. Workcell control logic can be implemented more easily and cheaper

when integrated with the robot controller. The robot controller has a high-level

programmable language that can be used to control many workcell functions. If

needed, a “Soft-PLC” (Software Programmable Logic Controller) can be installed

on the system. Placing a Soft-PLC in the robot controller focuses the cell control

to a centralized location. PC based PLC's can still provide the familiar

programming control logic interface for the maintenance personnel on the factory

floor. A Soft-PLC also reduces the physical wiring interconnections between

traditional robot controllers and typical hardware PLC. As future enhancements

are made, Soft-PLC can be easily upgraded on the controller. Physical I/O (i.e.,

inputs and outputs) are no longer related to a few proprietary choices because the

open architecture controller can communicate with standard bus systems.

Many standard workcell sensors, which include; light curtains, gate

switches, and tooling proxies, can be integrated and controlled directly by the
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
7
he

he
k

k
lic

lic
C

C
om
robot controller software, or controlled by a reside Soft-PLC program. Other om
w w
w

w
w. w.
A B B Y Y.c A B B Y Y.c

workcell sensor components, such as real-time vision seam tracking systems,

through-the-arc seam tracking systems, and vision systems for part detection and

placement can be implemented in open architecture controllers. A standard PC

system will have several ISA and PCI slots open which can be used for special

vision hardware. Arc data monitoring hardware and software could be

incorporated into the controller itself. Software modules for collecting data can be

resident on the robot controller platform or an external processing board

connected to the controller using a standard communication interface. Processing

of the data can take place on the controller or exported to another computer for

post-processing. The data manipulation software can be written by the integrator

or end user using standard off-the-shelf development software or even purchased

from a third party source.

33..22 N WD
NEEW DEEVVEELLOOPPM NTT O
MEEN OPPPPOORRTTUUNNIITTIIEESS

Robotic systems are designed for and applied to a variety of tasks in the

work area. These tasks include; spot and

arc welding, material handling, gluing,

water and laser cutting, and others.

Manufactures of robot systems

traditionally develop a core set of

controller functions that only provide the

robot with a basic set of motion control

and programming functions. When a robot is applied to perform a particular type

of job (i.e., arc welding), additional functionality must be added to the robot

system. For example, some welding related functions (i.e., wire feed rate, weld
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
8
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c
voltage, etc.) must be correlated to the motion of the robot arm or more specific,

the welding torch. In most cases, it is expected that these functions be integrated

into the user interface (i.e., the teach pendent).

Therefore, a given line of robots from a single manufacture may be applied

to several types of applications and tasks that may require several different user

interfaces. When applying a proprietary system to a new job, which requires a set

of unique controls or a user interface, only the robot manufacture can add these

features to the controller software. The system integrator must go back to the

manufacture of the propriety controller to add more functionality or to correct

problems in the existing controller software. In addition, changes to the controller

may only be implemented if they are viewed as a worthy investment of resources

and also viewed as needed for the good of all who will buy the new controller

interface (i.e., custom functions and user interfaces are unlikely for a given system

integrator). On a PC based open architecture system, which uses a standard

operating system (e.g. some version of Windows®), the system integrator has the

ability to develop new functions and customized user interfaces. The "value added

components" refer to these unique customizable software and hardware modules

than can be added by the system integrator with little to no help from the

developer of the controller. The system integrator reaps many of the same

benefits as the developer of the robot controller software. For example, most robot

controllers do not have a built in production screen.

A "production screen" is an information screen for the operator to be used

during the production cycle to display pertinent system and production

information. With an open architecture controller, the system integrator could

develop a custom production screen and other "value added" components (e.g.

built-in electronic documentation, system error notification and diagnostic

 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
9
he

he
k

k
lic

lic
C

C
w om w om
w

w
modules, statistical packages, etc.) for a given type of job or even for a given
w. w.
A B B Y Y.c A B B Y Y.c

customer.

As mentioned in earlier, the developer of a PC based system is open to an

array of low cost, commercially available hardware peripherals. Likewise, the

system integrator can take advantage of these resources to provide the end-user

with relatively low cost parts. More importantly, the system integrator can easily

upgrade the robot controller system by just plugging in standard, off-the-shelf

components (i.e., a faster CPU, more memory, faster modem, etc.).

33..33 IIM
MPPRRO DM
OVVEED MAAIINNTTEENNAANNCCEE SSEERRVVIICCIINNGG
System integrators using an open architecture PC based controller system

can reduce the short and long term expenses incurred in their service department,

change the way service is conducted, and respond to the customer quicker and

more directly than ever before while reducing costs and losses for each party.

Typically, the system integrator builds up a robot workcell and ships the system to

a customer. Included with the system, may be a service contract that gives a

warranty covering some extended period of time. The number of service calls by

the customer to the system integrator is dependent upon the customer's prior

robotic experience and the amount of training received on the new system.

Service calls made within the warranty period are recorded as an expense for the

integrator otherwise they are an expense for the customer. Traditionally, when the

customer has a problem they call for service. If the system integrator is unable to

correct the problem via vocal instructions over the telephone, they must send

service personnel to the site. In the mean time, the customer is losing because of

lost production time (i.e., losing finical and competitively--market influences) and

the system integrator is losing money because of the expenses of sending a

representative into the field (i.e., rental cars, airline tickets, etc.).
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
10
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c
It is well known that some problems leading to a field service call are

corrected shortly after the service person arrives at the site. The expenses and

lost revenue by the integrator and customer can be greatly reduced by changing

the way service calls are conducted. This can be achieved by taking an advantage

of the available hardware devices and software programs that are readily

available for the standard PC system. For example, the connectivity possibilities,

when using either a modem or an Ethernet card in conjunction with commercially

available peer-to-peer graphical communications software packages, provide

service personnel with new tools to perform their job quicker, easier, and cheaper,

by eliminating the need to leave their desk.

This remote tele-robotic servicing approach is one of the business changes

that are emerging as part of the shift to open architecture controllers. Many

customer service calls can be solved by simultaneously conversing with the

customer and actively viewing and controlling the customer's teach pendent

hundreds of miles away. A service person physically located at either the system

integrator's site or locally in-house to the customer would have the ability to

interact with the robot controller (without moving the robot -- i.e., safety issue). In

some cases, live videos snapshots of the robotic work cell may be needed to

communicate some work cell problems to the service person.

With these tools, they would be able to visually instruct the operator on the

procedural "how-to's" with almost everything on the teach pendent. They can also

check system errors and log files, install new or updated software modules, and

perform many other functions.

CCOONNCCLLUUSSIIOONN
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
11
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c

Presently, thousands of PC based robot controllers, developed by KUKA,

are now in production and a considerable amount of research and development

efforts are being expended by other manufactures. The customization and

development opportunities for system integrators dramatically increase when

using open architecture robot controllers which are based on standard PC

hardware and the common Windows® operating system. System integrators are

now able to provide improved man-machine interfaces, improved

communications, customer service, and productivity.

 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
12
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c

BBIIBBLLIIOOGGRRAAPPHHYY

Ø Fiedler P. and Schilb C., "Open Architecture Systems for Robotic

Workcells," IWACT 1997 Conference Proceedings, Columbia Ohio, 1997

Ø Specification Sheet, KUKA Roboter GmbH, "KR C1, Kuka Robot Control

System," Augsburg, Germany, 1996.

Ø Advertisement, Nimbl Incorporated, Robotics World: The end user's

magazine of flexible automation, Vol. 15, Number 3, pg 5, Fall 1997.

Ø News Release, RWT - Robotic Workspace Technologies Inc., "Universal

Robot Controller," Contact: Sandra Brooks, Fort Myers Beach, FL, July

1997.

Ø Robotics World: The end user's magazine of flexible automation, Vol. 15,

Number 3, Fall 1997.

Ø Brochure, Hitachie 3242Y800 704, Hitachie LTD. Narachino Works, Japan

Ø Service Manual, ASEA Service Manual, 6397-020-105, CK 09-1564E Sept.

1987

Ø Brochure, Accudata Inc., 9700 Myers Road, Jackson, IM., Sales literature.

Ø Technical Description, Servo-Robot Inc., 1380, Graham Bell, Boucherville,

Quebec, Canada J4B 6H5

Ø Technical flyer, Technosoftware AG Germany

Ø Technical Documentation, Sybase Inc., 15721 College Blvd, Lenexa, KS

66219
 F T ra n sf o F T ra n sf o
PD rm PD rm
Y Y
Y

Y
er

er
ABB

ABB
y

y
bu

bu
2.0

2.0
to

to
re

re
13
he

he
k

k
lic

lic
C

C
w om w om
w

w
w. w.
A B B Y Y.c A B B Y Y.c

A
ACCKKNNOOW
WLLEED
DGGEEM
MEEN
NTT

We take this opportunity, to express our deep sense of gratitude towards

Prof. B. B. Patel (H.O.D. mechanical) and Prof. N. S. Walimbe (Mechanical)
PVG’s COET, for their expert guidance during the preparation of this paper
presentation.
We are also thankful to Prof. D. S. Patil (mechanical) PVG’s COET, Pune &
the entire library staff without whom; we wouldn't have been in a position to
present this paper.
We are also grateful to MESA for giving us the opportunity to present this
paper.
We also express our thanks to all of them who directly or indirectly have
helped us to prepare this presentation.

OMKAR V KARANDIKAR
AMIT H KHAMKAR
(B. E. MECHANICAL)