Open architecture controller interface implementation ...

Innovative Production Machines and Systems D.T. Pham, E.E. Eldukhri and A.J. Soroka (eds) © 2008 MEC. Cardiff University, UK.

Open Architecture Controller Interface Implementation for Machine Tools W.-S. Yuna, B.-K. Minb, Z.J. Pasekc a

Korea Polytechnic University, Seoul, S. Korea b Yonsei University, Seoul, S. Korea c University of Windsor, Windsor, Canada

Abstract Open architecture control (OAC) is a well-established factory automation technology. However, a gap between the available state-of-the art technology in support of OAC and practical industrial implementations persists. To explore the different viewpoints between the end users and vendors of OAC, two applications of OAC were developed. The first application is a user-customizable, remote monitoring system that can gather machine tool or machining process information generated by networked CNC (Computer Numerical Control) systems. For common open connectivity, OPC (OLE for Process Control) standard interface was used. The second application is a hardware-in-the-loop simulation for machine tool development using a commercial OAC. The simulation model proves to be a useful tool for analyzing and verifying complex CNC machine tool system performance. Keywords: CNC, machine tool, open architecture control

1. Introduction The rapid pace of evolution in manufacturing automation creates increasing demands with regard to productivity, agility, and maintainability. Open Architecture Control (OAC) can help manufacturing companies address these challenges. Open architecture, a term from computer industry, refers to hardware and software systems designed to address a broad variety of applications. In the personal computer industry, many companies develop hardware and software independently, yet due to use of open standards, the hardware and software works together. Such openness engenders competition among component suppliers and works in favor of the end users. In the machine tools control industry, however, the situation is different. The leading control companies,

382

traditionally hardware developers, create systems with embedded software. In order to run a user application, end users must use device-oriented systems with proprietary hardware and software components. OAC would benefit end users by allowing them to choose the hardware and software components they want for their machine tool systems, giving them more flexibility and reducing maintenance and upgrade costs. Since the early 1990s several groups (e.g., OMAC, OSACA, and JOP) actively promote OAC use and research. Yet despite a world-wide collaboration, a global OAC standard is still far off, mostly due to the physical differences between existing control products, conflicts of interests in the market, and the absence of clear agreement on such a standard. Most recent promising effort aims to develop a global Human Machine Interface (HMI) Application Program

Interface (API) standard for OAC systems [10], with the goal to define an HMI API for most control products in the world. A concise overview the past, present and future of open controller architecture is given in [16]. Early OACs through the use of PC-platform enabled access to the source code, and thus its easy modification. Initial implementation [4, 14] included the servo control, interpolator, G-code interpreter, and user interface. It was gradually expanded to include FSMbased machine control, supervisory control, and an HMI [5]. Implementations of modular machine tool design and control, distributed network-based control, retrofit of an existing machine tool, OAC simulation tools, and common HMI API followed [8, 9, 15]. An alternative solution based on a PC/DSP-based multiaxis programmable CNC controller [2]. The PC-based platforms to control the production systems are in use since the 1990s and many vendors now offer PC-based OAC solutions [1]. This paper attempts to address the gap between research and practice in OAC implementation.

2. OAC Technology Practice and Requirements The common control components in factory automation are CNC and Programmable Logic Controller (PLC). If properly implemented, existing PC-based controllers are reliable enough for real-time machine tool control. These OAC systems typically have both a PC-based PLC and CNC kernel and allow users to mix and match hardware and software components to meet control requirements. However, just because a system uses a PC platform for control, it does not necessarily mean that it is open.

Fig. 1 Typical system-level architecture of an open architecture CNC controller.

Typical control system architecture for discrete manufacturing operations (Fig. 1) has three layers: device-, controller-, and cell-level (or system-level). Open interfaces, including plug-and-play capability between these levels (i.e., cell and controller level, controller and device level), are required for the control components and system to work together. In addition, the user must be able to customize his controller applications (Table 1). Table 1. OAC Requirements Item

Description

Customization capability of user application

x x x x x x

Servo interface Sensor signal I/O interface PLC HMI level Soft Real-time application level Hard real-time application level

Integration with other software

x x

3rd party software compatible Connectivity with enterprise system

Interface with external devices

2.1. Interface with external devices The device level network of the control system in Fig.1 consists of the servo and device network. Use of standard device-level network assures interoperability of control components. Currently, various intelligent drives, analog and digital, are used in factory automation with variety of interfaces, including the analog servo interface, proprietary servo interface, open device network interface (e.g. Profibus DP), and industry-standard servo interface (e.g. SERCOS). Most OAC systems support analog servo interfaces and the SERCOS digital interface. Use interfaces such as IEEE 1394 and USB, will further drive the factory automation towards the use of PC-based open CNC software. Discrete applications in CNC continue to be hardwired or use proprietary remote I/O networks, but standard device networks such as CANOpen, DeviceNet, PROFIBUS DP, Interbus-S, etc., have also gained significant market share. Many PC-based OAC systems contain a PLC execution module. PC-based open architecture CNC adopts the software PLC and avoids an extra CPU to handle the executions. In general, the software PLCs support all IEC-61131 languages. Users can also integrate custom routines. The trend toward convergence of various control technologies (e.g., PLC, CNC) running on PC-based computing platforms has created the additional benefit

383

of allowing users to apply their CNC controllers beyond motion-centric applications. 2.2 Customization capability of user application In addition to device-level hardware interoperability, open systems must allow users to easily integrate and customize application modules. A method frequently used to allow users to develop their own applications is to offer a standard application program interface (API). Control software vendors provide API functions in their controller software suite, and custom software calls the API functions. This method gives the users the freedom to program and access the system variables and functions. Alternately, controller vendors may offer OPC (OLE for process control), industrial standard popular among users and developers. Based on Microsoft’s OLE (Object Linking and Embedding), COM (Component Object Model) and DCOM (Distributed Component Object Model) technologies, OPC consists of a standard set of interfaces, properties, and methods for use in process-control and manufacturing automation. Most of the HMI, SCADA, and DCS automation manufacturers, as well as the soft PLC manufacturers, are offering OPC client and/or OPC server interfaces with their products [3]. Only seldom users can modify low-level control algorithms (i.e., hard real-time tasks). Usually, PCbased controllers given the OAC label allow only applications written in MS Windows software technologies (such as DDE) into their control software. In such cases the system openness is just inherent to the operating system, and thus cannot be considered strictly OAC (no hardware- or control logic openness). A few control software vendors, targeting R&D applications, do allow users to modify the low-level control logic for situations requiring frequent application changes (e.g., development of special machine tool or robotic devices). Giving users permission to modify system code is a reasonable policy: by doing so, control software vendors give OEMs the flexibility to select the devices they need and implement special control/user interface software. 2.3. Integration with other software PC-based OAC is moving from stand-alone islands of technology to network distributed technologies, thus enabling machine tools to be factory network peripherals. It is important in an OAC system for the devices and controller to exchange information and specifications. The PCs are already a natural part of the information system, and when a PC is used as the

384

control platform, the OACs can provide details about the process, machine, or system they control. The information created during the manufacturing process has also value to other parts of the organization, e.g., accounting, quality, logistics, purchasing, etc. PC-based control systems can connect to the information infrastructure through common networks such as Ethernet or TCP/IP. In support of these enterprise-wide applications, software companies are introducing new technologies. Nevertheless, a PCbased controller remains a low-level building block that can provide timely manufacturing floor data such as machining data, diagnostic data, and machine tool configuration. One way to exchange this data is by using XML (Extended Markup Language), a standard data format with great use potential in manufacturing.

3. OAC Implementation Industry shows strong interest in adopting open architecture control, especially when various OAC products are already available (e.g., MS Windows PCbased control systems). Many of the OAC goals can be achieved using these technologies. The manufacturing industry, however, resists frequent changes in its production environment – an issue exacerbated by the fast pace of change in IT technologies, much faster than that of manufacturing technologies. 3.1. OPC standard interface in PC-based CNC While many researchers have developed PC-based CNC systems, these systems have not, however, successfully used open interfaces. Figure 2 shows the software architecture of the PC-based CNC software and OPC interface developed by the authors. The developed PC-CNC system runs under the MS Windows operating system with real-time extensions. The PC-based CNC is made up of several modules that run at different priorities and communicate with each other through shared memory. CNC software modules are divided into two separate architectural layers depending on the real-time response requirements (soft-real time vs. hard-real time tasks). The soft-real time tasks include modules for CNC user applications, such as the HMI and memory manager, and custom modules, including a CNC parameter viewer and graphic simulation for cutter path. The hard-real time tasks, commonly called the CNC kernel, include the NC code interpreter, interpolator, PLC executable, and position and velocity control loop, as well as interrupt routines that interface

to hardware. The hard real-time tasks run at the highest priority (interrupt level) and gain access to the CPU prior to any other programs. Soft real-time tasks require real-time response, but their priorities are lower than those of the hard real-time tasks, thus the soft realtime modules gain access to the CPU only when the hard real-time processes computational needs are satisfied. For the inter-process communication between each module, the two separate real-time tasks share the specific memory that contains the internal variables and system parameters (see Fig. 3).

of standards specifications (OPC Foundation, 2004). The OPC server accesses the shared memory using a real-time API and can be connected to various OPC clients via LAN, WAN or internet (Fig. 2). OPC is based on the Distributed Component Object Model (DCOM), technology for the implementation of distributed systems. DCOM provides built-in features that ensure OPC clients and servers have a reliable mechanism to exchange real-time information across the network. An OPC client application communicates to an OPC server through the specified custom and automation interfaces (Fig. 3) [3, 12]. Table 2 Data items acquired by the remote monitoring module Item (OPC data tag) Description Machine/Relative/Current Position information position, Distance to go Display of tool path on Tool Path machining NC program Name and status of information machining program(NC code) Alarm and events of remote Alarm and Events CNC machine tool.

Fig. 2 Software architecture for PC-based CNC and OPC server/client interface

Fig. 3 Schematic diagram of the typical OPC interfaces To allow open connectivity to the PC-based CNC, the OPC client/server based application module has been developed to monitor the status of local or remote CNC systems. A standard mechanism for communicating to numerous data sources, either devices on the factory floor, or a database in a control room is the motivation for OPC use, which is a series

Data for remote monitoring (Table 3) are acquired through the OPC server/client communication. All the data tags provided by the OPC server can be accessed by various OPC clients with the OPC Data Access specification. The addition and removal of the data tags does not require recompilation of the OPC server or CNC software. End users or system integrators can make their own applications satisfying the OPC specification, then plug them into the CNC software and play the applications. Using the OPC standard interface we can get real plug-and-play capability. OPC client remote monitoring module, comprised of the network browser and monitoring window, obtains the required data for remote monitoring through the OPC standard interface (Fig. 4). By choosing the remote PC-based CNC OPC server on the network browser, the monitoring module can get required data from the remote CNC. The monitoring window displays the tool path, machine position, running program information, and recent alarm and events for multiple PC-based CNC machine tools. If necessary, more data can be extracted from the OPC server by simply editing the database file that contains OPC data tag information in the OPC server. Through the OPC-based application module, a system operator can readily gather information about the status of remote CNC machine tools by connecting their desktop computer to the OPC server. This module

385

enables real unmanned machining. Since the required data has been obtained through software connection not hard-wired connection, the remote monitoring program can reduce the cost of installation and maintenance. Tool Path Display Position Display

Network Browser

time simulation code and executables was produced with a computer aided software engineering tool (RTI, 2004). An unmodified commercial OAC (MDSI OpenCNC Version 6.1) was used in the simulation loop to control the real machine tool. CNC Control

Axis 1 Dynamics

PLC

Discrete I/O Model

PC-based Open Architecture Controller Program Information

Simulation

Axis 1 Simulation Axis N Simulation

Switch

Axis 1 Drive

Discrete I/O

Real machine tool

Real Axis 1 Alarm & Event Display

Fig. 4 Sample screen of the OPC client-based remote monitoring module 3.2. Hardware-in-the-loop simulation Simulation is a popular way to analyze and verify complex systems such as machine tools. Many CNC machine tools provide a simulation mode that allows users to validate control logic and part programs. But because the simulation modes (or dry run modes) provided by the CNC machines do not include dynamic models of the machine tool components, it is difficult to conduct accurate simulations of machine tool behaviors relating to control parameters, discrete logic design errors, productivity, and faulty components. Users can, however, perform detailed modeling of commercial CNC machines using dynamic simulation tools (Matlab) for control design and prototyping. Hardware-in-the-loop simulation (HILS) is an effective approach to verify controller design and part programs in a CNC machine tool (Pritschow and Röck, 2004). By incorporating real CNC hardware in the machine tool simulation, users can test machine tool performance without building a complex machine tool controller model. With a PC-based OAC the HILS can be implemented without the hardware interface. The simulator structure (Fig. 5), instead of using hardware connections, connects the dynamic model of the machine tool as well as the discrete components to the real controller using the shared memory of the controller PC. The modular C++ code, based on prior work of the authors (Landers et al., 2002), simulates machine tool dynamics and discrete events. The real-

386

Real Axis N

Fig. 5 Modular machine tool simulator. The simulator reads data generated by the OpenCNC controller, calculates the response of the machine tool servo drives and discrete components, such as limit switches, and then outputs encoder and discrete output values to the OpenCNC controller. The simulator must perform this procedure in real time, i.e., it must output values before the controller samples its inputs. The controller sampling time was 10 ms, and the maximum simulation period was less than 5ms. The controller connects to the real machine tool by switching the connection from the shared memory of simulator to the real machine tool device drivers provided by the controller component manufacturers (Fig. 5). To verify the simulator accuracy the results of the simulations were compared to the experimental results from a real machine tool using by the same controller (Fig. 6). To demonstrate the functional capability of the simulation, the controller startup sequence was included in the simulation. The machine tool was initialized at about 5 sec, then the table started homing motion, and executed a part program afterwards. In addition to the servo dynamics, process models and failure models can be added to the simulation. The simulation can also be used to evaluate how well a controller handles errors, something that a conventional machine tool simulation cannot do easily. In summary, the PC-based OAC makes it easy to simulate a CNC machine, especially using when HILS.

[3] [4] [5]

[6] [7] [8]

Fig. 6 CNC simulation and experimental results: Following error, axis position, and DAC output. [9]

4. Conclusions OAC-related concepts, developed in parallel in industry and academia are now converging due to progress in IT technologies, facilitating faster and increasingly complex integration tasks. Two studies presented here demonstrate OAC effectiveness in truly making individual machine tools part of the interconnected enterprise infrastructure and also enabling thorough controller feature exploration before final implementation, which leads to improved solution robustness and reduces cost and length of development cycle.

[10] [11]

[12] [13] [14]

Acknowledgments This work was supported in part by the NSF ERC for Reconfigurable Manufacturing System (NSF grant # EEC-9529125). The post-doctoral fellowship of W. S. Yun at NSF ERC/RMS was supported by Korea Science & Engineering Foundation (KOSEF).

[15]

[16]

References [17] [1] ARC advisory group (2001) CNC Worldwide Outlook: Market analysis and forecast through 2005, ARC Advisory Group. [2] Erol, E. A., Altintas, Y. and Ito, M. R. (2000) Open system architecture modular tool kit for motion and

[18]

machining process control. IEEE/ASME Transactions on Mechatronics, 5(2), 281-291. Iwanitz, F. and Lange, J. (2001) OLE for Process Control: Fundamentals, Implementation, and Application, Hüthig GmbH Heidelberg. Koren, Y. (1998) “Open-Architecture Controllers for Manufacturing Systems,” in: “Open Architecture Control Systems”, ITIA Series, 85-101. Koren, Y., Heisel, U., Jovane, F., Moriwaki, T., Pritchow, G., Van Brussel, H. and Ulsoy, A.G. (1999) Reconfigurable Manufacturing Systems. CIRP Annals, 48(2), 527-540. Katz, R., Min, B.-K. and Pasek, Z. (2000) Open Architecture Control Technology Trends. ERC/RMS Technical Report #35, Ann Arbor, MI. Landers, R., Min, B.-K. and Koren, Y. (2002) Reconfigurable Machine Tools. CIRP Annals, 50(1), 269 – 274. Lian, F., Moyne, J. and Tilbury, D. (2000) Control Performance Study of a Networked Machining Cell. Proceedings of the American Control Conference, 2337-2341. Lucas, M., Endsley, E. and Tilbury, D. (2000) Modular Control for Reconfigurable Machine Tools: Integrating Servo and Logic Control. Proceedings of the Japan-USA Symposium on Flexible Automation, Ann Arbor, MI. Mathias, D. and Hellmann, R. (1999) Boeing implements HMI. Manufacturing Engineering, 78-82. Min, B.-K, Huang, Z., Pasek, Z., Yip-Hoi, D., Husted, F., and Marker, S., (2002) “Integration of Real-Time Control Simulation to a Virtual Manufacturing Environment,” International Journal of Agile Manufacturing, v. 1(1), p. 67-87. OPC Task Force (1998) OPC Overview, OPC foundation OPC Foundation. (2004) http://www.opcfoundation.org. Park, J., Pasek, Z. J., Shan, Y., Koren, Y., Shin, K. G., Ulsoy, A. G., 1996, “An Open Architecture RealTime Controller for Machining Processes,” Manufacturing Systems, v. 25(1), p. 23-27. Pasek, Z. J., Min, B.-K., Husted, F., Marker, S., (2002) “Web-enabled Monitoring and Control of Manufacturing Systems,” Advances in Manufacturing Science and Technology, v. 26(1), p. 5-16. Pritschow, G., Altintas, Y., Jovane, F., Koren, Y., Mitsubishi, M., Takata, S., van Brussel, H., Weck, M. and Yamazaki, K. (2001) Open Controller Architecture – Past, Present and Future. CIRP Annals, 50(2), 446-463. Pritschow, G., and Röck, S., (2004) “Hardware in the Loop” Simulation of Machine Tools. CIRP Annals, 52(1), 1, 259-298. RTI, Constellation. (2004) http://www.rti.com/products/constellation/.

387