Open Real-time Robotics Control - PC Hardware, Windows/VxWorks ...

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 [email protected]

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 realtime expansion as a solution with two motherboards PC hardware and Windows 95 operating system with the VxWorks real-time expansion 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, graphicssupported 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 realtime 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 prewelded 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 processorarchitectures (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 LPVxWin 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 MSWindows, 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 MSWindows only will be activated, if all VxWorks tasks are idle, one can say that MSWindows 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 MSWindows 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 LPVxWin 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

4.1.1

13

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 system. 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 [email protected], http://www.beckipc.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.dedicatedsystems.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 )