Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

BNCE PUSAD
2.0

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

C

lic

k

he

re

to

w

w.

A B B Y Y.c

om

om

w

w

'OPEN ARCHITECTURE ROBOT CONTROLLERS ANDWorkcell Integration'
Ritesh Bhusari

2006

Y

Y

Y

PD

F T ra n sf o

rm

w

w.

A B B Y Y.c

om

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.

1..0 INTRODUCTIION 1 0 INTRODUCT ON

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

1
w

k

he

om

w

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

2
om
w

k

he

w

w.

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.

om

w

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

w

w.

A B B Y Y.c

om

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.

2..0 OPEN ARCHIITECTURE CONTROLLER SYSTEMS 2 0 OPEN ARCH TECTURE CONTROLLER SYSTEMS

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

3
w

k

he

om

w

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

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

4
om
w

k

he

w

w.

A B B Y Y.c

om

w

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.

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

5
om

k

he

w

w.

A B B Y Y.c

The software developer of an open architecture system has an equally 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.

om

w

w

3..0 WORK CELL INTEGRATIION 3 0 WORK CELL INTEGRAT ON

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

6
om
w

k

he

w

w.

A B B Y Y.c

om

w

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.

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

3..1 INTEGRATIION OF WORKCELL COMPONENTS 3 1 INTEGRAT ON OF WORKCELL COMPONENTS

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

7
om

k

he

w

w.

A B B Y Y.c

robot controller software, or controlled by a reside Soft-PLC program. Other 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.

om

w

w

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 traditionally of develop robot a core systems set of

3..2 NEW DEVELOPMENT OPPORTUNIITIIES 3 2 NEW DEVELOPMENT OPPORTUN T ES

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

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

8
om
w

k

he

w

w.

A B B Y Y.c

om

w

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

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

9
om
w

k

he

w

w.

A B B Y Y.c

modules, statistical packages, etc.) for a given type of job or even for a given 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.).

om

w

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.).

3..3 IMPROVED MAIINTENANCE SERVIICIING 3 3 IMPROVED MA NTENANCE SERV C NG

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

10
om
w

k

he

w

w.

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.

om

w

CONCLUSIION CONCLUS ON

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

11
om
w

k

he

w

w.

A B B Y Y.c

om

w

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.

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

12
om
w

k

he

w

w.

A B B Y Y.c

om

w

Ø 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

BIIBLIIOGRAPHY B BL OGRAPHY

Y

Y

Y

PD

F T ra n sf o

rm

Y

PD

F T ra n sf o

rm

er

er

ABB

ABB

y

bu

bu C lic k he re to
w

y
w.
A B B Y Y.c

2.0

2.0

re

to

C

lic

13
om
w

k

he

w

w.

A B B Y Y.c

om

w

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)

ACKNOWLEDGEMENT ACKNOWLEDGEMENT

Sign up to vote on this title
UsefulNot useful