Page 133 - Welding Robots Technology, System Issues, and Applications

120 Welding Robots
Using any of the presented software interfaces it’s possible to design a software
strategy/architecture to implement robot controller access for data exchange,
program control and robot controller status supervision. To particularize and
demonstrate a few implementation specific details, two different technologies will
be explored in the following sections: remote procedure calls (based on the SUN
RPC 4.0 implementation [32]) and TCP/IP sockets (based on the Microsoft
Winsock implementation [33]-[35]). The concepts will be kept as general as
possible, using a specific robot controller when needed for clarity.

4.5.1 Using RPC – Remote Procedure Calls

Client-server software architecture was adopted [32],[33]. The robot controller
software works as a server, exposing to the client a collection of RPC services that
constitute its basic functionality (Figure 4.9). Those services, offered by the RPC
servers running on the robot controller, include as already mentioned variable
access services, files and programs management services, and robot status and
controller state management and information services. To access those services the
remote computer (client) issues properly parameterized remote procedures calls to
the robot controller (server) through the network (Figure 4.9). Considering for
example the S4CPLUS robot controller from ABB Robotics, it’s possible to extend
the RPC services available in the robot controller adding user functionality to the
system. The ABB implementation is based on a messaging protocol developed by
ABB called RAP (Remote Application Protocol) [38], which is an Application
Specific Protocol (ASP) of the OSI application level. The messaging protocol RAP
defines the necessary data structures and message syntax of the RPC calls used to
explore the RPC services available in the controller. These services were
implemented using the standard and open source RPC specification SUN RPC 4.0,
a collection of tools developed by the SUN Microsystems Open Network Group
(ONC) [32]. Consequently, to implement the client calls, the ONC SUN RPC 4.0
specification and tools were also used. This package includes a compiler (rpcgen),
a portmaper and a few useful tools like rpcinfo [32]. The Microsoft RPC
implementation uses another standard defined by Digital Corporation named
OSF/DCE [37], which is not compatible with the SUN RPC standard. The package
used to build the client software was a port to Windows NT/2000/XP [39],
equivalent to the original version that was built to UNIX systems, although a few
functions were slightly changed to suit better the needs without compromising
compatibility with client and server programs developed with the SUN RPC
package. The port was compiled using the Microsoft Visual C++ .NET 2003
compiler [42].

From all the RPC services available in the robot controller, the ones really needed
to implement the software architecture depicted in Figure 4.9 are the variable
access services. Nevertheless, calls to the other services were implemented for
completeness. The procedure is simple and based on the XDR (Extended Data
Representation) file obtained by defining the data structures, the service
identification numbers and the service syntax specified by the RAP protocol. That