AS 116.

140L Juhani Heilala 2001 1

Open Real-time Robotics Control - PC Hardware,

Windows/VxWorks Operating Systems and
Communication
Juhani Heilala
VTT Manufacturing Technology
P.O.Box 1702, FIN-02044 VTT, Finland
Juhani.heilala@vtt.fi

Abstract
In the modern robotics systems the users must combine hardware, operating
systems and network. Robot controller is a real-time operating system with multiple
tasks and processors, the hardest real-time requirements are in path control, there
coordinated movements of multible axes and other tasks must be controlled. The
robotics society is going to increase PC’s as part of the control platforms. Same time
modularised, distributed, open control system are more and more used, this increased
the importance of real-time communication. The article covers the recent
development on open robot control architecture based on PC, use of real-time
operating system VxWorks and Windows 95/NT in the same control system and
importance of internal and external communication in robot workcells.

1 Introduction
1.1 What is real-time?
The principal responsibility of a real-time (RT) operating system (RTOS) can be
summarized as that of producing correct results while meeting predefined deadlines
in doing so. Therefore, the computational correctness of the system depends on both
the logical correctness of the results it produces, and then timing correctness, i.e. the
ability to meet deadlines, of its computation.
Hard real-time (HRT) operating systems can be thought as a particular subclass
of RT systems, in which the lack of adherence to the above mentioned deadlines may
result in a catastrophic system failure. A RT application can be modeled as a set of
cooperating tasks. These tasks can be classified according to their timing
requirements, as hard real-time (HRT), and not real-time (NRT). A HRT task is a task
whose timely (and logically correct) execution is labeled as critical for the operation
of the whole system. The deadline associated to a HRT task is pronounced hard
deadline. Consequently, it is assumed that the missing of a hard deadline can result in
a tragic system failure. NRT tasks are those tasks which exhibits no real-time
requirements (e.g. system maintenance tasks that can run occasionally in the
background). [Brega and Honegger 1998]
The taxonomy of application tasks can de further expanded with the terms
periodic, aperiodic and sporadic. Periodic tasks are tasks which enter the execution
state at regular intervals of time, i.e. every T time units. These tasks are usually
associated with hard deadlines. Aperiodic tasks are tasks whose execution time cannot
AS 116.140L Juhani Heilala 2001 2

be anticipated, as their execution is determined by the occurrence of some internal or

external events. These tasks are usually NRT tasks. Finally, aperiodic tasks bound to
hard deadlines are termed sporadic tasks, e.g. tasks dealing with the occurrence of
system failures (exceptions), or prioritized responses to some event. With the above
classifications in mind, one can observe that the principal responsibility of a RT
operating system is to guarantee that each individual execution of each application
task can meet the timing requirements of that task. However, it is worth noting that, in
order to fulfill that responsibility, the objective of a RT operating system cannot be
stated just as that of minimizing the average response time of each application task;
rather the fundamental concern of a RT operating system is that of being predictable.
[Brega and Honegger 1998]
Two general paradigms for the design of predictable RTOSes can be found:
Event-Triggered (ET) and Time-Triggered (TT). In ET RTOSes any system activity is
initiated in response of the occurrence of a particular event, caused by the system
environment (mainly software or hardware interrupt vectors). In TT RTOSes system
activities are initiated as predefined instants of the globally synchronized clock recur
(scheduling, dispatching of events). [Brega and Honegger 1998]
In the robotic systems there are all the classes presented above. Path planning and
servo-loops are periodic (Time-Triggered), the sensor events are usually aperiodic,
emergency signals and some other sensor events are sporadic (Event-Triggered)

1.2 Open control

The promise of open control can also be a curse. Control engineers have the
ability to choose hardware, software, and networking products that best match
application requirements. Since all vendors pledge their products are “open,” this
automatically means there will be no problems hooking it all together and making it
run with no more than the usual start-up bugs. Actually, this could be a bad
assumption. The benefits are there, but making it work can be a trek through a jungle
maze with many traps and engineer-eating beasts along the way. [Mintchell 2000B]
A control system contains hardware, software, and networking components.
Each component must be evaluated both separately and how each acts within a
system. The controller platform contains plug-in cards ranging from video to
communications to special purpose like vision or motion. Choice of an operating
system (OS) is crucial whether the readily available Microsoft Windows NT, one of
the real-time operating systems available or even Linux. Several software applications
will be running on top of the OS, and communications to other applications has
become mandatory. Network communication to I/O devices and information systems
requires choices of physical media as well as protocols and configuration software.
[Mintchell 2000B]

1.3 Robotics
Robots usually come in one of three varieties: articulated arm, SCARA, and
gantry. Articulated arm robots are most often seen, for instance, in long automotive
assembly spot welding lines. SCARA robots are fast, multi-axis, pick-and-place
machines often used for packing and assembly of small parts. Gantry robots
sometimes cover large areas and are often capable of precise handling of heavy
payloads. These are often found on machining lines handling parts going into and out
AS 116.140L Juhani Heilala 2001 3

of automatic mills and grinders. They are also useful for certain part-picking
operations.
A robotic system is not unlike a motion control system with a controller, servo
module, drive amplifier, and motors with feedback. Kinematics is the difference.
Robotic control usually involves complex movements, coordinating up to 6 or more
axes of motion. Sometimes guiding the tool over the workspace is challenging.
Integration of vision systems with robotic control has been used for many years, but
use is increasing as both technologies become easier to integrate and applications
become more challenging. Some manufacturers cite complexity of kinematic
algorithms as a requirement to maintain robot control of its own processor. Advancing
technologies that are shrinking chip size and packing more components on a smaller
printed circuit board are permitting a complete controller on a PCI board. Look for
several companies to have computer plug-in cards that control robot motion while the
PC handles all the human-machine interface, data collection, and communication
chores. [Mintchell 2000A]
Most people agree that open systems relate to PC technology. Reasons most often
cited include taking advantage of ever-increasing power of PC microprocessors and
software. Add in economies of scale of the PC market - sales much larger than the
industrial market - and these larger markets usually mean lower prices for chips and
networking equipment. Another reason lies with enterprise information needs.
Managers are demanding accurate manufacturing information as quickly as possible.
Of course, the best information comes directly from machine controllers. Since plants
generally are now wired with a PC client-server network over Ethernet, machine
control connectivity to that network becomes mandatory. [Mintchell 2000A]
Using a common foundation like Windows leads to another benefit -
communications. Standards like OPC and tools like COM, DCOM, and ActiveX
objects mean robots can now be more easily integrated into the larger factory process.
[Mintchell 2000A]

2 System architectures for industrial robot controllers

The different types of system architecture used in modern controllers for industrial
robots may be assigned to the following categories [Schneider 1999]:
- Company-specific hardware and operating system software, PC could be used as a
user interface to the system
- PC hardware and company-specific operating system software
- PC hardware and Windows 95 operating system (or DOS) with the VxWorks real-
time expansion as a solution with two motherboards
- PC hardware and Windows 95 operating system with the VxWorks real-time ex-
pansion as a single-processor solution.

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
AS 116.140L Juhani Heilala 2001 4

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
[Fiedler and Schilb 2000].
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 [Fiedler and Schilb 2000].

Figure 1. Block diagram of an example PC based open architecture robot controller

system. [Fiedler and Schilb 2000].

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 1. 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 controller and
communication interface hardware and specifications are labeled as the open
AS 116.140L Juhani Heilala 2001 5

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, and parallel ports). [Fiedler and Schilb 2000]

2.1 Company-specific hardware and operating system software

With system architectures featuring company-specific hardware and operating
system software, it is often possible to connect an additional PC with Windows (95 or
NT) to the robot controller. Installed on this PC may be, for example, graphics-
supported application packages (e.g. a user interface for palletizing) as the hand-held
programming unit for these robot controllers does not have the graphics capabilities
required for this. Bus interfaces or other interfaces for communication with
subordinate or higher-level control units require special plug-in cards which have
been developed for the platform in question. [Schneider 1999]

2.2 PC hardware and company-specific operating system software

The same applies to systems with PC hardware and company-specific operating
system software. Once again, the graphics capability of the associated hand-held
programming unit is greatly restricted by the operating systems, which have been
little developed in this regard. However, in such cases the Windows NT operating
system is also run on the PC hardware. This means the hardware requirements are
correspondingly high: an Intel Pentium P200 with 48 Mbytes of RAM. Here
Windows NT is not used directly for control or operation, but as a platform for
additional software modules (e.g. a simple simulation), displayed using an additional
monitor, and for the integration of peripherals (e.g. an image processing system).
[Schneider 1999]

2.3 PC hardware and Window operating system

Windows is not really suitable as the sole operating system on which to base
control and operation because of the requirement for real-time capability and
openness. Although Windows NT does have a real-time capability within certain
limits, there are still drawbacks with regard to the ability to integrate additional
hardware and software modules. This is possible with Windows 95, but here the real-
time capability cannot be guaranteed. This problem is resolved by using the real-time
operating system VxWorks alongside Windows, Figure 2. [Schneider 1999].
For this, in system architectures with PC hardware with two motherboards, the
two operating systems Windows 95 (or DOS) and VxWorks work on their own
motherboards, which communicate with each other using ISA/PCI. VxWorks is used
as the basis for processing all real-time relevant tasks (path planning, etc) and
Windows 95/NT (or DOS) as the basis for the operator control. Operator control and
programming are performed using an MF2 keyboard and a standard monitor as there
is no hand-held programming unit. This system architecture does not have a user
interface: instead, libraries are supplied under Windows 95/NT (or DOS) which the
customer may use to program a user interface. The manufacturer of the controller may
also do this as one of his services.
AS 116.140L Juhani Heilala 2001 6

Figure 2. Trend in control technology, standardized software and hardware.

[Schneider 1999].

2.4 Workcell Communications

2.4.1 Intra-Workcell Communications [Fiedler, and Dehof. 1997]
An older, but typical high-level control configuration for robotic workcells is a
control scheme that is centered around a system programmable logic controller (PLC).
In these configurations, the PLC is defined as a “master” controller that is responsible
for workcell activity by controlling several “slave” components. The slave
components are the system sensors, actuators and the robot controller. In these control
schemes, the robot controller is usually operated as a slave device that communicates
with the master PLC through its built-in binary I/O’s. The robot controllers were
optimized for path planning and motion control. Most companies spent little to no
effort on system interfaces and communication devices, MMI’s, diagnostic functions,
or management tools. This PLC centered control scheme was so common that the
vision of independent robot controllers communicating with each other as well as
communicating with higher level factory automation devices wasn’t pursued.
PC based robot controllers are now being configured as the control master of the
workcell. In many cases, the PC controller is replacing all PLC’s in the workcell and
performing both the traditional robot tasks as well as other system control tasks. In
other configurations, the robot controller is the master device controlling the several
slave devices where one of these slave devices is a PLC. Despite the fact that the
present day robot controller has the ability to manipulate multiple fieldbusses, vision
systems, and other devices with a single CPU, it is hard for many people to change
and accept this newer technology. Not that PLCs are no longer necessary, but the way
they operate within a workcell is changing. The communication capabilities of PLCs
concerning data exchange were developed in the past and only paid attention to the
interface between PLC and factory automation systems.
AS 116.140L Juhani Heilala 2001 7

The implementation of a PC based controller brings standard devices to the

design table and allows us to forget about some of the technical and economical
questions that were asked in the past. With a proprietary system, ethernet interfaces
are usually out of the question. If you consider a PC based controller running
Windows® , it simply is a standard feature. The same applies to fieldbus systems
where every manufacturer supplies PC compatible hardware that usually comes
available with an ISA or PCI interface. Vision systems were often a big problem for
robot controller manufactures. However, today there is an increasing number of
commercially available frame grabbers and video systems for the PC platform.

2.4.2 Levels of Communication [Fiedler, and Dehof. 1997]

The basic robot controller is now equipped with hardware to control their own
peripheries, such as field busses (i.e., DeviceNet, Interbus, Profibus, etc.). However,
the PC based robot controller is also capable of communicating with more complex
peripherals, such as commercially available vision systems, bar code readers, pagers,
and glue controllers. Communication interfaces are using standard hardware and
software devices making it easier to interface to outside systems and thus, allowing
the use of improved development, diagnostic, maintenance, and statistic tools.
The next communication level is the exchanging of information between robot
controllers in the same workcell and the exchange of information with outside office
PC’s. In a workcell configuration, it is no longer necessary to have a master controller
(e.g., PLC) receiving information from one controller, processing it and forwarding it
to the others. Despite the fact that most systems are using proprietary data formats,
most of them use standard protocols and interfaces. The TCP/IP communication
protocol has become a kind of a de-facto standard for this type of interfacing. The
TCP/IP protocol is a well known, well proven communication protocol. There are a
number of TCP/IP based programming and diagnostic tools available for nearly every
conceivable platform which can be used to transfer data between devices within a
given workcell, as well as between different systems on the factory floor or in the
office. In addition to ethernet devices, the PC based robot controller usually comes
with other standard built-in communication hardware (i.e., serial ports, parallel ports,
universal serial bus, and others).
Another level of communication within the workcell is the transfer and usage of
process data (e.g., welding related processes). Offset information from one or more
touch senses can be compiled, stored, and used to make the controller more
intelligent. Many systems use touch sensing to find weld joints and to intelligently
determine the size of the part. However, not many systems collect the touched offset
data to make some intelligent decisions based on joint by joint offset statistics. For
example, a robot can be programmed to intelligently touch sense selected joints of a
given part over time in order to increase cycle time (i.e., because of variations in pre-
welded parts from one batch to the next). Another example use of statistical offset
data, is to collect and communicate this information to the workcell managers to give
them knowledge of the consistency of the pre-welded parts. Similarly, the methods
and information exchange approaches used with the touch sensing process can be
used with the seam tracking and other workcell processes.
AS 116.140L Juhani Heilala 2001 8

3 Real-Time features to Windows [Munz, 1997], [LP

Elektronik 1999]
3.1 MS-Windows
MS-Windows is a widespread graphical user interface for IBM compatible PCs.
Due to the absence of real time ability it is hardly suitable for industrial applications.
The advantages of MS-Windows however, are to be found in its variety of
applications and the acceptance of the users. Finally, a lot of low-priced user
programs for MS-Windows are available. To make MS-Windows useful also for
industrial real time applications, a way has been developed, which eliminates the
disadvantages of MS-Windows, without giving up its advantages.

3.2 VxWorks
VxWorks is a widespread real time operating system, produced by Wind River
Systems. Several versions of VxWorks are available for different processor-
architectures (Motorola 68k, Intel 80x86, Sparc, AMD 29k and others ). VxWorks
normally runs standalone on one processor and controls all resources for itself (RAM,
ROM, I/O, and so on).

Figure 3. Typical communication method between VxWorks and Windows, two

separate processors. [LP Elektronik 1999]

3.3 LP-VxWin: VxWorks and MS-Windows together on one PC

The LP-VxWin product family combines both operating systems, so they can run
concurrently on the same PC and the user can get the best of both worlds. For LP-
VxWin the kernel of VxWorks for Intel 80x86 processor has been adapted, in order to
run VxWorks and MS-Windows concurrently on the same 80x86 processor. Of
course, VxWorks has a higher priority as MS-Windows. As long as at least one
VxWorks task is active, the processor’s execution time is available exclusively for
VxWorks. In other words, only if all VxWorks tasks have given up their execution
time, MS-Windows will be reactivated. This is done when VxWorks falls into the
kernel idle loop.
AS 116.140L Juhani Heilala 2001 9

Figure 4. VxWorks and Windows running in same PC.

3.3.1 LP-VxWin/RTAcc
LP-VxWin/RTAcc requires a cheap, passive additional hardware, the LP-Real
Time Accelerator (RTAcc). Using the RTAcc, a 100% real time ability can be
guaranteed. The main function of the RTAcc is to accept normal interrupts from the
ISA-Bus and to generate a Non Maskable Interrupt (NMI) instead. The NMI
cannot be disabled by MS-Windows, so 100% real time ability can be guaranteed.
VxWorks will be activated by the NMI within a few microseconds depending on the
PC processor speed.

Non Maskable Interrupt (NMI),

cannot be disabled by MS-Windows

Figure 5. LP-WIN and real-time accelerator card.

AS 116.140L Juhani Heilala 2001 10

Figure 6. Real-time Accelator card

The LP-Realtime Accelerator mainly consists of a simple passive logic chip (44
Pin EPLD). This device supports the functionality of a Programmable Interrupt
Controller (PIC) for the Non Maskable Interrupt (NMI) and a 12 Bit Timer on one
chip. It can receive up to seven ienormallr interrupts, i.e. from other ISA-Bus
hardware over its seven hardware input pins. Some or all of them can be enabled by
software over eight addresses in the I/O address-room of the PC. If an interrupt is
enabled and received by the LP- RTAcc chip, a NMI will be generated. Additionally
the LP-RTAcc chip contains a 12 Bit Timer, which is clocked by about 6.7
microseconds on the evaluation board. With that feature, periodically realtime
interrupts can be programmed with cyclic times between 6,7 microseconds and 27,4
milliseconds. This timer is used by the VxWorks system ticker. The LP-RTAcc chip
is available not only on the evaluation board. It also can be ordered stand alone with a
data sheet. The user can design this chip into a new developed PC plug in board. A
third way to use the LP-RTAcc chip is to employ PC motherboards, where this
technology is already on board.

Figure 7. Principle schematics of LP-real Time Accelerator board.

AS 116.140L Juhani Heilala 2001 11

The NMIs, generated by the LP-RTAcc chip will interrupt MS-Windows or

VxWin tasks within a few microseconds and call the corresponding VxWorks
Interrupt Service Routine. After returning from the ISR, but before returning to MS-
Windows, the system checks, if there are any tasks ready to run. If this is the case
(one or more tasks has been activated with-in the ISR), the system will not return to
MS-Windows, but it will activate the corresponding VxWorks task, first. Those tasks
keep on running until all of them will be suspended again. The system then enters the
kernel idle loop of VxWorks, which will lead to a return to MS-Windows. Since MS-
Windows only will be activated, if all VxWorks tasks are idle, one can say that MS-
Windows runs as the idle task of VxWorks.

Few microseconds

Figure 8. Windows is running on VxWorks idle loop.

3.3.2 LP-VxWin LC20

LP-VxWin LC20, is a short sized PC plug-in board (16Bit ISA-Bus) with a
Motorola 68020 CPU (25Mhz) and a local 8MB of RAM. VxWorks runs on this
additional processor, so the PC processor is completely relieved from the real time.
The communication with MS-Windows is done via a TCP/IP-NDIS shared memory
driver over the ISA-Bus. Due to its Bus-Master-DMA ability, VxWorks running on
the LC20 can directly access other PC hardware via the I/O or memory channel of the
PC. It also can receive interrupts from other boards. Memory map of MS-Windows
and VxWorks with the LC20-version MS-Windows "sees" the VxWorks-memory
through a 64-KB window, which can be placed in segment D000 or E000. This
window can be moved over the entire memory of VxWorks.

3.3.3 LP-VxWin/LITE
LP-VxWin/LITE works only with Windows NT 4.0 and doesn't require any
additional hardware. If the Timer or an ISA Bus interrupt is used from VxWorks the
Interrupt Service Routine from the NT Kernel Mode Driver will call the Interrupt
Service Routine from VxWorks. Under Windows NT 4.0, there was measured
AS 116.140L Juhani Heilala 2001 12

interrupt latency times up to two milliseconds. However, even this time can not be
guaranteed. In this procedure only soft real time ability can be guaranteed.

3.4 Communication between VxWorks and MS-Windows

The TCP/IP-protocol can be used for communication between VxWorks and MS-
Windows through shared memory areas. For this purpose two corresponding network
drivers have been developed for each side, MS-Windows and VxWorks. Over the
commonly accessible shared memory area, both systems can exchange data as they
would do via an Ethernet line. Alternatively a direct TCP/IP connection to systems
outside of the PC can be installed using an additional Ethernet hardware. For LP-
VxWin an Ethernet board, which is supported by a standard VxWorks driver can be
plugged into the PC. Usually this will be a second Ethernet board beside the first one,
which is used by MS-Windows. VxWin directly can control this Ethernet board.
Using the standard TCP/IP protocol, any additional VxWorks products can be
used together with the VxWin product family, e.g. the development system Tornado
on the PC or the VxWorks development system for UNIX. Source level debugging is
possible as well as the use of WindView or others. For the Run Time System, TCP/IP
sockets or Remote Procedure Calls (RPC) can be used for communication between
MS-Windows and VxWorks programs. From the point of view of the VxWorks or the
MS-Windows applications there is no difference between running under VxWin on
the same PC or running on two different systems as usual.

4 Open robot controller with PC hardware

Robot controllers based upon the standard Personal Computer (PC) open
architecture hardware and the common Microsoft Windows® operating systems are
dramatically changing the robotic industry. The robotic industry is beginning to
experience the benefits and opportunities from the inevitable paradigm shift in the
design, integration, and servicing of robotic systems. The desire for improved Man
Machine Interfaces (MMI), increased flexibility, and lower costs has motivated some
system integration companies to pursue new PC based open architecture robot
controllers. [Fiedler and Schilb 2000]. (see also Figure 1 and Figure 2).
Robot control has been a holdout to the PC revolution in industrial automation
because of the real-time requirements of motion control. In reality, application
development can be delineated from motion control such as the former can take place
on an open architecture platform while kinematics, trajectory planning and servo
control are carried out in a tight real-time framework.

4.1 Some examples

Two PC based control architecture are presented here, Bosch Turboscara
SR6/SR8 and Kuka KRC1. They both use VxWorks Real-time operating system with
Windows. The solutions cannot be compared directly, due to robot kinematics and
differences in control hardware. In the market there might be also others. The selected
systems came to the market in late 1990 or early 2000.
AS 116.140L Juhani Heilala 2001 13

4.1.1 Bosch IQ2000 and TurboScara SR6/SR8

Figure 9. Bosch Turboscara system [Bosch Automation 2000].

The robot system SR6/SR8 consists of robust robotic mechanics with four freely
programmable axes. At the core of the IQ200 robot controller is an industrial PC
(rho4) with a Pentium MMX processor. The power supply (EVS) has a power supply
pack for the internal voltage supply (24V) integrated with an emergency off circuit
and safety technology: safety class 3 per EN 954. The digital drive booster (AV200)
for the four individual axes exchanges data with the rho4 robot controller via a field
bus (CAN 1). All three modules are developed as 19” plug-in assemblies.
Decentralised input and output modules or other periphery equipment, such as
actuators and sensors, can be controlled via the field bus (CAN 1 or CAN 2). Aside
from the operating block, the robot can be operated by a hand-held programming unit
(PHG2000), a touch screen (BF200T), or any PC. A keyboard, mouse, and monitor
can also be directly hooked up to the robot controller (rho4).
The rho4 runs concurrently Windows 95 or Windows NT in realtime. The
familiar operating system makes the control easy to use and provides users with more
openness to implement their own technology functions. However, instead of
extensive modifications of Windows or costly plug-in cards with separate processors
to deliver realtime capabilities, Bosch developed a more cost-effective solution. The
AS 116.140L Juhani Heilala 2001 14

PCI_RHO extension card, passive PCI card with realtime logic and the VxWorks
realtime operating system ensure that the control functionality is delivered
independent from other Windows activities. The real beauty about this solution is that
this combination safely continues to work even if Windows crashes. All PLC tasks
are handled by the integrated software PLC PCL under Windows. This means that
users do not require any additional hardware.

Figure 10. Block structure of rho4 [Bosch Automation 2000].

The PCI_RHO card is already included in the rho4 standard configuration and
includes, among other features, CAN and SERCOS Interface as digital interfaces to
the drives. Other standard features include an incremental measuring system, safety
functions and a port for connection of the PHG2000 hand programming unit.
Another key feature of the rho4 is the use of the TCP/IP (Transmission Control
Protocol/Internet Protocol) standard network. This permits both internal
communications between the Bosch software modules and external communications
AS 116.140L Juhani Heilala 2001 15

with standard and customer applications. Via TCP/IP, remote diagnostics capabilities
can be implemented for the first time so that on-site service calls can be minimized.
The integrated CAN field bus permits connection to remote I/O modules. The far
reaching communication capabilities of the rho4 even include the possibility to
initiate axis movements from a Windows application by using the newly created
library functions. The rho4 or an external PC can be used for programming the robot.
Data or programs are exchanged via the serial interfaces or with the Internet protocol
TCP/IP. The hand-held programming device PHG2000 is used primarily to teach the
robot and to diagnose errors. It can also change and edit robot programs.
The robot’s movement programs are written in the PASCAL-like language BAPS
(movement and sequence program language). BAPS robot programs can be created
with a text editor or with the graphical programming tool BAPSplus. When needed,
the integrated SoftSPS (PCL) can be programmed by the offline programming
software WinSPS.
The rho4.1 has a high-performance Pentium microprocessor, a 4 MB user
memory for BAPS programs and a 16 MB memory for Windows applications. The
microprocessor is sectioned into 2 virtual processors P1 and P2. The processor P1 is
the BAPS3 language processor. It interprets the commands and plans the course of
action and paths for the robot motion: up to 11 points in advance. In addition, the P1
processor is responsible for intelligent systems, e.g. vision systems, host computer,
etc, the I/O handling of the freely programmable real time loop PCL, as well as the
exchange of information with the operator via Windows interface.
The task of the P2 processor is to continually calculate each set position of the
axes in path operation, i.e. to perform a transformation of the co-ordinates from space
co-ordinates to axis co-ordinates. It monitors the work space limits or the axis limits
and maintains the digital position control via CAN (Controller Area Network).
The rho4 can handle up to 24 axes simultaneously and permits the simultaneous
control of up to 16 kinematics. The extended functionality, such as TCP/IP
networking, communications via the DDE and DLL standard interfaces and the use of
PC technology as the control platform opens up a wide range of applications, from
traditional robots through special-purpose paint robots and handling systems to
special-purpose machinery.

4.1.2 Kuka KRC1 [Schneider 1998].

The second example on the control technology market for industrial robots with
PC hardware and the Windows 95 operating system together with the real-time
VxWorks expansion as a single-processor solution is supplied by the KR C1 robot
controller made by KUKA Roboter GmbH.
Figure 11 shows the entire system architecture. From the point of view of the
hardware system, the heart of the system is a PC motherboard with an Intel Pentium
processor (currently P166 as standard) and 32 Mbytes of RAM. The two operating
systems Windows 95 and VxWorks (in the form of LP-VxWin made by LP
Elektronik GmbH) run on this processor and exchange data, such as variable values,
commands, robot program uploads/downloads, via the TCP/IP protocol.
AS 116.140L Juhani Heilala 2001 16

Figure 11. System structure of the PC-based robot controller KR C1

Operator control, displays and data management are implemented under

Windows 95 (a complete user interface is available – not just a library to generate
one). VxWorks is used for all real-time tasks such as path planning, command
processing and the processing of information from peripheral interfaces (e.g. sensor
data processing).
To control the drives (via DSE AT) and for coupling buses and digital I/Os, the
MFC (multi-function card) is plugged onto the PC motherboard. MFC has Digital
Signal Procesor (DSP). This turns the PC into a special machine controller. The MFC
also contains the passive LP Real-time Accelerator Chip as a logic device to guarante
real-time.
For communication with the periphery, a CAN bus module supporting the
DeviceNet protocol is integrated on the MFC as standard. The coupling of other bus
systems (Interbus-S, Profibus Master or Slave, FIP, etc.) is accomplished using
additionally available plug-in cards. This satisfies the requirement for support for the
various bus systems encountered on the market. No standard has been identified, once
again variety is the rule. The internal ISA/PCI bus may be used to integrate all the
plug-in cards based on this standard. For communication via Ethernet (TCP/IP
protocol), there are two interconnection options: one on the MFC with direct access to
the real-time operating system VxWorks, the other on the motherboard with access to
the data exchange between Windows 95 and VxWorks. It also supports the typical PC
serial interface (e.g. for the integration of sensors) – although be-cause of the
requirement for real-time processing, this is run under a special protocol (e.g. 3964
R).
AS 116.140L Juhani Heilala 2001 17

5 Real-Time Communication in Distributed Systems

Figure 12. Distributed control system needs communication [Festo]

5.1 Prerequisite for distributed control systems [Plagemann 2000]

It seems that we have to meet some basic demands to be able to realise the idea of
distributed systems. The following list might not be complete but seems to include
extremely important points:
- We definitely need control systems which are equipped with a
communication device. The complete system must not be considerably more
expensive than a centralised control system. This sounds simple as the distributed
systems are usually smaller systems and will cost less money than the central sys-
tem. But we need many small systems, each including a CPU and the
communication channel. These many CPUs plus communication devices compete
against the one central CPU and the one fieldbus for IOs.
- We need a configuration method which is easy to handle and easy to modify and
easy to document. Especially this has long been the greatest disadvantage of
Profibus FMS. And again today some new communication ideas seem to be
designed to frighten the automation practician instead of being attractive to be
used.
- We need a communication method which is easy to be used in a program, which
is clearly described so that the user (not creator) of a program can understand fast
and easy which data are communicated and where is source and recipient – or in
terms of modern network technology – where is client and server.
- We need a centralised programming possibility to handle decentralised
automation systems. This means that it must be possible to program and observe
the whole system containing many individual CPUs from just one point of the net.
A distributed system where the maintenance person has to walk with his notebook
from CPU to CPU, connecting again and again to the local programming port will
never succeed.
AS 116.140L Juhani Heilala 2001 18

5.2 What is Real Time?

A system is real time capable if it is guaranteed that the system will give an
answer to an input signal within a defined time. The important words are underlined
and it is obvious that there is no speed or time limit given. The traditional way to
define Real Time as being “fast”, or giving “immediate” response, cannot help as
these words cannot define a system in a technical way. In fact “immediate” response
might mean to react within 5 minutes, and it might be “fast” to check a system every
half hour. Other applications will need a reaction time of less than 1 microsecond and
consider a millisecond to be much too slow. In real applications within automation we
usually talk about reaction times of some 10 to 100 milliseconds. In any case, the
crucial point is that there will be a reaction within a defined time. Remember last time
when your PC crashed because the network was down or else. You pressed a key –
and nothing happened. In automation we need a guaranteed reaction when pressing
the STOP button –hence we need real time capable systems. [Plagemann, 2000]

5.2.1 Real Time Communication via Ethernet [Plagemann, 2000]

Whenever talking about Real Time communication via Ethernet we have one
precondition: Office and Automation have to be separated. As in the office world we
do not have any chance at all to predict the load of communication, we cannot
guarantee for any response within any time. The necessary separation could mean that
office and automation have no link at all, it could mean that they are linked via a
switch or – in most cases – they are linked via a gateway or router. Based on this
situation we know of three ways to guarantee real time communication:

1. First is not typical for Ethernet but used in many applications: Reducing the
system to a master/Slave system guarantees real time capability without any
doubt. This might be old fashioned but works.
2. The second way is to implement a token, which allows just the one and only
station with the token to access the bus. The protocol ensures that the token will
pass the whole round within a defined time. The configuration of such a system
needs considerably more effort as all stations have to know from each other to
ensure the token to be passed through.
3. The third way is a very Ethernet like way. We know that Ethernet guarantees a
reaction within a defined time as long as the bus load is below 60%. In automation
we can define the bus load as we can predict the communication. This means we
can configure the system so that the bus load is guaranteed to stay below 50%.
This then guarantees reaction within a defined time (not at a defined time!).

5.3 Bus systems for internal and external communication

Networks are crucial component [Mintchell 2000B]. Open systems would
probably never have happened without standard networks. There are many networks
with open vendor associations to guide development of standards. Some of them are
DeviceNet, Profibus, ControlNet, Interbus, and Foundation Fieldbus, not to mention
device level buses like Seriplex and AS-Interface.
AS 116.140L Juhani Heilala 2001 19

In control engineering, five bus systems have gained wide market acceptance
[Bosch]:
- Profibus-DP
- CANopen
- DeviceNet
- AS-Interface
- InterBus-S

A network borrowed from commercial applications that is making market share

gains is Ethernet. Its installed base is so large that many necessary components are
much less expensive than competitive industrial ones. Whether it is robust enough for
industrial use is still hotly debated, but it already has many users.

5.4 Standards and Protocols on Ethernet

5.4.1 GEM/SECS
GEM/SECS is a specification developed by the Semiconductor Equipment and
Materials International (SEMI) trade association. The GEM/SECS protocol provides
a method of communication between a host computer system and automation
equipment. It specifies the format and allowable content of messages. The SEMI
Equipment Communication Standard, SECS defines point to point communication
using RS-232C. High Speed SECS Message Service, HSMS is based on TCP/IP
streams, and is not limited to point-to-point topology.

Levels of GEM/SECS Software :

- Physical Transmission Level (SECS-I/HSMS)
- Message Content Level (SECS-II)
- Equipment Behavior Level (GEM)

GEM/SECHS is expanding in the electronic industry.

5.4.2 CORBA
Common Object Request Broker Architecture (CORBA) gives application
components the ability to transparently interoperate with objects implemented on any
of the more than 50 platforms with CORBA support, including all common Windows,
Unix and Linux variants. CORBA also provides seamless communication between
components implemented in different programming languages, such as C, C++ and
Java.

CORBA Highlights:
- Object Oriented
- Language independent
- Platform independent (more than 50 supported)
- Network location independent
- Enables efficient network management of advanced applications
- Standard mappings for SNMP and CMIP
- Gateways available for COM/DCOM
AS 116.140L Juhani Heilala 2001 20

5.4.3 OPC, DDE server

Ole for Process Control, OPC is based on Microsoft’s DCOM/Active-X concept.
Microsoft is dominating the field, OPC servers are a de facto standard, even this is not
yet a really cross-platform standard.

6 Results

The trend in robot control technology is towards PC technology: the robot control
systems which are now available range from just an extra operator control station for
special tasks right up to a control computer with a PC-typical operating system
(Windows or DOS) and some real-time expansion. This increases openness with
regard to the user interface, communication with the periphery and the integration of
the periphery. PC hardware based open robot control systems are already in the
market as shown in this article. The Windows operating system has been enhanced
with real time kernel, VxWorks. These operating systems are in the same processor
and communicate with shared memory and TCP/IP drivers. Same PC can replace
even PLC:s, with SoftPLC.
Automation is not isolated any more. Using a communication procedure, which is
based on TCP/IP and Ethernet vendors, can provide DDE and OPC server. This
allows any modern Windows application to communicate with the control systems.

7 Analysis and discussion

The distributed paradigm brings the power of better connectivity to the factory.
Just as the Internet has greatly increased the productivity of the enterprise, distributed
intelligence offers many fundamentally better capabilities to factory systems. These
include faster integration, better understanding of functions, and much better
maintenance. Networking truly is the next great revolution. Ethernet and TCP/IP and
socket-interface for serial communications between machines will continue to spread.
Ethernet for I/O-messages will get more room.
Distributed, embedded systems. ?
Author expect to see many more developments in embedded computing in the
future. In Robotics this will likely show up first in Windows CE powered intelligent
teach pendants. Other real-time, embedded system like intelligent sensors, force and
torque need could be based on QNX. The intellingence, control functions are also
going to actuators and motors. The functions of a PLC controller has been put to a
single chip, the problems is the interfaces and connections to and from the chip. Festo
PLC-CHIP has in build ethernet interface. A device could have own IP-address.
What about WLAN, Wireless Local Area Network. ?
Author expcts to see industrial wireless application are soon in the factory floor. The
wireless solution give some freedom for system building, but the solutions must be
reliable in every situation.
AS 116.140L Juhani Heilala 2001 21

8 Reference
[Fiedler and Schilb 1997] Phillip J. Fiedler and Chris J. Schilb. Open Architecture
Robot Controllers And Workcell Integration. http://www.robotics.org/
Technical papers. 1.4.2001.

[Fiedler, and Dehof. 1997] . Phillip J. Fiedler, and Matthias K. Dehof. Workcell
Communications: Connectivity, Man-Machine Interfaces, and Multi-System
Management. http://www.robotics.org/ Technical papers. 1.4.2001

[Plagemann 2000] Bernhard Plagemann. Distributed small controllers in the WEB.

Beck IPC GmbH. Garbenheimer Str. 38 35578 Wetzlar, Germany
b.plagemann@beck-ipc.com, http://www.beck-
ipc.com/files/presentations/ospma2000.pdf

[Mintchell 2000A], Gary A. Mintchell. Robotics Integrate PCs, Networks. Control

Engineering, January 2000.
http://www.controleng.com/archives/2000/ctl0101.00/000101.htm

[Mintchell 2000B], Gary A. Mintchell. How to Succeed with Open Control,

PROMISE VS. THE CURSE, . Control Engineering, February 2000

[Munz, 1997] Heinrich Munz, LP- VxWin VxWorks Together with Windows on the
same PC. Real-Time Magazine 97-2. http://www.dedicated-
systems.com/magazine/97q2/1997q2_p047.pdf

[LP Elektronik 1999] LP Elektronik GmbH. LP-VxWin. VxWorks & MS-Windows.

Product Manual Version 3.4. Edition: 28. July, 1999.

[Schneider 1998]. Gerd Schneider. Control technology for industrial robots. KUKA
Roboter GmbH, Augsburg. 12.2.1998

[Brega and Honegger 1998]. R. Brega & M. Honegger Introduction to Real-time

systems. Jun 1998, http://www.ifr.mavt.ethz.ch/research/xoberon/introduction.html .
1.4.2001

[Bosch Automation 2000]. Turboscara SR6/SR8, CD-ROM Version 3.0. 3 842 524
619 (00.04) de/en. Bosch Automation. Assembly Technology.
(http://www.bosch.de/at )