Theory and Design of CNC Systems Part 11 pdf

35 536 0
Theory and Design of CNC Systems Part 11 pdf

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

338 9 CNC Architecture Design 9.8.2 Message System A message system is a method that enables process synchronization and data ex- change without shared variables. Basically, the communication function between processes provides two operations; the first is SEND for sending a message and the other is RECEIVE for receiving a message. A method is needed to refer to each other for communication between processes. There are two methods for this. Direct Communication: The process that wants to send or receive a message spec- ifies the name of the receiver or sender. For this, it is necessary to know the name of the corresponding process. SEND (P, message): send message to P. RECEIVE(Q, message): receive message from Q. Indirect Communication: the message is transmitted via a mail box. The mail box has a unique identification number and when two processes share the same mail box communication is possible. SEND (A, message): Send message to mail box A. RECEIVE(A, message): Receive message from mail box A. Sending a message to a mail box is a simple task. The message is copied into the specified mail box and then the first in-message is copied into the receiver’s message data structure when the receive function is called. After reading the message, it is deleted from the mail box. A mail box does not have an individual structure and is located in memory or on disk. It exists when the system is on and activated. If a mail box exists on disk, it is regarded as a temporary file and is deleted when the system is turned off. A mail box does not have a unique identifier or name. When it is created, it is distinguished by a logical identifier. All processes that use a mail box use the logical identifier to distinguish it. Figure 9.10 shows an example of a message-passing program. If proc1 and proc2, the processes created by the main program, receive a message that is not zero, they write out “A” and “B” respectively and send a message that is not zero. As a result, since synchronization of the two processes is realized, texts “A” and “B” are written out successively. In another method, which is similar to using a mail box, a queue is used. A queue can store more than one message and can be implemented as an array of mail boxes. As a practical implementation method, a ring buffer is used in order to receive service requests for a device and queues at the head and tail of the ring buffer are used in order to control access to the ring buffer. As other communication methods, the rendezvous method and monitor method are used. The rendezvous method is a method for synchronization and communi- cation between tasks in the ADA programming language. One task requests a ren- dezvous and the other task declares that it is ready to receive. The task that requests the rendezvous has to know the name of the task called. However, it is not necessary 9.8 Inter-process Communication 339 /* Display ‘A’ and ‘B’ one by one utilizing message passing method */ #include<conf.h> #include<kernel.h> void main() { int proc1(), proc2(); printf(”\n Display A and B one by one by utilizing message passing method \n”); printf(” Output \n\n“); pid1 = create(proc1, INITSTK, INITPRIO, “proc1”, 0, 0); /* create process 1 */ resume(pid1); /* make process 1 READY */ pid2 = create(proc2, INITSTK, INITPRIO, “proc2”, 0, 0); resume(pid2); } proc1() { int i; int msg1, msg2; for (i = 0; i < 10; i++) { /* receive message, if message is not received, process1 turns to wait state * / msg1 = receive(); if (msg1 != 0) printf(”A”); msg2 = 1; /* assign nonzero value for sending to process2 */ send(pid2, msg2); } } proc2() { int i; int msg2 = 0, msg1 = 5; for (i = 0; i < 10; i++) { msg2 = receive(); /* receive message from process1 */ if (msg2 != 0) printf(”B”); send(pid1, msg1); } } Fig. 9.10 Programming example utilizing a message for inter-task communication 340 9 CNC Architecture Design for the task called to know the name of the caller. The concept of the rendezvous method is the same as that for a subroutine call. The classical method for resource protection and communication between tasks is the monitor. The monitor consists of a reserved data region (monitored region) and a process that has the exclusive right to manage the reserved data region. Other processes do not have direct access to the monitored region and have to call the monitor process. The monitor provides the service to only one process at a time. Using this mechanism, the monitor can guarantee that the execution of a process completes before another process has access to the same data region. 9.9 Key Performance Indices A real-time OS supports pre-emption multi-tasking. The multi-tasking ability en- ables effective resource management as well as parallel execution of processes or tasks. For efficient multi-tasking, it is essential to increase the response character- istics of the OS by reducing the context switching time. Furthermore, a real-time OS can predict the required time for running tasks in order to realize the real-time scheduling and synchronization mechanism. In addition, it is necessary to know the characteristics of the interrupter, such as interrupt latency, which is the time spent to resume a task after an interrupt has been fired, the maximum elapsed time of the system call, etc. Knowledge of the above performance indices makes it possible to predict the user application’s execution and makes it easy to design the process schedule. In the following sections, the key performance indices of a real-time OS will be addressed. In general, the terminology and definition of these indices are slightly different depending on the kind of OS. In this book, the performance indices that are typically used will be described. 9.9.1 Task Switching Time Task switching time means the average time spent to switch between two tasks with the same priority. As shown in Fig. 9.11a, it is supposed that all tasks have the same priority. Task switching is done when real-time software uses the time-sharing algo- rithm to carry out tasks with the same priority. Task switching time is used for storing and restoring context. And it depends on the efficiency of control data structure, pro- cessor architecture, and instruction set. 9.9 Key Performance Indices 341 9.9.2 Context Switching Time The context switching time denotes the time spent to start task B when task A with low priority is being executed, as shown in Fig. 9.11b. For the context switching time, the context of the pre-empted task is stored, the context of the new task is loaded, and the new task is scheduled. Note that the task switching time denotes the time spent to switch tasks with the same priority, and that the context switching time is different from the task switching time. Task A Task B Task C dt 1 dt2 Time tcs Low-priority task A High-priority task A Time Fig. 9.11 Definition of Task switching time (a) and context switching time (b) 9.9.3 Semaphore Shuffling Time The semaphore shuffling time denotes the time delay from when some task frees the semaphore to when the task waiting for the semaphore is activated. Because the semaphore shuffling time itself represents a computing burden related with the mutual exclusion, the semaphore shuffling time is one of the key performanceindices of real-time systems. Figure 9.12 shows the mechanism to pass a semaphore when more than one task is competing for the same resource. Task A is being executed and requests the semaphore corresponding to the resource in order to access the resource at t1. At t2, Task A is stopped and Task B starts. At t3, Task B requests the semaphore to access the resource that is occupied by Task A. Because Task B cannot be continued, Task B is stopped and Task A is activated again. At the end of execution, t4, Task A frees the semaphore. As soon as the semaphore is freed, the scheduler resumes Task B and Task B receives the semaphore. Mutual exclusivity based on a semaphore is the most effective method of allowing only one task to access a particular resource. 9.9.4 Task Dispatch Latency Time The task dispatch latency time is a frequently used performance index for evaluating real-time systems. In a real-time system, a real-time task waits for a particular event 342 9 CNC Architecture Design Tasks Timet 1 t2 t3 t4 tss t5 Semaphore Ownership Task B Task A Task A Task B Fig. 9.12 Semaphore passing mechanism to happen. When the interrupt occurs, the task being executed with a low priority should be stopped quickly and the real-time task activated. The task dispatch latency time denotes the time spent to start a task from the interrupt service request. The task dispatch latency time is highly related to the interrupt latency time and the context switching time. Figure 9.13 shows the interrupt mechanism to activate an interrupt service routine (ISR) from the point of interrupt and to come back to the task status before the inter- rupt. The interrupt response time consists of the delay time related to the hardware and software. The hardware latency (delay time) is defined as the time span from detection of an interrupt to acknowledgement of it by a processor. If a processor receives the interrupt signal, the OS has to wait for completion of the instruction cur- rently being executed. This delay time is defined as an interrupt overhead (IO). After an IO, the system needs the time for interrupt latency, which an interrupt dispatcher manages, for the whole interrupt to be worked out. In conclusion, during the interrupt response time, which is composed of the above three steps, the system is ready to execute an interrupt service routine by acknowl- edging an interrupt to a processor and storing the parameters or context of the sys- tem. After the interrupt response time, the interrupt service routine (ISR) is invoked to handle the requirement of the interrupt. When the ISR has completed its work, a scheduling latency is spent for the OS to reschedule and switch the context to the task before the interrupt. Therefore, the scheduling latency time is defined as the time span from completion of the ISR to activation of the first instruction of a scheduled task. Figure 9.14 shows the worst case example of the task dispatch latency time exe- cuting in LynxOS (one of the widely used RTOS). It includes several behaviors and delay times consumed, such as issuing an interrupt, activating multiple ISRs, and resuming the task after the interrupt. Table 9.1 shows the comparison of the performance index of three kinds of a real-time OS; Hyperkernel 4.3 (Imagination), INTime 1.2 (Radisys), and RTX4.1 (VentureCom). They were tested on a PC with a Pentium 200MHz CPU. (Note: 9.9 Key Performance Indices 343 Time H/W latency Finish instruction Interrupt latency ISR INT exit & rescheduling Task A Task A t OH tIL tSL Fig. 9.13 Definition of task dispatch latency time Interrupt dispatch time Interrupt routine Other interrupt Pre-emption disabled Scheduling Context switch Return from system call 12 10 60 75 28 13 12 Fig. 9.14 Example of a task dispatch latency time Because this table only intends to show examples of the performance index, the actual system is not identified.) The performance index shown in the above table is described by an average value and a maximum value obtained from thousands of tests. When we select the right real-time OS, the maximum value, meaning worst case, should be considered rather than the average value. In order to design the reliable and deterministic system that is required to meet the hard real-time property, the OS with lower maximum value is preferred. From this point of view, system B is a good operating system. Of course, it is not always to be concluded that the OS with the lowest performance index is the best. According to the characteristics of the system, various performance indices should be considered. According to the above-mentioned standards and the requirements for a real-time OS, Windows NT (Microsoft), widely used as a PC OS, is adequate as a general- purpose OS but is not adequate for real-time OS. Firstly, Windows NT is able to sup- port multi-threading but is not suitable for real-time scheduling because it does not provide enough priorities and it is impossible to define clearly a tiny time slice. For example, Windows NT provides a good hardware interface. However, since Pentium power management interrupts the system for an unpredictable time, time analysis of 344 9 CNC Architecture Design an application is very difficult and development of a reliable system is impossible. Also, it is impossible to use a small real-time clock pulse because Windows NT does not provide a tiny programmable timer. Besides, Windows CE 2.0, which is widely used as an embedded system OS, is not suitable for medium-sized or large-sized sys- tems. It is only useful for small systems having a long performance index latency, and few allocable priorities. Table 9.1 Comparison of performance indices of three RTOS (times: μ s) Performance Index System A System B System C Task Switching Avg. 5.47 4.68 2.64 Latency Max. 23.13 10.68 5.73 ISR Avg. 11.26 8.78 7.66 Latency Max. 19.23 14.52 25.68 Scheduling Latency Avg. 25.95 4.73 6.36 Max. 39.0 10.14 32.25 In addition to the above-mentioned operating systems, various real-time OSs, such as CHORUS/OS, IRIX, LynxOS, OS-9, p-SOS, QNX, RT-mach, SORIX 386/486, VRTX, and VxWorks have been used. However, the source code of the application developed for one particular OS cannot be reused on a different OS, since each OS has its own code format, such as API and system calls. To overcome this compati- bility problem, POSIX 1003.4, which is based on POXIS, was established, but it can be expected that a lot of time will be needed for perfect standardization. 9.10 Hardware and Operating Systems In the case of the design of real-time systems, one of the key considerations is how to integrate the hardware components for equally distributing task load and how to operate the real-time OS to manage hardware resources. Therefore, it is important to define a multi-processing hardware architecture allowing combination of multiple processors for handling particular tasks, input/output processors and the operating system of a multi-processing system. 9.10.1 Architecture of Multi-processing Hardware As the hardware architecture for multi-processing systems, a bus structure has been widely used. Bus structures are classified into two types; one is the common bus type, where one bus is shared by multiple processors, and the other is the standard bus type, where a computer unit with a heterogeneous local bus is connected to a standard bus (e.g., Multi-bus and VME bus). 9.10 Hardware and Operating Systems 345 I/O Monitor Keyboard FDD HDD CUP1 (Graphic) CPU2 (Graphic) Common-Bus CUP3 (PLC) CPU4 (Interpreter) CPU5 (Interpolation, Position) Drive I/O I/O Drive Drive I/O I/F I/F Local Bus NCK boardPLC board HDD Monitor Keyboard Drive Standard Bus MMC board Mem CPU1 Other I/O I/O Drive Drive CPU2 Mem1 Other I/F Local Bus CPU3 Mem1 Other Fig. 9.15 Architecture of multi-processing hardware having a bus structure For the sake of explanation, let us suppose that each bus type is applied to the CNC system. The common bus type shown in Fig. 9.15a is a structure where multiple processors, carrying out tasks such as PLC, MMI, interpreter, and interpolator, are connected via one bus, using the common memory and having their own individual input/output interfaces. It can be called a “closed” architecture, where system scaling is very difficult. The architecture shown in Fig. 9.15b implements several processor units execut- ing NCK, PLC, and MMC and all units are connected via a standard bus. Accord- ingly, expansion of such a system is easily possible only by adding process units for particular tasks to the standard bus. In this architecture, each processor unit commu- nicates with the other units via a common memory module. As mentioned above, in the bus-type architecture only one communications chan- nel is provided to processors, memory modules, and input/output devices. In this simple architecture, the common bus works basically as a passive device and com- munication between devices is controlled by the devices own bus interface. First, the processor that wants to transmit data or input/output to the processor has to check whether the bus and the counter device can be used. It must then transmit the data af- ter informing the device how to handle the transmitted data. The device that receives the data has to know that the message from the bus is its own. It must also be able to recognize the message and perform particular actions according to the message. However, the bus-type architecture has serious drawbacks due to having only one communications channel. If the bus does not work the entire system does not work. Also, the communication bandwidth of a system is restricted by the bus bandwidth. In addition, as the system becomes busy, the competition for the bus grows and the efficiency of the bus decreases drastically. Therefore, bus-type architecture is eco- nomical, simple, and flexible, but the application of this architecture is restricted to small-sized multi-processing systems due to the limitations of the bus. As hardware architecture for multi-processing, a distributed architecture can be considered instead of the bus-type architecture. The distributed architecture is re- garded as a loosely coupled type of architecture where more than one individual distributed computer system is integrated by a communication line, as shown in Fig. 9.16. Each system has its own operating system and memory and is operated 346 9 CNC Architecture Design I/O Drive Light Speed Serial Communication Mem MMC board PLC board MMC board NCK board I/O NCK/ PLC board Monitor Keyboard Drive Token Ring Communication (a) Dedicated Communication (b) Distributed Communication CPU1 I/F Other I/F CPU3 Mem CPU2 Mem Other I/O I/O Drive Drive CPU1 Mem Other I/F I/O I/O CPU2 Mem I/F Other I/F Mem CPU3 Other Drive Drive Fig. 9.16 Architecture of multi-processing hardware having a distributed structure individually. Only if necessary, does each system communicate with another system. The distributed system can access files located in another system via a communica- tion line and a busy system can pass tasks to another system that is less loaded. In this architecture, since the communication speed has a large influence on the perfor- mance of the entire system, the design should allow that tasks that need high-speed communication are always executed on the same processor taking into consideration the balanced distribution of tasks among processors. As shown in Fig. 9.16a, NCK and PLC which need high-speed communications are executed on the same unit. In contrast, the MMI unit, whose communication data is relatively small, communicates with the NCK/PLC unit via a high-speed serial communication line. Figure 9.16b shows another distributed architecture where the NCK, PLC, and MMI tasks are executed on each unit and combined using a ring-type high-speed communication line. In recent times, the sustained development of microprocessors makes it possi- ble for only one processor to carry out many tasks that could only be performed by multiple processors in the past. Accordingly, the old multi-processing system archi- tecture was replaced by an architecture where one processor performs multiple tasks, or threads, which denote the processes that were executed individually by multiple processors. As a system with one processor is a system that maximizes usage of the processor resource, this has an advantage in terms of cost. However, it has the dis- advantage that some trouble results in the malfunction of the whole system because one processor performs all the tasks. Also, because all the tasks of the CNC system are performed by one processor and memory, it is necessary to use a highly reliable, hard real-time OS that can guarantee regular execution of tasks within the allowable time and manage perfectly shared resources. 9.10 Hardware and Operating Systems 347 9.10.2 Operating System Configuration Not only integration of hardware for multi-processing but also configuration of op- erating systems must be considered. The configuration method for allocating and managing resources, protecting resources, preventing deadlocks, terminating abnor- mal execution, balancing input/output load, and balancing process load should be defined together with the configuration method of the hardware. As configuration methods for multi-processing operating systems, there are the master/slave method, separate executive method, and symmetrical method. In the master/slave architecture, the main processor only executes the OS and slave processors perform user applications, as shown in Fig. 9.17a. In this method, when it is necessary for the OS to handle a process that was executed by a slave pro- cessor, the OS generates an interrupt and waits for the processor’s interrupt handling. Depending on the number of slave processors and how often a slave generates an in- terrupt, the size of the waiting queue may be different. Although the slave processor has no task to run, it must wait for the master processor’s interrupt. If the slave pro- cessor performs only short and simple tasks, the master processor will have a large burden. If the main processor cannot respond to the requests of slave processors quickly, the capability of the slave processor is wasted. As a main processor plays the role of general-purpose processor, it performs not only arithmetic operations but also input/output operations while the slave processor only performs arithmetic oper- ations. Therefore, slave processors can effectively perform arithmetic operations but because input/output operations are done only through the master, a slave processor cannot perform these. In terms of reliability, if one slave processor does not work, the computing power is decreased by some amount but the whole system continues to work. However, if the main processor fails, the system can do no input nor output. Therefore, the main drawback of the master/slave architecture is that processors are not equal and only the main processor manages input/output operations. In conclusion, since malfunc- tion of the main processor makes execution of the system impossible, the reliability of this architecture is low but it is easy to implement this architecture. Therefore, this architecture is suitable for systems where the computing burden is well known and the main processor can manage task scheduling accurately. It is appropriate for asymmetric systems where the performance of the main processor is superior to that of the slave processor. As shown in Fig. 9.17b, in the case of separate executive architecture, each pro- cessor has an individual OS and interrupts from each processor are handled by the processor responsible. The data about the whole system is stored in a table and ac- cess to the table should be controlled based on the mutual-exclusivity mechanism. A task that is allocated to a particular processor is executed on that processor until the task is finished. Because this architecture is more reliable than the master/slave architecture, the malfunctionof one processor doesnot result in a halt of the entire system. However,it is not easy to restart the malfunctioning processor and synchronize it with the whole [...]... fundamental design of software architecture for CNC system modeling, kernel design, and communication among modules will be described in the case of Soft-NC design 10.2.1 CNC System Modeling To design the software architecture, system modeling of the processes and tasks to be performed on CNC system is needed The software modules of the CNC system consist of the OS and system kernel based on PC hardware and. .. Windows NT 10.2 Design of Software Architecture As previously mentioned, the software design of a CNC system must be done together with the design of the hardware and the operating system As the design of the software architecture belongs to the stage of developing MMC, NCK, PLC, and the system kernel, it is difficult to apply formal methodologies and regular rules and depends on the system designer’s know-how... determined hardware architecture and operating system 10.3 Design of Soft-NC System 10.3.1 Design of Task Module The task modules of the CNC system can be designed in unlimited combinations according to the specification of the CNC and the designer’s concept Typically, however, the functions of commercial systems can be classified as shown in Fig 10.3 and the major function of each module is as shown in... addressed In particular, Soft-NC, where a single processor is used and all functions of PC-NC are implemented as software tasks, will be described In addition, an open CNC architecture supporting openness of H/W and S/W of CNC systems will be discussed 10.1 Introduction The CNC system in the 1970s and 1980s was a multi-processor system with several 8-bit CPUs or 16-bit CPUs and an individual processor and memory... also called Soft-NC, and the functions of NC and PLC are designed as functional modules or software tasks in the multi-processing environment of a real-time OS Soft-NC has the aim of realizing the PC-NC architecture using software Therefore, the NC and PLC functions in Soft-NC are executed together in cooperation with user applications via the various internal services of the OS This type of system can... Therefore, the former CNC systems were closed systems, in which the design of the CNC system depends on the CNC maker’s hardware and firmware In the late 1980s, PCs built on Intel 80386 and 80486 processors having high computing power and based on 32-bit CPUs were introduced and so, naturally, PC-NC was developed using a PC system as base hardware for the CNC system Unlike the closed CNC system, where NC... Manage tool offset, tool life, and tool shape Utility Manage DNC, PLC monitoring, alarm, and data communication Kernel Manage screen display, key input, file management, application module handling, system boot up and external communication 10.3 Design of Soft-NC System 361 10.3.2 Design of the System Kernel In order to perform the independent tasks of the CNC system, such as the MMI, NCK, and PLC tasks... real-time system where NCK, MMI, and PLC should be executed within a specified time In order to design a CNC system that guarantees hard real- 9 .11 Summary 351 Fig 9.21 Coupled commercial CNC systems time property, a harmonized relationship between the functionality of real-time OS and the architecture of hardware and software has to be considered The kernel, being the core component of a real-time OS, provides... 9.10.3 CNC System Architecture As mentioned in the previous section, the configuration of multi-processing systems varies and there is a variety of advantages and disadvantages according to the architecture Some commercial CNC systems are configured based on the abovementioned architectures, while other systems use modifications of those architectures or combinations of them Figure 9.18 shows one example of. .. Acquisition Dedicated Bus Axis1 80196 Axis1 80196 Fig 9.18 Example of CNC systems having a standard bus based on the common bus, being the standard VME bus, and is a master/slave type that consists of a main processor, controlling the whole system, and slave processors and it is possible to add various kinds of slave processor In particular, a real-time master that manages the system entirely is connected . mentioned, the software design of a CNC system must be done to- gether with the design of the hardware and the operating system. As the design of the software architecture belongs to the stage of developing. processor and memory were assigned for each function. Therefore, the former CNC systems were closed systems, in which the design of the CNC system depends on the CNC maker’s hardware and firmware. In. also called Soft-NC, and the functions of NC and PLC are designed as functional modules or software tasks in the multi-processing environment of a real-time OS. Soft-NC has the aim of realizing

Ngày đăng: 11/08/2014, 20:21

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan