Control method for control software execution system

Abstract

To insure that a task is started once and runs for a prespecified time previously allocated for the task, the real time operating system according to the present invention computes lapse of time from a current point of time, writes the computed lapse of time in a counter, and makes the task run after the period of time written in the counter has passed.

Claims

What is claimed is:

1. A control method for a control software execution system in which a scheduler for switching between different tasks is provided in a real time operating system in a memory and a plurality of tasks each for executing control software is executed according to task switch control by said scheduler, the method comprising the steps of:

changing a value stored in a counter with each cycle of a real time clock;

reading and recording a first value stored in said counter immediately before a task is started;

reading and recording a second value stored in said counter immediately after said task is finished;

computing a last running time for said task from said first and second values;

computing a total running time for said task from a previous total running time and said last running time; and

recording said computed total running time.

2. A control method for a control software execution system in which a scheduler for switching between different tasks is provided in a real time operating system in a memory and a plurality of tasks each for executing control software is executed according to task switch control by said scheduler, the method comprising the steps of:

synchronizing operations of the control software execution system using a system clock having a system clock cycle not less than a time required to execute a task requiring a longest processing time;

computing a lapse of time from a current point of time to a point of time after which a task is to be run so that the task runs at a prespecified rate, said lapse of time being an integer multiple of a real time clock cycle that is a fraction of the system clock cycle;

writing said computed lapse of time in a counter;

making said task run after the lapse of time written in said counter has passed;

changing a value stored in a second counter with each cycle of the real time clock;

reading and recording a first value stored in said second counter immediately before a task is started;

reading and recording a second value stored in said second counter immediately after said task is finished

computing a last running time for said task from said first and second values;

computing a total running time for said task from a previous total running time and said last running time;

recording said computed total running time;

executing interrupt processing when interrupt is generated with a task having higher dispatching priority order;

specifying an expected total running rate for each task;

specifying allowance for a difference between said specified expected total running rate and the actual running time;

computing an expected total running time from the expected running rate including the specified allowance; and

determining an abnormal state of a task by comparing said expected total running time to the actual running time.

3. A control method for a control software execution system in which a scheduler for switching between different tasks is provided in a real time operating system in a memory and a plurality of tasks each for executing control software is executed according to task switch control by said scheduler, the method comprising the steps of:

synchronizing operations of the control software execution system using a system clock having a system clock cycle not less than a time required to execute a task requiring a longest processing time;

computing a lapse of time from a current point of time to a point of time after which a task is to be run so that the task runs at a prespecified rate, said lapse of time being an integer multiple of a real time clock cycle that is a fraction of the system clock cycle;

writing said computed lapse of time in a counter;

making said task run after the lapse of time written in said counter has passed;

changing a value stored in a second counter with each cycle of the real time clock;

reading and recording a first value stored in said second counter immediately before a task is started;

reading and recording a second value stored in said second counter immediately after said task is finished;

computing a last running time for said task from said first and second values;

computing a total running time for said task from a previous total running time and said last running time;

recording said computed total running time;

executing interrupt processing when interrupt is generated, with a task having higher dispatching order;

specifying an expected total running rate for each task;

specifying an allowance for a difference between said expected total running rate and the actual running time;

computing an expected total running time from the expected running rate including said specified allowance;

determining an abnormal state of a task by comparing said computed expected total running time to the actual running time;

determining whether or not said task is one affected by a tool;

selecting another tool if it has been determined that the task will be affected by the tool; and

restarting execution of a machining program specified by said selected tool.

4. A control method for a control software execution system in which a scheduler for switching between different tasks is provided in a real time operating system in a memory and a plurality of tasks each for executing control software is executed according to task switch control by said scheduler, the method comprising the steps of:

synchronizing operations of the control software execution system using a system clock having a system clock cycle not less than a time required to execute a task requiring a longest processing time;

computing a lapse of time from a current point of time to a point of time after which a task is to be run so that the task runs at a prespecified rate, said lapse of time being an integer multiple of a real time clock cycle that is a fraction of the system clock cycle;

writing said computed lapse of time in a counter;

making said task run after the lapse of time written in said counter has passed;

changing a value stored in a second counter with each cycle of the real time

reading and recording a first value stored in said second counter immediately before a task is started;

reading and recording a second value stored in said second counter immediately after said task is finished;

computing a last running time for said task from said first and second values;

computing a total running time for said task from a previous total running time and said last running time;

recording said computed total running time;

executing interrupt processing when interrupt is generated with a task having higher dispatching priority;

specifying an expected total running rate for each task;

specifying an allowance for a difference between said specified expected total running time and the actual running time;

computing an expected total running time from the expected running rate including said specified allowance;

determining an abnormal state of a task by comparing said computed expected total running time to the actual running time;

determining whether or not said task is one affected by a tool feed speed;

selecting another tool feed speed if it is determined that the task is affected by the tool feed speed; and

restarting execution of a machining program specified by said selected tool feed speed.

5. A control method for executing control software so as to execute switching between different tasks using a scheduler which is independent of a task priority system in a real time operating system having a plurality of tasks in a memory, the method comprising:

synchronizing operations of the control software execution system using a system clock having a system clock cycle which is at least equal to a time required to execute that task requiring a longest processing time;

computing a time period from a first time to a second time after which a task is to be run so that a task runs according to a prespecified parameter from the first time, said time period being an integer multiple of a real time clock period which is a fraction of the system clock cycle;

writing the time period in a counter; and

running a task after the time period written in the counter has passed.

6. A method according to claim 5 wherein said prespecified parameter is specified so that the task runs once in each cycle.

7. A method according to claim 5 wherein said prespecified parameter is specified so that the task runs at a prespecified rate.

8. A method according to claim 5 wherein said prespecified parameter is specified so that the task runs continuously.

9. A method according to claim 5 wherein said prespecified parameter is specified so that the task runs at a prespecified rate in a cycle.

10. A method according to claim 5 wherein said prespecified parameter is specified so that the task runs for a prespecified time in a cycle.

11. A control method for executing control software so as to execute switching between different tasks using a scheduler which is independent of a task priority system, in a real time operating system having a plurality of tasks in a memory, the method comprising:

synchronizing operations between an external event and a task of the control software execution system, using a system clock having a system clock cycle which is at least equal to a time required to execute that task requiring a longest processing time;

computing a time period from a first time to a second time after which a task is to be run so that a task runs according to a prespecified parameter from the current time, said time period being an integer multiple of a real time clock period which is a fraction of the system clock cycle;

writing the time period in a counter; and

running a task after the time period written in the counter has passed.

Description

FIELD OF THE INVENTION

The present invention relates to a control method for a control software execution system, and more particularly to a control method for a control software execution system for an NC unit for efficiently executing software (a control program) for controlling a numerical control unit (described as NC unit hereinafter).

BACKGROUND OF THE INVENTION

FIG. 73 is a block diagram showing general configuration of a control software execution system for a conventional type of NC unit, and in this figure the reference numeral 501 indicates an NC unit as a whole. Description is made hereinafter for general configuration of the conventional type of NC unit with reference to the hardware configuration in this NC unit 501.

In FIG. 73, designated at the reference numeral 1 is a main CPU for controlling operations of each section or executing computing required for numerical control, at 2 a system bus connecting section of the unit to each other, at 3 a ROM (non-volatile storage device) for storing control software or the like for realization of main functions of the NC unit 501, at 4 a RAM (volatile storage device) used for temporal data storage or as a work area.

Also in this figure, designated at the reference numeral 5 is a SIO interface section for transacting data with external devices by means of serial communications, at 6 a display unit for displaying a running state of the NC unit 501 or identifying an command given to the NC unit 501, at 7 a keyboard for giving commands to the NC unit 501 (input device), at 8 a servo control section for computing commands for controlling a servo motor. This servo control section 8 may comprise a dedicated CPU which is different from the main CPU 1.

Also in this figure, designated at the reference numeral 9 is a servo amplifier for electrically amplifying an command received from the servo control section 8 and driving a servo motor or a main shaft of machine tool (not shown), at 10 a servo motor for controlling a machining section of machine tool (not shown), at 11 a programmable control section (described as PC section hereinafter) for transacting data other than commands for servo control with the machine tool, at 12 a system clock (not shown) and an external interrupt signal inputted to the main CPU 1. The system clock is a clock signal for establishing synchronism for controlling the NC unit 501 as a whole. The external interrupt signal 12 is a signal for reporting an event (emergent state) such as power error or emergent stop to the main CPU 1.

Next, a description is made for operations. FIG. 74 is an explanatory view for explanation of a sequence for execution of analysis of a machining program for a control software execution system for the NC unit 501 shown in FIG. 73, and at first the main CPU 1 sequentially reads control software written in the ROM 3 via the system bus 2, and executes the contents.

In FIG. 74, in a machining program input processing 21, a machining program 20 is read via the SIO interface section 5 from the outside, and is stored in the RAM 4. Then, each block (a prespecified unit decided for each machining program to be inputted) is converted to internal data which can easily be processed internally.

Also in a correction computing processing 22, internal data for each block is processed and computed to obtain a travel. Also such parameters as a tool diameter or a tool length are corrected. Furthermore such operations as updation of internal coordinate values are executed. In a setting/display processing 23, various type of data for the NC unit 501 are displayed in the display unit 6. Also each of the various set-up data inputted by an operator using the keyboard 7 is stored in the RAM 4. In addition, in an interpolation processing 24, a travel for each shaft per minute time unit using a result of the correction computing processing 22.

In a servo processing 25, a result of the interpolation processing 24 is further converted to a travel for each shaft per minute time unit. Furthermore feedback control (not shown) is executed from a speed detector or a position detector (not shown herein) attached to the servo motor 10 or the machine tool (not shown) is executed. In a processing 26 by a programmable controller (described as PC hereinafter), control over peripheral devices around the machine tool such as input/output processing to and from the machine tool or the main shaft is executed.

As described above with reference to FIG. 73, the NC unit 501 can respond to an emergent state other than the normal processing flow such as emergency stop by receiving the external interrupt signal 12 and having interrupt processing executed. When the external interrupt signal 12 (Refer to FIG. 73) is inputted, the main CPU 1 executes a prespecified particular processing, and returns to the normal command after execution of the prespecified particular processing has been finished.

FIG. 75 is a concept view showing interrupt processing. In this figure, reference numerals 30 to 36 indicate a normal command, 37 to 40 indicate an interrupt command, and 41 indicates an command for return to normal command respectively. For instance, when an external interrupt signal 12 (Refer to FIG. 73) is inputted while the main CPU 1 executes a normal command 33, the main CPU 1 detects an interrupt after execution of the normal command 33, and starts execution of an interrupt command 37 specified previously. Then after execution of interrupt commands 37 to 40 is finished, the main CPU 1 executes the return command 41, returns to the normal command 34, and then executes normal commands 35, 36.

It should be noted that, if a time required for interrupt processing becomes longer, the possibility of multiple interrupt in which another interrupt is inputted during execution of interrupt processing becomes higher, and if any interrupt is inhibited during executing of interrupt processing, a quick response to an interrupt request becomes impossible, and for the reasons as described above it is desirable to make the time for interrupt processing as short as possible.

By the way, control software for the NC unit 501 has the features as described below.

At first, because of the variety of functions to be realized by the control software for the NC unit 501, a number of required software is very large, and many people are required to be involved in development of the software.

Secondly, a response time (turn around time, dead line) required for execution of each function of control software for the NC unit 501 is different. For instance, in the servo processing 25 (Refer to FIG. 74), if some delay occurs in computing a result of processing, cutting is stopped, a work becomes a defective product, so that real time processing is required. On the other hand, in such a processing as display on the display unit 6, even if some delay occurs, not trouble is generated, so that real time processing is not required.

Thirdly, a processing by control software for the NC unit 501 is not of a batch type, nor of a compiler type (in which an entire machining program is analyzed from its beginning to the end and then all the moving data for a servo is outputted at once), but of an interpreter type (in which a machining program is divided to several blocks, the blocks are analyzed one by one, and also the moving data for servo is outputted little by little).

Fourthly, there are many types of interrupt processing to be executed by the main CPU 1.

Because of these features, generally control software for the NC unit 501 is based on a real time operating system (described as RTOS hereinafter), and usually a task for each function to be executed under the control is regarded as an execution unit.

Next, a description is made for a method of controlling each task with the RTOS. To check dispatching priority of each task at a specified time interval or to delay execution of a task by a specified period of time, generally a timer interrupt (not shown) is loaded to the main CPU 1 (Refer to FIG. 73) at a certain cycle. This is called system clock.

Also the RTOS checks a state of each task each time system clock interrupt is generated, stops a task in execution, and has other task executed. This is called scheduling or dispatch.

Furthermore in the RTOS, dispatching priority (priority in execution) is assigned to each task. This dispatching priority means that, while a task having lower dispatching priority is being executed, if a task having higher dispatching priority is ready for execution, execution of the task having lower dispatching priority is interrupted and the task having higher dispatching priority is executed. This is called preempt of task.

FIG. 76 is a timing chart showing a relation in terms of time between operations in each task, and in this figure, a time required for processing largely varies in such a task as the correction computing task because of complicatedness of a task to be computed. Generally a system clock cycle is decided assuming a task requiring the longest processing time. As a result, when other task is executed, idle time when the main CPU 1 is not executing any effective processing, as T1 shown i FIG. 76, is generated. Also it should be noted that, in FIG. 76, when there is not any other processing to be executed, a processing is waited in a loop in the RTOS as described above.

Generally, the RTOS has a function to run a task at a specified cycle or a function to measure a running time of a task, but these time-related factors can only be controlled or measured with a time unit which is a multiple of an integral number of the system clock .DELTA.T.

Among the three tasks shown in FIG. 76, a processing time (computing time) for the servo processing task, display setting task is kept constant respectively. However, in the correction computing task, a processing time largely varies according to contents of a machining program. On the other hand, the servo processing task executes data communications or the like to the servo amplifier 9, so that the task is run once for one system clock cycle. Otherwise, data for running the servo motor 10 forward the amplifier unit can not be transmitted, and operation of the servo motor 10 is stopped.

For this reason, control is provided by, for instance, terminating execution of the correction computing task for each block of a machining program so that a time for running once will not become excessively long. On the contrary, however, even if a processing time for the correction computing task is short and a total of processing time for the three tasks is 1/N (N: an integral number) of the system clock, each task runs only once for each system clock cycle. Because of this restriction, there is an upper limit for cutting feed speed in an NC unit. For this reason, if each task can run twice for each system clock cycle, it is possible to double the cutting feed speed, and the machining time is reduced to approximately 1/2 of the original one as shown in FIG. 77.

The NC unit 501, which executes control software under control by the RTOS as described above, has various types of operating mode. The operating modes include, for instance, a state where a work is cut by means of automatic operation or in the manual mode, or a case where real machining is not executed and a graphic tool path is displayed for checking correctness of the machining program.

Also as a means for inputting a machining program, in addition to the EIA format which is a standard machining program for the NC unit 501, for instance, an automatic programming is available. This is for automatically controlling a speed or a position of tool, or an operation thereof such as in a case where, when data for a tool to be used, a form of a work, and a final machine form or other parameters are inputted and as a result, the final form is automatically provided as a result of machining as shown in FIG. 78A and FIG. 78B.

A task for analyzing the EIA format or a machining program such as an automatic programming as described above executes the processing as shown in FIG. 79. Namely, ZZZ1 is a processing for reading a machining program by 1 block and storing the block in a work area on a memory. ZZZ2 is a processing for analyzing the data read in ZZZ1 and preparing data to be delivered to the correction computing task.

ZZZ3 is a processing for issuing SVC to terminate a task. With this SVC, this task delivers the right for using the main CPU 1 to other task. Then the system enters the stand-by state until, for instance, the correction computing task demands the next data and the machining program starts the analysis task.

However, in the control software execution system for an NC unit having the configuration as described above, the problems as described below occur.

At first, an order for execution of tasks each realizing functions of an NC unit can be decided only according to the dispatching priority, and for this reason it is impossible to cyclically run all tasks, or to decide an execution time for each task.

Secondly, even in a case where task control is carried out according to timing, the time unit is limited to a time unit of the system clock (a multiple of an integral number of system clock).

Thirdly, it is extremely difficult to decide dispatching priority for each task, and in a case where three or more tasks are involved therein, so called the priority inversion (a phenomenon of inversion of dispatching order in which a task having lower dispatching priority stops execution of a task having higher dispatching order) may occur, so that there are several restriction for practical operations in the execution system based only on the dispatching order.

Fourthly, as dispatching priority between tasks is decided when a system is prepared, there exist tasks short in a processing time, or those having, on the contrary, excessive processing time.

Fifthly, as a processing requiring specification of a cycle is treated as an interrupt, the processing must be short, which is one of the restrictions over the system operations.

Sixthly, irrespective of the fact that a load to each task varies according to a running state or running mode of an NC unit, a running state of each task is decided when the system is generated, and the state can not be changed later.

Seventhly, there is no means for determining whether a task is in the normal state or not (a task has fallen in an abnormal state).

Eighthly, irrespective of size of one block in a machining program, a machining program analysis task ends each time analysis of one block is finished, so that a processing time may become short or excessive according to size of one block.

SUMMARY OF THE INVENTION

It is an object of the present invention to allocate an appropriate processing time to each task by realizing flexibility in a system for specifying an execution for each task and thereby obtain an effective control method for a control software execution system.

In the control method for a control software execution system according to the present invention, control of tasks each realizing a function of an NC unit respectively can be executed by a small time unit, furthermore a cycle for starting the task can easily be specified, so that waste of the time allocated to each task can be reduced, and furthermore a task can be controlled according to the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control for tasks each realizing a function of an NC unit can be executed by the running time, waste of the time allocated to each task can be reduced, and furthermore a task can be controlled according to the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, continuous running time can be insured for task each realizing functions of an NC unit respectively, so that waste of the time allocated to each task can be reduced, and furthermore a task can be controlled according to the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control according to an accurate starting time and a running time can be executed for tasks each realizing a function of the NC unit respectively, so that waste of the time allocated to each task can be reduced, and furthermore a task can be controlled by the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control according to an accurate starting time and a continuous running time for tasks each realizing a function of the NC unit respectively can be executed, so that waste of the time allocated to each task can be reduced, and furthermore a task can be controlled within the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, an accurate executing time for tasks each realizing a function of the NC unit respectively can be acquired, so that allocation of a running time for each task can easily be executed, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, an accurate executing time for a task for realizing functions of an NC unit as well as for an interrupt processing can be acquired, so that allocation of a running time for each task can easily be executed, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, a running time for all tasks can be recorded, and furthermore a rate of a running time for all tasks can be specified, so that allocation of a running time for each task can be optimized. For this reason, an accurate executing time for interrupt processing can be acquired, and allocation of a running time for each task can easily be executed, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, allocation of a running time for each task can automatically be optimized according to operating conditions of the unit, so that wasting time in each task can be eliminated. Namely, a task can be run only for a period of time appropriate for the task in each mode by changing a running rate for a task according to an operating mode of the an NC unit, so that an executing speed of an NC unit can be improved.

In another control method for a control software execution system according to the present invention, a rate for running time allocated to each task can be changed while operating the NC unit, wasting time in each task can be eliminated, and a machining time in machining of repetition can be shortened by automatically setting allocation of a running time for each task realizing a function of an NC unit to be optimal.

In another control method for a control software execution system according to the present invention, a task in which an error has been generated can be defined by comparing the running time. Namely when an error has been generated in a task realizing a function of an NC unit, the fact can be detected, and for this reason determination can immediately be made that an error has been generated in the NC unit.

In another control method for a control software execution system according to the present invention, when it is determined that an error has occurred in automatic machining by the NC unit, automatic machining is executed again by changing a tool, so that the possibility that machining process stops due to occurrence of an error can be reduced, and continuous machining is automatically realized, and for this reason reliability for continuous running of an NC unit can be improved.

In another control method for a control software execution system according to the present invention, when it is determined that an error has occurred in automatic machining by the NC unit, automatic machining is executed again by changing a tool speed, so that the possibility that machining stops due to occurrence of an error can be reduced, and continuous machining can automatically be executed, and for this reason reliability for continuous running of an NC unit can be improved.

In another control method for a control software execution system according to the present invention, when it is determined that an error has occurred in automatic machining of the NC unit, automatic machining is executed again by other machining program, so that the possibility that machining stops due to occurrence of an error can be reduced, and for this reason continuous machining can automatically executed and reliability for continuous running of an NC unit can be improved.

In another control method for a control software execution system according to the present invention, a running time for tasks each realizing a function of an NC unit respectively is limited, so that each task will not run for a period of time exceeding an allocated period of time for the task, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control for tasks each realizing a function of an NC unit respectively can more precisely be executed, and a processing time for each task can be optimized, so that waste of the time can be reduced and a total processing time can be shortened. In addition, the system itself can determine abnormal conditions in the control software execution system for the NC unit, so that a processing for avoidance from occurrence of abnormal conditions therein can easily be executed.

In another control method for a control software execution system according to the present invention, control according to a period of time for tasks each realizing functions of an NC unit can be executed with a small time unit, furthermore a cycle for starting a task can easily be specified so that waste of the time allocated for each task can be reduced, and furthermore a task can be controlled according to the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control according to a rate for a running time for tasks each realizing a function of an NC unit respectively can be executed, so that waste of the time allocated for each task can be reduced, and furthermore a task can be controlled according to the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, a continuous running time for tasks each realizing a function of an NC unit respectively can be insured, so that waste of the time allocated for a task can be reduced, and furthermore a task can be controlled according to the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control according to an accurate starting time and a running time for tasks each realizing a function of an NC unit respectively can be executed, so that waste of the time allocated for each task can be reduced, and furthermore a task can be controlled according to the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control according to an accurate starting time and a continuous running time for tasks each realizing a function of an NC unit respectively can be executed, so that waste of the time allocated for each task can be reduced, and furthermore a task can be controlled within the running time, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, an accurate executing time for tasks each realizing a function of an NC unit respectively can be acquired, so that allocation of a running time for each task can easily be executed, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, an accurate executing time for task each realizing a function of an NC unit respectively and an interrupt time can be acquired, so that allocation of a running time for each task can easily be executed, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, a running time for all tasks can be recorded, and furthermore a rate of the running time for a task can be specified, so that allocation of a running time for each task can be optimized. In addition, an accurate executing time for an interrupt can be acquired, and allocation of the running time for each task can easily be executed, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, allocation of a running time for each task can automatically be optimized according to operating conditions of the unit, waste of the time can be eliminated in each task. Namely, a task can be run only for a period of time appropriate to the task in each mode by changing a running rate for a task according to an operating mode of the NC unit, and an executing speed of an NC unit can be improved.

In another control method for a control software execution system according to the present invention, a rate of running time allocated for each task can be changed while running the NC unit, so that waste of the time thereof can be eliminated in each task, and by automatically optimizing a rate of the running time for tasks each realizing a function, the machining time in machining of repetition can be shortened.

In another control method for a control software execution system according to the present invention, a task in which an error has been generated can be defined by comparing the running time. Namely when an error has been generated in the task realizing a function of the NC unit, the fact can be detected, so that determination can immediately be made that an error has been generated in the NC unit.

In another control method for a control software execution system according to the present invention, restriction according to a running time for tasks each realizing a function of an NC unit can be executed, so that a task will not run exceeding an allocated period of time for each task, and because of this feature system construction becomes easier.

In another control method for a control software execution system according to the present invention, control for tasks each realizing a function of an NC unit respectively can more precisely be executed, so that a processing time for each task can be optimized, and for this reason waste of the time thereof can be reduced, and a total processing time can be shortened. In addition, the system itself can determine abnormal conditions of the control software execution system for an NC unit, so that a processing for avoidance from occurrence of abnormal conditions therein can easily be executed.

Other objects and features of this invention will become understood from the following description with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a block diagram showing general configuration of a control software execution system for an NC unit according to Embodiment 1;

FIG. 2 is an explanatory view showing structure of a task running cycle table;

FIG. 3 is an explanatory view showing structure of a task running queue list;

FIG. 4 is a flow chart showing a processing sequence when the control software execution system for an NC unit according to Embodiment 1 prepares a task running queue list;

FIG. 5 is an explanatory view showing structure of a running queue list;

FIG. 6 is an explanatory view showing a state after a block has been added to the running queue list;

FIG. 7 is a flow chart showing a processing sequence for task start interrupt processing;

FIG. 8 is a flow chart showing a processing sequence for general interrupt processing;

FIG. 9 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 2;

FIG. 10 is an explanatory view showing data structure required in the control software execution system for an NC unit according to Embodiment 2;

FIG. 11 is a flow chart showing a processing sequence for standard interrupt processing;

FIG. 12 is a flow chart showing a processing sequence for running time alarm interrupt processing;

FIG. 13 is a flow chart showing a processing sequence for general interrupt processing;

FIG. 14 is a flow chart showing a sequence for a processing by a scheduler;

FIG. 15 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 3;

FIG. 16 is an explanatory view showing structure of a task end tick number list;

FIG. 17 is an explanatory view showing structure of a task continuous running insurance table;

FIG. 18 is a flow chart showing a processing sequence for continuous running interrupt processing;

FIG. 19 is a flow chart showing a processing sequence for general interrupt processing;

FIG. 20 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 4;

FIG. 21 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 6;

FIG. 22 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 6;

FIG. 23 is a flow chart showing a processing sequence for general interrupt processing;

FIG. 24 is a flow chart showing a sequence for a processing by a scheduler;

FIG. 25 is a flow chart showing a sequence for a processing by a scheduler;

FIG. 26 is a flow chart showing a processing sequence for a task for interrupt processing;

FIG. 27 is a flow chart showing a processing sequence for general interrupt processing;

FIG. 28 is a flow chart showing a sequence for a processing by a scheduler;

FIG. 29 is a flow chart showing a processing sequence for running mode selecting process;

FIG. 30 is a flow chart showing a processing sequence for optimizing allocation of a task running time;

FIG. 31 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 11;

FIG. 32 is a flow chart showing a processing sequence for an error determining task;

FIG. 33 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 12;

FIG. 34 is a flow chart showing a processing sequence for a tool selecting process;

FIG. 35 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 13;

FIG. 36 is a flow chart showing a processing sequence for a speed re-computing process;

FIG. 37 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 14;

FIG. 38 is a flow chart showing a processing sequence for a selecting process of other machining program;

FIG. 39 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 15;

FIG. 40 is a flow chart showing a processing sequence for task stop interrupt processing;

FIG. 41 is a flow chart showing a processing sequence for general interrupt processing;

FIG. 42 is a flow chart showing a sequence for a processing by a scheduler;

FIG. 43 is a flow chart showing a processing sequence for a machining program analysis task;

FIG. 44 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 17 (21);

FIG. 45 is a flow chart showing a processing sequence in which the control software executing system for an NC unit according to Embodiment 17 prepares a task running queue list;

FIG. 46 is a flow chart showing a processing sequence for task start;

FIG. 47 is a flow chart showing a processing sequence for system clock interrupt processing;

FIG. 48 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 18 (24, 25, 26, 27, 28);

FIG. 49 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 18;

FIG. 50 is a flow chart showing a sequence for a reference cycle reset process;

FIG. 51 is a flow chart showing a sequence for a running time alarm process;

FIG. 52 is a flow chart showing a sequence for system clock interrupt processing;

FIG. 53 is a flow chart showing a sequence for a processing by a scheduler;

FIG. 54 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 19;

FIG. 55 is an explanatory view showing structure of a task end clock number list;

FIG. 56 is an explanatory view showing structure of a task continuous running insurance table;

FIG. 57 is a flow chart showing a sequence for a task continuous running terminate process;

FIG. 58 is a flow chart showing a sequence for system clock interrupt processing;

FIG. 59 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 20;

FIG. 60 is a block diagram showing general configuration of the control software execution system for an NC unit according to Embodiment 22 (23);

FIG. 61 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 22;

FIG. 62 is a flow chart showing a sequence for system clock interrupt processing;

FIG. 63 is a flow chart showing a sequence for processing by a scheduler;

FIG. 64 is a flow chart showing a sequence for processing by a scheduler;

FIG. 65 is a flow chart showing a sequence for system clock interrupt processing;

FIG. 66 is a flow chart showing a sequence for processing by a scheduler;

FIG. 67 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 27;

FIG. 68 is a flow chart showing a processing sequence for an error determining task;

FIG. 69 is an explanatory view showing data structure required for the control software execution system for an NC unit according to Embodiment 28;

FIG. 70 is a flow chart showing a processing sequence for a task stop process;

FIG. 71 is a flow chart showing a sequence for system clock interrupt processing;

FIG. 72 is a flow chart showing a sequence for processing by a scheduler;

FIG. 73 is a block diagram showing general configuration of a control software execution system for an NC unit based on conventional technology;

FIG. 74 is an explanatory view showing an analysis executing sequence for a machining program for the control software execution system for NC unit;

FIG. 75 is a concept diagram showing interrupt processing;

FIG. 76 is a timing chart showing a relation in terms of times between operations in each task;

FIG. 77 is a timing chart showing a relation in terms of times between operations in each task;

FIGS. 78A and 78B are explanatory views showing a state of an automatic program operation; and

FIG. 79 is a flow chart showing a processing sequence for an analyzing task process.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Detailed description is made for the control software execution system according to the present invention with reference to related drawings.

At first description is made for configuration in Embodiment 1 of the present invention. FIG. 1 is a block diagram showing general configuration of a control software execution system A1 for an NC unit according to Embodiment 1, and this control software execution system A1 comprises the following elements. In this figure, designated at the reference numeral 1 is a main CPU for controlling operations of each section or executing computing required for numerical control, at 2 a system bus for connecting various sections in the system to each other, at 3 a ROM (non-volatile storage means) for storing therein control software for realizing main functions of the NC unit or the like, at a RAM (volatile storage memory) used for temporally storing data or as a work area, at 5 an SIO interface section for transacting data with external devices by means of serial communications.

Also in FIG. 1, designated at the reference numeral 6 is a display unit for displaying running condition of the NC unit or displaying data to identify each command given to the NC unit, at 7 a keyboard as an input means for giving commands to the NC unit, at 8 a servo control section for computing commands for controlling a servo motor, and the servo control section 8 may have a dedicated CPU different from the main CPU 1.

Further, in FIG. 1, designated at the reference numeral 9 is a servo amplifier for electrically amplifying a command received from the servo control section 8 and driving a servo motor or a main shaft of machine tool (not shown), at 10 a servo motor for controlling a machining section of the machine tool (not shown), at 11 a programmable control section (described as PC section hereinafter) for transacting data other than commands for servo control with the machine, and at 12 a system clock (not shown) and an external interrupt signal each inputted into the main CPU 1. Herein the system clock is a clock signal for establishing synchronism to control the entire NC unit as a whole, while the external interrupt signal is a signal for reporting generation of invents (emergent invents) such as power error or emergency stop to the main CPU 1.

In FIG. 1, the reference numeral 200 indicates an internal interrupt signal, and generation or timing of this signal is controlled by the main CPU 1. The reference numeral 201 indicates a real time clock, which is controlled by the main CPU 1 and executes such operations as controlling the internal interrupt signal 200 or reading time. Furthermore, the reference numeral 202 is a counter register provided inside the real time clock 201, and the counter register decrements the value by 1 each time a clock signal is inputted from outside, and when the value is decremented to 0, the default value is set or its operation is kept down until a value is again set from the main CPU 1. Selection of this operation, and setting or changing the default value can be freely executed by main CPU 1. The reference numeral 203 indicates a quartz oscillator for outputting a clock signal to the real time clock 201.

Then, a description is made for operations of the control software execution system A1 for the NC unit having the configuration as described above. Generally, as a system clock, a frequency from 60 Hz to 100 Hz (60 to 100 oscillations per second). If the system clock is set to a value higher than that described above, times of execution for processing the interrupt becomes too large, and as a result time when a task executing a function of the NC unit can run is reduced. However, as the minimum time unit is too large for minute control of a task, interrupt is not used, and for instance the general purpose real time clock 201 is used. When a clock signal having a frequency of 10 MHz is inputted from the quartz oscillator 203 to the real time clock 201, the real time clock 201 decrements the internal counter register 202 one by one. If a clock signal having a frequency of 10 MHz is inputted, measurement can be executed at a unit of 0.1 .mu.s (0.0000001 sec).

The real time clock 201 also can play a role as a programmable interval timer. This is a function to generate interrupt to the CPI 1 when a specified default value is zero (0). Generally the real time clock 201 has a plurality of channels available for either purpose as described above.

An execution cycle of each task is registered by SVC (supervisor call, or a service call) previously or when the task is started. Herein the SVC is a generic name of operations in which a task demands some type of service to the RTOS. The phrase of "some type of service" means an operation such as stopping execution of the task itself, communicating with other tasks, starting execution of other task (starting executing) or stopping the execution until some necessary conditions are established.

The data is registered by the RTOS in a "task running cycle table" 50 as shown, for instance, in FIG. 2. FIG. 2 shows data configuration having a "running cycle" and "times of repetition". Herein the running cycle is defined as a value indicating a number of clocks until the next running cycle of the task is started, and the times of repetition is defined as a value indicating how many times the cycle should be started. Herein it is assumed, for instance, that, if this value is a minus one, the value indicates the .infin., and in that case the task is started repeatedly. Using this task running cycle table 50, the RTOS prepares a "task running queue list" 51 as shown in FIG. 3 each time the task is started.

In FIG. 3, running queue blocks 52 in the task running queue list 51 are blocks comprising "ink" indicating a position of the next running queue block, "task name", "running schedule clock number" indicating lapse of time from a current point of time required until the running cycle is started, "simultaneous task name" indicating task name or names required to be run simultaneously, and "TCB pointer" indicating a position of TCB.

Next, a description is made for concrete operations with reference to FIG. 4. For convenience in description, it is assumed herein that a clock signal inputted into the quarts oscillator 203 has a frequency of 10 MHz and the internal counter register 202 decrements by 1 once for 0.1 .mu.sec. Namely, it is assumed herein that the minimum time unit in measurement is 0.1 .mu.sec. Also it is assumed in the following description that interrupt is inhibited during certain processing such as operation of a list. Furthermore when preparing the running queue block 52, as a task name, name indicating the task is previously registered.

FIG. 4 shows a sequence when the RTOS prepares the task running queue list 51. In this figure, at first in step B1, a requested running cycle is converted to an internal clock number. For instance, if the requested running cycle is 10 msec, the internal clock number is 100,000 (100,000.times.0.1 .mu.sec.=10 msec). This value is used as TR (request time). Then in step B2, determination is made as to whether any running queue block exists in the current running queue list or not, and if it is determined that there is no running queue block, system control shifts to processing in step B3, and on the contrary if it is determined that there is any running queue block, system control shifts to processing in step B6.

Step B3 indicates a processing in a case where there was no running queue block 52 in the running queue list 51, and in this processing a running queue block 52 is prepared and in step B4 it is placed at the head of the running queue list 51. Then in step B5 a running schedule clock number for the header block in the running queue list 51 is set in a counter register 202 of the real time clock 201.

Step B6 is a processing in a case where it is determined that there is the running queue block 52 in the running queue list 51, and in this processing a last task running time LT is set to 0, and a task index TI is set to 1. Herein the LT is defined as a parameter for computing how many clocks are required until execution of the task is started, and T1 is an index indicating the tasks in the running queue list. Then in step B7, a value provided by the counter register 202 of the current real time clock 201 is read, and the value is included in a running schedule clock number for the header running queue block 52. Then in step B8, determination is made as to whether all the running queue blocks 52 in the running queue list 51 have been checked (or traced) or not.

As a result, in step B8, if it is determined that all the running queue blocks 52 have not been checked, system control shifts to processing in step B9. Step B9 is a processing executed when it was determined that there was the running queue block 51 in the running queue list 51, and a running schedule clock number for the running queue block 52 shown in TI is fetched from the running queue list 51, and is added to LT.

Then in step B10, RT is compared to LT. Step B11 is a processing executed when it was determined that RT was equal to LT (RT=LT), and in this processing the running queue block 52 is prepared. Then a running schedule clock number is set to zero (0). Step B12 is a processing for linking, for instance, the running queue block 52 prepared in step B11 to a simultaneous task name in blocks indicated by TI in the running queue list 51. Herein the term "linking" is defined as an operation for, for instance, placing an address for a block prepared in 11 at a position of a simultaneous task name for the running queue block 52 indicated by TI; in brief an operation for locating a block prepared in step B11 at a place which can easily be found out.

Step B13 is a processing executed in a case where RT is larger than LT (RT>LT), and a value of TI is incremented by 1, and then system control returns to step B8 to repeat the same processing.

Step B14 is a processing executed in a state where RT is smaller than LT (RT<LT), and in this processing the running queue block 52 is prepared. Then a running schedule clock number is set to a value of RT-LT+(a running schedule clock number for the running queue block 52 just 1 before that indicated by TI). Then in step B15, a running schedule clock number for a block indicated by TI is set to a value of LT-RT, and in step B16, a running queue block 52 prepared in step B14 is inserted between the running queue block 52 indicated by TI and a block just ahead. Then, in step B17, determination is made as to whether the block inserted in step B16 is present in the head of the running queue list 51 or not, and if it is determined in step B18 that the inserted block is in the head of the running queue list 51, a running schedule clock number for the header block in the running queue list 51 is set in the counter register 202 of the real time clock 201.

In step B19, if it is determined in B8 that all the running queue blocks have been checked, the running queue block 52 with a running schedule clock number of RT-LT is prepared, and then in step B20, the running queue block 52 prepared in step B19 is inserted at the end of the running queue list 51.

FIG. 5 shows an example of the running queue list 51. In this example, a task A is started in 30 clocks from a current point of time and then a task B is started in further 20 clocks from the start of the task A (namely in 50 clocks from a current point of time). If a request for starting a task C in 35 clocks from a current point of time is issued to the RTOS, the running queue list becomes as shown in FIG. 6 according to the sequence shown by the flow chart in FIG. 4.

In step B5 or step B18 shown in FIG. 4, a running schedule clock number for a header block in the running queue list 51 is specified in the counter register 202 of the real time clock 201, and after a time equivalent to the specified clock number has passed, a request for "task start interrupt" is generated. Description is made for this task start interrupt processing with reference to FIG. 7.

In FIG. 7, in step C1, a processing for separating the header running queue block 52 in the running queue list 51 from the running queue list 51 is executed, and then whether the running queue list 51 has become empty or not is checked in step C2. Step C3 is a processing in a case where it was determined that the running queue list 51 had become empty, and task start interrupt is inhibited by, for instance, setting the counter register 202 of the real time clock 210 to zero (0) so that a subsequent request for task start interrupt will not be generated.

Step C4 is a processing in a case where it is determined in step C2 that there remains any running queue block 52 in the running queue list 51 and in the processing, a running schedule clock number in the header running queue block 52 is set in the counter resister 202 of the real time clock 201. Then in step C5, a start task is taken out from the running queue block 52 separated in step C1, and TCB for the task is placed at the head of a TCB queue matrix.

Then in step C6, cycle times in the task running cycle table 50 (Refer to FIG. 2) for the task just run is checked. Step C7 is a processing in a case where time of running are indefinite (negative), and in this processing the running schedule clock number in the running queue block 52 for this task is converted to a running cycle of the task running cycle table 50 and the running queue block is added to the running queue list.

Step C8 is a processing in a case where the running times is a positive integer, and the running schedule times is decremented by 1. Then in step C9, the running queue block 52 for this task is prepared for the task through the processing shown in FIG. 4, and is added to the running queue list.

Step C10 is a processing in a case where running times is zero (0), and in this case no processing is executed, and the processing is terminated. After processing in steps C7 and C9, in step C11 system control jumps to a scheduler in the RTOS. A processing by the scheduler is the same as a processing by a scheduler in the conventional technology, and description thereof is omitted.

Next, a description is made for general interrupt processing other than interrupt for task start with reference to FIG. 8. Step D1 is a header of interrupt processing in case where an interrupt is generated, and at first generation of other interrupt is inhibited. However, generally this processing is automatically generated when an interrupt is generated by the main CPU 1. Step D2 is a processing for acquiring an unused ICB from an ICB pool (a space for ICBs not used yet therein).

Then in step D3, an environment for execution of an interrupt of the task itself is stored in the ICB. Storage of a header address in a processing in step D12 as an address for a command to be executed next is also included. Also in step D4, the ICB just prepared is added to the ICB queue matrix to be executed by the scheduler. Then in step D5, inhibition of interrupt by step D is canceled. In this step and on, there is the possibility that interrupt is generated again. The processing described above, is for making an interrupt inhibited period of time as short as possible.

Then in step D6, determination is made as to whether the interrupted processing is interrupt processing or RTOS or execution of a task. Step D7 is a processing in a case where, as a result of determination above, it is determined that the interrupted processing is interrupt processing or execution of RTOS, and in this case system control directly returns to the interrupted processing. On the contrary, step D8 is a processing in a case where it is determined that the interrupted processing is execution of a task, and in this case at first TCB for the interrupted task is searched. Then in step D9, an environment for execution of the interrupted task is stored in the TCB found in step D8.

Furthermore, in step D10, the prepared TCB is added to an order of priority in the TCB queue matrix to be executed by the scheduler. Also in step D11, system control jumps to the scheduler, and then returns from the scheduler to step D12, but this processing is not always executed immediately after system control has jumped to the scheduler, and sometimes system returns to step D12 after other ICB has been processed. Interrupt processing from this step and on is original interrupt processing specific to each interrupt, and the processing varies according to a case for interrupt. Furthermore, step D13 is a processing for terminating interrupt processing, and generally an command for return to an ordinary subroutine is issued, and according to this return command, system control returns to the ICB processing by the scheduler.

As described above, the control software execution system A1 for an NC unit according to Embodiment 1 has, in addition to functions of an RTOS having only the scheduling system generally based on priority, a function to control for starting a task at a more minute precision than a system clock, and executes control system for an NC unit.

With Embodiment 1, the control software execution system A1 for an NC unit can execute time control for tasks each realizing functions of the NC unit with a smaller unit, and furthermore can easily specify a cycle for starting a task. For the reasons as described above, waste of time allocated to each task can be reduced, and furthermore a task can be controlled within a running time allocated to the task, so that system construction becomes easy and also a processing speed in the NC unit is improved.

Next, a description is made for configuration in Embodiment 2 of the present invention. The contents in FIG. 9 showing general configuration of a control software execution system A2 for an NC unit according to Embodiment 2 is substantially the same as that in FIG. 1 relating to Embodiment 1. It should be noted that in Embodiment 1, an interrupt port for a real time clock 201 was used by only one channel, while three channels are used in the present embodiment.

Detailed description is made hereinafter for configuration thereof. The reference numerals 1 to 11 of this control software execution system A2 indicate the same components as those shown in FIG. 1 relating to Embodiment 1, the description thereof is omitted herein. In FIG. 9, the reference numeral 200 indicates an internal interrupt signal inputted into the main CPU 1. Generation and timing of this signal can be controlled by the main CPU 1. The reference numeral 201 indicates a real time clock, which is controlled by the main CPU 1, and controls an internal interrupt signal 200 or reads a time.

The reference numeral 202 indicates a counter register in the real time clock 201. The counter register decrements the value by 1 each time a clock signal is inputted from outside, and when the value is decremented to zero (0), the default value is set again. It should be noted that the default value can freely be set from the main CPU 1. The reference numeral 203 indicates a quartz oscillator for inputting a clock signal to the real time clock 201.

The reference numerals 204 and 205 indicate a second and a third counter registers each provided inside of the real time clock 201. The counter register decrements the value by 1 each time a clock signal is inputted from outside, and when the value is decremented to zero (0), the default value is set again or its operation is kept down until a value is again set from the main CPU 1. Selection of this operation, and setting or changing the default value can automatically be executed by CPU 1. Also the counter register 202, second counter register 204, and third counter register 205 can independently set and cancel respectively. The counter registers 202, 204 and 205 are used each for measurement of a task running time, a reference time interrupt, and a running time alarm in this embodiment.

Next, a description is made for operations of the control software execution system A2 of the NC unit. FIG. 10 shows data structure required for the present embodiment, and the reference numeral 210 indicates "a task start tick memo", and the RTOS records a value of the internal counter register 202 in the real time clock 201 shown in FIG. 9 right before the RTOS starts execution of a task, then computes a period of time in which the task ran by obtaining a difference between the recorded value and a value of the internal counter register 202 when the task is terminated and system control returns to the RTOS.

Also the reference numeral 211 indicates a region for storing "a reference cycle". One reference cycle is previously registered in the system. How long does each task run for each this cycle is specified previously. The specification may be executed with either a period of time or a number of ticks, but herein it is converted to a number of ticks for the sake of simplicity of description thereof.

Furthermore, the reference numeral 212 indicates "a task running state memo". A running rate of each task is registered by the SVC previously or when the task is started. For instance, a specified running cycle for each task is registered, namely if a task A is 10%, a task B is 5%, and a task C is 20%, and a reference cycle is 20 m/sec, the task A may run at 2 m/sec, the task B at 1 m/sec, and the task C at 4 m/sec for every 20 m/sec respectively.

Herein, in FIG. 1 like in Embodiment 1, assuming that a clock signal inputted to the quartz oscillator 203 is set to 10 MHz, the internal counter register 202 decrements the value by 1 for each 0.1 .mu./sec. Namely assuming that a minimum unit for measurement is 0.1 .mu./sec, each of the tasks A, B, and C may run by 20,000 ticks, 10,000 ticks, and 40,000 ticks respectively within a number of clocks of 200,000 ticks. This tick number is stored in a column of "running tick number" of the task running state memo 212. Herein for a task in which a rate for running is not specified, a value in this column is set to zero (0).

A column of "remaining running tick number" makes a copy of the column of running tick number each time one reference cycle is finished, and decrements by the tick numbers equal to those when the task ran last. The contents of this column for all the tasks may be set to zero (0) each time one reference cycle is finished. The sum of running tick number should naturally be smaller than a reference cycle. The error check thereof may be executed, for instance, each time a running tick number is newly registered to the task state memo. It should be noted that description for error check is omitted in the description below.

Then what is to be set in a column of "a number of times of repetition" is a number of times indicating how many times the task is to be started. For instance, if the value is a minus value, it will be indicated with a sign of .infin.. In this case, the task described above will be set to start repeatedly.

Also a column of "running inhibited flag" is used by a scheduler. The task in which this flag is ON is left out from the object for scheduling. Namely the task in which this flag is ON can not run even if the priority thereof is high.

Next, a description is made for operations of interrupt processing. The control software execution system A2 presets a value for a reference cycle 211 (Refer to FIG. 10) to the internal counter register 204 of the real time clock 201 (a programmable interval timer)(Refer to FIG. 9) before a task for protecting a running rate starts to run when the system control has actuated or the like.

FIG. 11 is a flow chart for explanation of a sequence for reference cycle interrupt processing, and step E1 is a header step of interrupt processing in a case where an interrupt is generated and at first generation of other interrupt is inhibited herein. Normally, this processing is automatically executed by the main CPU 1. In step E2, the sum of remaining running tick numbers of the task running state memo 212 (Refer to FIG. 10) is obtained. In step E3, determination is made as to whether the sum thereof is more than zero (0) or not, and in a case where it is determined that the sum is not more than zero (0), an error processing is executed in step E4, however, this case does not normally occur, so that the description thereof is omitted herein.

On the contrary, in step E3, in a case where it is determined that the sum thereof is more than zero (0), the value in the column of running tick number of the task running state memo 212 (Refer to FIG. 10) is copied to the column of remaining running tick number for each task. Then, in step E6, a value of the reference cycle 211 (refer FIG. 10) is set again to the internal counter register 204 of the real time clock 201 (a programmable interval timer) (Refer to FIG. 9).

Then, in step E7, a processing for turning OFF running inhibited flags of all the tasks of the task running state memo 212 (Refer to FIG. 10) is executed. With this processing, all the tasks become objects for scheduling again. Furthermore, in step E8, the value subtracting the sum of remaining running tick numbers of the task running state memo 212 from the reference cycle 211 (Refer to FIG. 10) is set in the internal counter register 205 for a running time alarm of the real time clock 201 (Refer to FIG. 9). As a result thereof, an interrupt for a running time alarm will be generated when there is no time left but for running only the task of which a cycle is insured.

Then in step E9, determination is made as to whether the interrupted state is a task in execution or not, and in a case where it is determined that the state is in a task in execution, an environment for execution of task is stored in TCB in step E10, and in step E11, the TCB stored in step E10 is connected to a TCB queue matrix, and furthermore in step E12, interrupt is allowed, and in step E13, system control jumps to the scheduler.

On the contrary, in step E9, if it is determined that the state is not a task in execution, system control returns to the interrupted processing in step E14. In this step, inhibition/permission of interrupt is returned to the state when interrupted.

In the description above concerning interrupt processing, no comment is given to the system based on the conventional technology in which an address for interrupt processing itself is registered in a list and multiplex interrupt (an interrupt during interrupt processing) is allowed, but even in that case, a processing for permitting a multiplex interrupt may be executed like that in the conventional technology. It should be noted that in that case overhead (wasting time required by the time a necessary processing is executed) is generated and it is required to set a rate for task running or other parameters to larger values.

FIG. 12 is a flow chart for explanation of a sequence for running time alarm interrupt processing. Step F1 indicates a header of interrupt processing executed when certain interrupt is generated, and at first generation of other interrupt is inhibited herein. Generally this processing is automatically executed by the main CPU 1. In step F2, running inhibited flags for all the task in which remaining running tick number of the task running state memo 212 (Refer to FIG. 10) is 0 or minus is turned ON.

In step F3, a queue matrix for task processing is reprepared so that the TCB in which all the running inhibited flags are OFF will be in front of the TCB in which all the running inhibited flags are turned ON. Namely the task in which a running inhibited flag is ON should run in front of the task in which the flag is OFF. In step F4, if an interrupted state is a task in execution, an environment for execution of the task is stored in the TCB, interrupt is permitted, and system control jumps to the scheduler. On the contrary, if an interrupted state is not a task in execution, system control returns to the interrupted processing.

FIG. 13 is a flow chart showing a sequence for general interrupt processing other than a reference cycle interrupt. Step G1 is a header step of interrupt processing in case where a certain interrupt is generated, and at first generation of other interrupt is inhibited. Generally this processing is automatically executed by the main CPU 1. In step G2, one ICB not used yet is acquired from the ICB pool (which is a site where ICBS not used yet are stored). In step G3, an environment for execution of this interrupt processing (itself) is stored in ICB. This operation includes storage of a header address for a processing in step G15 described later in the ICB as an address for command to be executed next.

In step G4, the ICB prepared herein is added to the ICB queue matrix to be executed by the scheduler. In step G5, inhibition of interrupt is canceled. After this step on, there is a possibility that interrupt is generated again. The processing described above is for making an interrupt inhibited period of time as short as possible.

In step G6, determination is made as to whether the interrupted processing is interrupt processing, or an operation by RTOS, or a task in execution. Step G7 is a processing executed in a case where the interrupted processing is interrupt processing or an operation by RTOS, and in this case system control directly returns to the interrupted processing. Step G8 is a processing executed in a case where the interrupted processing is for a task in execution, and in this case, at first the TCB for interrupted task is searched out. In step G9, an environment for execution of the interrupted task is stored in the TCB found out in step G8.

Step G10 is a processing for determining whether a task currently being executing is a task which is an object for insurance of a running rate or not. Concretely, determination is made as to whether the task has a value of 1 or more in the column of remaining running tick number in the task running state memo 212 (Refer to FIG. 10). Step G11 is a processing executed in a case where it has been determined that the task in execution was an object for insurance in step G10, and the value provided by the internal counter register 202 (Refer to FIG. 9) is subtracted from the value stored in the reference cycle 211 (Refer to FIG. 10). This result indicates a tick number indicating counts equivalent to a period of time in which the task continuously ran in this cycle. This number is subtracted from the column of remaining running tick number for the task in the task running state memo 211.

In step G12, the value subtracted in step G11 is added to the value of the internal counter register 205 for running time alarm of the real time clock 201 (Refer to FIG. 9). In proportion to a period of time in which the tasks insured for continuous run, a running time not insured for continuous run is increased.

In step G13, the prepared TCB is added to a TCB queue matrix executed by the scheduler. At this time, if the running inhibited flag for even one of the tasks is ON in the column of the task running state memo 212 (Refer to FIG. 10), in the TCB queue matrix the TCBs for the tasks for which the running inhibited flags are OFF is set before the TCB for the task for which running inhibited flags are ON.

In step G14, system control jumps to the scheduler. Step G15 indicates a processing in a case where system control returns from the scheduler, and this processing is not always executed right after system control has jumped to the scheduler, and it may be executed after other ICB has been processed, but system control will return to this step after all. From this step on original interrupt processing specific to each interrupt is executed, and contents of the processing varies according to a cause for interrupt. Step G16 is a processing for terminating interrupt processing, and in the processing an command for return to a normal subroutine is generally issued, and system control returns to the ICB processing section of the scheduler with this return command.

Next, a description is made for operations of the scheduler of RTOS with reference to FIG. 14. For simplicity, in the present embodiment, description is made hereinafter by assuming that an idle task which is the lowest in the priority and executes no processing toward outside is always running.

Step H1 is a processing for checking whether there is a queue matrix for interrupt processing (ICB) or not. Step H2 is a processing executed in a case where it is determined that there is a queue matrix for interrupt processing, and in the processing at first interrupt is inhibited to execute the queue matrix. This operation is executed because, if an interrupt is generated and it is tried to add the interrupt to the queue matrix for interrupt processing while a list of the queue matrix for interrupt processing is being processed, consistency of the list is lost.

In step H3, the header ICB is removed from the list of the queue matrix for interrupt processing. In step H4, inhibition of interrupt is canceled. In step H5, an environment for execution of interrupt processing such as an execution address and a register stored in step G3 (Refer to FIG. 13) is taken out from the ICB removed in step H3, and processing is executed therewith. This is the processing in step G15 (Refer to FIG. 13). Step H6 is a processing executed when system control returns from step G16 (Refer to FIG. 13), and in this step interrupt is inhibited again. In step H7, the ICB having been removed in step H3 is returned to the ICB pool. In step H8, interrupt inhibition is canceled and then system control returns to step H1. And then, as long as there is a queue matrix for interrupt processing, the processing sequence from step H1 to step H7 is repeated.

Step H9 is a processing executed in a case where there is not a queue matrix for interrupt processing in step H1, and in this case determination is made as to whether there is a queue matrix for TCB or not. Step H10 is a processing executed in a case where it is determined that there is a queue matrix for TCB in step H9, and in the processing, at first interrupt is inhibited in order to execute the queue. In step H11, in a case where the task for TCB is a task for which a running rate is insured, the value of the internal counter register 202 (Refer to FIG. 9) for running time measurement of the real time clock 201 (Refer to FIG. 9) is stored in the task start tick memo 210 (Refer to FIG. 10).

In step H12, interrupt inhibition is canceled. In step H13, an environment for execution of the task stored in step G9 (Refer to FIG. 13) is taken out from the TCB removed from the queue matrix (a list) for a task processing in step H11, and the processing is executed therewith.

As described above, the control software execution system A2 for an NC unit according to Embodiment 2 is a system in which a function of executing a control for giving insurance of a task running time is added to the RTOS having only a normal scheduling system based on a priority, and executes control software for an NC unit according to the system. With Embodiment 2, the control software execution system A2 for an NC unit can execute a control according to a running time for task for realizing functions of an NC unit. For this reason, waste of time allocated to each task can be reduced. Furthermore, a task can be controlled according to the running time, and because of this feature system construction becomes easier.

Next, a description is made for configuration of Embodiment 3. The contents in FIG. 15 showing general configuration of the control software execution system A3 for an NC unit is substantially the same as those in FIG. 9 relating to Embodiment 2. It should be noted that in Embodiment 3, a counter register 206 is provided inside of the real time clock 201 like the counter register 202. In Embodiment 3, this counter register 206 is used for continuous run terminate interrupt.

Next, a description is made for operation in Embodiment 3. FIG. 16 and FIG. 17 each show data structure each required for insuring continuous run of a task, and FIG. 16 shows structure of a list for a "task end tick number".The reference numeral 220 indicates "a task end tick block". Components of the task end block include "a link (a pointer)" for linking a task end block, "a task name", and "an end tick number". Like in the description above, it is assumed also in the description of the present embodiment that internally time control is executed according to a number of ticks.

FIG. 17 shows the contents of "a task continuous run insurance table" 221. There are columns for "a name of task", "continuous run insurance tick number", and "in-execution flag", and a value of a continuous run insurance tick number is set when system control starts, or by SVC. A value in column is set to 0 to a task which does not require a continuous run. A column for the in-execution flag is turned ON when a task insured for its continuous run is currently running, and OFF in other cases, and two or more of this flags are never turned ON simultaneously. This table is not required if specified as a parameter in the SVC for a task start, but for convenience in the description hereinafter, it is assumed that this table is used in the present embodiment.

The scheduler in the RTOS insures a continuous run for a task by not executing re-scheduling after end of interrupt processing even if an interrupt is generated when a task, a continuous run of which is insured, is running. Execution of a task, a continuous run of which is insured, is terminated only when "continuous run end interrupt" has been generated.

The RTOS determines at first, when the SVC for a task start has been issued, whether the task is a task, a continuous run of which is insured or not, and if it is determined that the task is the one, a continuous run of which is insured, a continuous run tick number is set from the task continuous run insurance table (Refer to FIG. 17) in the internal counter register 206 of the real time clock 201 (Refer to FIG. 15). When a period of time equivalent to the set clock number has passed, "a continuous run end interrupt" will be generated. Firstly, description is made for interrupt processing. FIG. 18 is a flow chart showing a processing sequence for a continuous run interrupt. Step I1 is a header step of the interrupt processing in a case where a certain interrupt is generated, and at first generation of other interrupt is inhibited. Generally, this processing is automatically executed by the main CPU 1. Step I2 is a processing for searching out a TCB for a task currently running, a continuous run of which is insured, and an environment for execution of the current task is stored in the TCB found out.

Then in step I3, the in-execution flag (Refer to FIG. 17) for the task is turned OFF. Step I4 is a processing for repreparing a queue matrix for a task processing according to dispatching priority. Furthermore, step I5 is a processing in which, if the interrupted processing is a task in execution, an environment for execution of a task is stored in a TCB, and system control jumps to the scheduler, and if it not, system control returns to the interrupted processing. In this step, an interrupt is permitted, as soon as system control has returned.

Next, a description is made for a processing sequence for general interrupt with reference to FIG. 19. Step J1 is a header step of interrupt processing in a case where a certain interrupt is generated, and at first generation of other interrupt is inhibited. Generally this processing is automatically executed by the main CPU 1. In step J2, one ICB not used yet is acquired from the ICB pool (a site where ICBs not used yet are stored). In step J3, an environment for execution of this interrupt processing (for itself) is stored in the ICB. This operation also includes storage of the header address of the processing in step J13 as an address for an command to be executed next time.

In step J4, the prepared ICB is added to an ICB queue matrix to be executed by the scheduler. In step J5, inhibition of an interrupt in step J1 is canceled. After this step and on, there is a possibility that an interrupt may be generated again. The processing described above is for making an interrupt inhibited time as shorter as possible. In step J6, determination is made as to whether the interrupted processing is interrupt processing or an operation by the RTOS, or a task in execution.

Step J7 is a processing executed when the interrupted processing is interrupt processing or an operation by the RTOS, and in this case system control returns directly to the interrupted processing. On the contrary, step J8 is a processing executed when the interrupted processing is a task in execution, and in this case, at first, a TCB for the interrupted task is searched out. Step J9 is a processing for determining whether the task currently being executed is a task as an object for insurance of a continuous run or not. More particularly, determination is made as to whether the interrupted task is a task with a value of 1 or more in the column for continuous run insurance tick number in the task continuous run insurance table (Refer to FIG. 17) or not. In a case where it is determined that the task is an object task insured for its continuous run, nothing is executed in steps J10 and J11, and system control shifts to step J12.

Step J10 is a processing in a case where it is determined that the task is not an object insured for its continuous run, and an environment for execution of the interrupted task is stored in the TCB found out in step J8. In step J11, a TCB queue matrix (Refer to FIG. 5) is re-prepared according to the dispatching priority. In step J12, system control jumps to the scheduler. Step J13 is a processing to which system control returns from the scheduler. This processing is not always executed right after system control has jumped to the scheduler, and in some cases this processing might be executed after other ICB has processed, but in any case system control returns to this step. From this step on it is an original interrupt processing executed specifically to each interrupt, and the contents of processing varies according to a cause for each interrupt. Step J14 is a step for terminating interrupt processing, and in this step generally an command for return to an ordinary subroutine is issued. With this command, system control returns to an ICB processing section for scheduler.

As described above, the control software execution system A3 of an NC unit according to Embodiment 3 is based on a system in which a function capable of executing a control for giving insurance of a continuous running time to a task is added to a RTOS having only a scheduling system based on general dispatching priority, and control software for the NC unit is executed based on this system.

With Embodiment 3, the control software execution system A3 for an NC unit enables insurance of a continuous running time for tasks each realizing a function of the NC unit respectively. For this reason, waste of time allocated to each task can be reduced. Furthermore, a task can be controlled according to the running time, and because of this feature system construction becomes easier.

Next, a description is made for configuration of Embodiment 4. Contents of FIG. 20 showing general configuration of a control software execution system A4 for an NC unit according to Embodiment 4 is substantially the same as contents of FIG. 1 relating to Embodiment 1. It should be noted that in Embodiment 1, an interrupt port of the real time clock 201 is used by only one channel, while in the present embodiment, it is different from that in Embodiment 1, four channels are used for it. Description is made hereinafter for the present embodiment with reference to FIG. 2 to FIG. 4 and FIG. 10.

Namely, the reference numeral 202 indicates a counter register provided inside of the real time clock 201, and this counter register decrements the value by 1 each time a clock signal is inputted from outside. When the value is decremented to 0, operation will be kept stopped until the default value is set again, or a value is set again from the main CPU 1. Selection of this operation, and setting or changing the default value can be executed freely from the main CPU 1.

The reference numerals 204, 205, and 206 indicate counter registers each provided inside of the real time clock 201. These registers decrement the value by 1 each time a clock signal is inputted from outside. When the value is decremented to 0, the default value is set again. Also the default value can be set freely from the main CPU 1. The counter registers 202, 204, 205, and 206 can be set or canceled independently from each other. In the present embodiment, the counter registers 202 to 206 are used each for measurement of a task running time, reference time interrupt, running time alarm, and task running interrupt respectively.

Next description is made for operations of the control software execution system A4 of the NC unit. An execution cycle for each task is registered by the SVC when the task is preset or started like in Embodiment 1.

This data is registered in, for instance, "the task running cycle table" 50 as shown in FIG. 2 by the RTOS. FIG. 2 shows data structure having columns for "a running cycle" and "times of repetition" for each task. The running cycle is a value of a clock number indicating a period of time until the task runs next time, while times of repetition indicates how many times the task will be started. For instance, if this value is a minus one, it is assumed that the value is infinite. In that case the task is started repeatedly. The RTOS prepares "the task running queue list" 51 as shown in FIG. 3 each time the task is started by using this task running cycle table 50.

In FIG. 3, each running queue block 52 in the list is a block comprising "a task name", "a running schedule clock number" indicating how long a time should pass from the current point of time before execution of the task is started, and "simultaneous task name" indicating names for tasks to be run simultaneously. The method for the RTOS to prepare a task running queue list is the same as that shown in FIG. 4 relating to Embodiment 1, so that description thereof is omitted herein.

Also as described in Embodiment 2, FIG. 10 shows data configuration required for insurance of a running rate for a task, and the reference numeral 210 indicates a "task start tick memo". The value of the internal counter register 202 (Refer to FIG. 20) of the real time clock 201 (Refer to FIG. 20) is recorded right before the RTOS starts execution of a task. Then a period of time the task has run is computed by obtaining a difference between the recorded value and the value of the internal counter register 202 (Refer to FIG. 20) when system control returns to the RTOS after execution of the task has been finished.

The columns for "a reference cycle" 211, "a task running state memo" 212, "a remaining running tick number", and columns of "a number of times of repetition" and "a running inhibited flag" each shown in FIG. 10 are the same as those in Embodiment 2, so that description thereof is omitted herein.

A running schedule clock number for a header block of a running queue list in steps B4 and B16 shown in FIG. 4 is stored in the counter register 202 (Refer to FIG. 20) of the real time clock 201 (Refer to FIG. 20), and after a period of time equivalent to the specified clock number has passed, "a task start interrupt" is generated. This processing for task start interrupt is the same as that described according to FIG. 7 in Embodiment 1, so that description thereof is omitted herein.

The control software execution system A4 shown in FIG. 20 presets a value for the reference cycle 211 (Refer to FIG. 10) in the counter register 204 provided inside of the programmable interval timer 201, for instance, when the system has been actuated before a task for which a running rate is insured is started. After a period of time equivalent to this preset tick number has passed, a reference cycle interrupt is generated.

A processing sequence for the reference cycle interrupt is the same as that described with reference to FIG. 11 relating to Embodiment 2, so that description thereof is omitted herein. Also a processing sequence for the running time alarm interrupt is also the same as that described with reference to FIG. 12 relating to Embodiment 2, so that description thereof is omitted herein. A processing sequence for the general interrupt other than the reference cycle interrupt is also the same as that described with reference to FIG. 13 relating to Embodiment 2, so that description thereof is omitted herein. Furthermore an operation of the scheduler for the RTOS is also the same as the sequence described with reference to FIG. 14 relating to Embodiment 2, so that description thereof is omitted herein.

Herein description is made for a task start interrupt, a reference time interrupt, a running time alarm interrupt, and a general interrupt centering on operations to the TCB queue matrix.

The task start interrupt is a processing for inserting the TCB for a task started by this interrupt to the header of the TCB queue matrix. Also the reference time interrupt enables run of all the tasks. The running time alarm interrupt is a processing for reporting to a general interrupt the fact that a running time alarm interrupt has been generated by setting the TCB for a task, a rate of running time of which is insured, in front of the TCB for task not insured for continuous run and at the same time by turning ON a running inhibited flag in the task running state memo 212 (Refer to FIG. 10). Furthermore in a general interrupt, the TCBs for tasks insured for a running time are linked to those for tasks, a running time for which is not insured, until a reference time interrupt is generated in a case where a running time alarm interrupt has been generated by the processing for running time alarm interrupt.

Herein, either one of the dispatching priority selection schemes according to a task start interrupt or to a general interrupt is previously specified. If a scheme according to a task start interrupt is selected, a time to start a task becomes more accurate, but a running rate for a task becomes somewhat inaccurate. On the contrary, if a scheme according to a general interrupt is selected, a running rate for a task becomes more accurate, but a time for starting the task becomes somewhat inaccurate. For selecting either one of the schemes, a threshold value may be specified by any means. For instance, a scheme is advisable in which priority is put on a running rate so long as a delay of a time to start a task is not more than a prespecified period of time, but the priority is put on start of a task when the delay exceeds the prespecified period of time.

As described above, the control software execution system A4 for the NC unit according to Embodiment 4 is based on a system in which a function capable of providing controls for a task start cycle as well as for insurance of a running rate of a task is added to the RTOS having only a scheduling system based on normal dispatching priority, and executes control software for an NC unit according to this system.

With Embodiment 4, the control software execution system A4 for the NC unit can provide controls for accurate starting time and a running time for tasks each realizing a function of the NC unit respectively. For this reason, waste of time allocated to each task can be reduced, and furthermore execution of a task can be controlled according to the running time, and because of this feature system construction becomes easier.

Next, a description is made for Embodiment 5. The general configuration of a control software execution system A5 for an NC unit according to Embodiment 5 is the same as that shown in Embodiment 1, so that description thereof is omitted herein.

Next, a description is made for operations of the control software execution system A5 for an NC unit according to Embodiment 5. Like in Embodiment 1, an execution cycle for each task is registered by the SVC previously or when the task is started.

The data is registered by the RTOS in, for instance, the "task running cycle table" 50 as shown in FIG. 2. "A running cycle" and "times of repetition" in this task running cycle table 50 are the same as those in Embodiment 1, so that description thereof is omitted herein.

In FIG. 3, each running queue block in the list is a block each comprising "a task name", "a running schedule clock number" indicating how long a time should pass from the current point of time on before execution of the task is started, and "a simultaneous task name" indicating names of tasks to be run simultaneously. The method in which the RTOS prepares this task queue list is the same as that shown in FIG. 4 in Embodiment 1, so that description thereof is omitted herein.

Also as Embodiment 3, FIG. 16 and FIG. 17 show data structure required for insurance of a running rate of continuous run for a task, and FIG. 16 shows structure of the list of "a task end tick number". The reference numeral 220 indicates "a task end tick block". Components of the task end block are a pointer for linking the task end blocks to each other, "a task name", and "an end tick number" or the like. As in the description above, it is assumed in the description of the present embodiment that internally time control is executed always according to a number of ticks. The column of "inexecution flag" is turned ON when a task, currently continuous run of which is insured, is running, and OFF in other cases. Two or more of this flags are never turned ON simultaneously.

FIG. 17 shows a "task continuous run insurance table" 221. This table has columns for a "task name" and a "task continuous run insurance tick number", and the value of a continuous run tick number is set when system control starts or by the SVC. A value in this column is set to 0 for a task with a continuous run not specified. Although this table is not required if it is specified as a parameter thereof in the SVC for task start, for convenience in description hereinafter, it is assumed that this table is used.

The scheduler in the RTOS insures a continuous run for a task by not executing re-scheduling after interrupt handing has finished even if an interrupt is generated while a task, a continuous run of which is insured, is running. An execution of the task, a continuous run of which is insured, is terminated only when a "continuous run end interrupt" is generated.

When the SVC for a task start is issued, the RTOS at first determines whether the task is one, a continuous run of which is insured, or not, and if it is determined that the task is the one insured for a continuous run, a continuous run tick number is set in the counter register inside of the real time clock 201 (Refer to FIG. 1) from the task continuous run insurance table 221 (Refer to FIG. 17). After a period of time equivalent to the set clock number has passed, a "continuous run end interrupt" is generated.

A processing sequence for a continuous run end interrupt is the same as the contents in FIG. 18 relating to Embodiment 3, so that description thereof is omitted herein. A processing sequence for the general interrupt other than the reference cycle interrupt is also the same as that described with reference to FIG. 19 relating to Embodiment 3, so that description thereof is omitted herein. As for the scheduler, it is also the same as a conventional type thereof, so that description thereof is omitted herein.

Herein, description is made for a continuous run end interrupt and a general interrupt centering on operations to the TCB queue matrix, namely the following three points:

1) When a task start interrupt is generated, the TCB for a task started by this interrupt is inserted to the header of the TCB queue matrix.

2) When a continuous run end interrupt is generated, the inexecution flag of the in-execution task is turned OFF, and other task is allowed to run.

3) When a general interrupt is generated, a dispatch of the TCB queue matrix is not executed for a task for which a continuous run is insured.

Herein either one of dispatching priority schemes 1) and 3) described above is previously selected. If the scheme 1) is selected, a time to start a task becomes more accurate, but a continuous running time for a task becomes somewhat inaccurate. On the other hand, if the scheme 3) is selected, a continuous running time for a task becomes more accurate, but a time to start a task becomes somewhat inaccurate. For selecting either one of the schemes, a threshold value may be decided by any means. For instance, a scheme is advisable in which priority is put on continuous run so long as a delay of a time to start a task is not more than a prespecified period of time, but the priority is put on start of a task when the delay exceeds the prespecified period of time.

As described above, the control software execution system A5 for the NC unit according to Embodiment 5 is based on a system in which a function capable of providing controls for a task start cycle as well as for insurance of continuous run of a task is added to the RTOS having only a scheduling system based on general dispatching priority, and executes control software for an NC unit according to this system.

With Embodiment 5, the control software execution system A5 for the NC unit can provide controls for accurate starting time as well as a time for continuous run of tasks each realizing a function for an NC unit respectively. For this reason, waste of time allocated to each task can be reduced, and furthermore execution of a task can be controlled according to the running time, and because of this feature system construction becomes easier.

Next, a description is made for Embodiment 6 of the present invention. FIG. 21 shows general configuration of an control software execution system A6 for an NC unit according to Embodiment 6, and the contents is substantially the same as Embodiment 1. It should be noted that, although in Embodiment 1 only one channel of an interrupt port for the real time clock 201, two channels are used in this embodiment.

In this figure, the reference numerals 202, 204 each indicates a counter register inside of the real time clock 201. The counter registers 202, 204 are set and released each independently. In this embodiment, the counter registers 202, 204 are used for measurement of task running time respectively.

Next, a description is made for operations of the control software execution system A6 for an NC unit. In an RTOS for the control software execution system A6 according to the present embodiment, previously, or for instance when operation of the system is started, the internal counter registers 202, 204 in the real time clock 201 are set so that default values are set again when the count is decremented to zero (0), and also an interrupt will not be generated even when the count is decremented to zero (0).

Also immediately before a task is started, the counter value is read and stored. Also immediately after operation for the task is finished, the counter value is again read, and a difference between the value and the value having been stored is obtained. The value indicates a clock number indicating a running time of the task. Then a site for storing a sum of the values is prepared for each task, and a sum of a running time of each task is recorded by adding a count read each time to the sum stored at the site.

Next, further detailed description is made for operations of the control software execution system A6 for an NC unit according to the present embodiment. FIG. 22 shows data structure required for recording a running time of each task, and the reference numeral 230 indicates a counter value memo, while the reference numeral 231 indicates a task running time table, and this table has a column for a total tick number for each task as shown in the figure. FIG. 23 shows a flow chart showing a processing sequence in general interrupt processing, and FIG. 24 is a view showing a sequence of processing by a scheduler.

FIG. 23 is a flow chart showing a processing sequence in general interrupt processing, and step K1 is an operation executed first in interrupt processing when an interrupt is generated, and with this operation generation of other interrupt is inhibited. Generally this processing is automatically executed by the main CPU 1. In step K2, one ICB not used yet is acquired from the ICB pool (which is a site where ICBs not used yet are stored). In step K3, an environment for execution of this interrupt processing (itself) is stored in the ICB. This operation includes also storage of a header address for a processing in step K8 as an address for an command to be executed next. In step K4, the ICB prepared herein is added to an ICB queue matrix to be executed by the scheduler. In step K5, inhibition of interrupt by step K1 is canceled. From this step and on, there is a possibility that an interrupt is generated again. The processing described above is for making a time of interrupt inhibition as short as possible.

In step K6, determination is made as to whether the interrupted processing is interrupt processing or RTOS, or execution of a task. The step K7 is an operation executed when it is determined that the interrupted processing is interrupt processing or execution of an RTOS, and system control directly returns to the interrupted processing. Step K8 is a processing executed when it is determined that the interrupted processing is execution of a task, and a TCB for the interrupted task is searched out. In step K9, an environment for execution of the interrupted task is stored in the TCB found out in step K8.

Step K10 is a processing for reading a value of the internal counter register 204 in the real time clock 201 (Refer to FIG. 21) and subtracting the value from a value provided in the counter value memo 230 (Refer to 22). The result is a number of ticks indicating a period in which the task continuously ran in the cycle. In step K11, the value obtained in step K10 is added to a column for the total tick number for the task in the task running time table 231 (Refer to FIG. 22). In step K12, the prepared TCB is added to an order of priority in the TCB queue matrix to be executed by the scheduler. Step K14 is a processing executed after having returned from the scheduler. This processing is not always executed right after jumping to the scheduler, and in some cases this processing is executed after other ICB is processed, but in any case system control returns to this step. The sequence from this step on is an original interrupt processing specific to each interrupt, and contents of the processing varies according to a case for interrupt. Step K15 is a processing to terminate interrupt processing, and generally an command for return to the ordinary subroutine is issued, and system control returns to the scheduler's ICB processing section according to this return command.

FIG. 24 shows operations of the RTOS according to this embodiment. For convenience in description, it is assumed that an idle task having the lowest priority and executing nothing to external devices is always running in this embodiment.

Step L1 is a processing to determine whether there is any queue matrix for interrupt processing or not. Step L2 is a processing executed when it is determined that there is a queue matrix for interrupt processing, and at first interrupt is inhibited to execute the queue matrix. This is because, if an interrupt is generated during a processing of list of queue matrix for interrupt processing and it is tried to add the interrupt to the queue for interrupt processing, consistency of the list is lost.

Step L3 is a processing for removing a header ICB from a list of queue matrix for interrupt processing. In step L4 inhibition of interrupt is canceled. In step L5, an environment for execution of interrupt processing such as an execution address or a register stored in step K3 (Refer to FIG. 23) is taken out from the ICB removed in step L3 and the required processing is executed. This is a processing executed in step K14 (Refer to FIG. 23). Step L6 is a step to which system control returns from step K15 (Refer to FIG. 23), and interrupt is inhibited again. In step L7, the ICB removed in step L3 is returned to the ICB pool. In step L8, inhibition of interrupt is canceled, and then system control returns to step L1. Then, as long as there is a queue matrix for interrupt processing, the processing sequence from step L1 to step L7 is repeated.

Step L9 is a step for determining whether there is a queue matrix for TCB, and step L10 is a processing executed when it is determined that there is a queue for interrupt processing, and at first interrupt is inhibited to execute the queue matrix. Step L11 is a processing for removing a header TCB from a list of queues matrix for interrupt processing. In step L12, a value provided by the internal counter register 204 (FIG. 22) for measuring a running time in the real time clock 201 (Refer to FIG. 21) is stored in the counter value memo 230 (Refer to FIG. 22).

In step L13, inhibition of interrupt is canceled. In step L14, an environment for execution of the task stored in step K9 (Refer to FIG. 23) is taken out from the TCB removed from the queue matrix (list) for task processing in step L11 and the task is executed. In this case, system control jumps to the processing, and never returns to this step. Step L15 is a processing executed when it is determined in step L9 that there is no TCB queue matrix, and interrupt is waited for.

As described above, by checking the task running time table 231 (Refer to FIG. 22) after having this system executed for a required period of time, it is possible to confirm a period of time when each task actually ran (for executing a processing in each task).

It should be noted that, if a column for a number of times for task running is provided, in addition to that for task running time, in the task running time table 231 (Refer to FIG. 22) to record a number of times of task running, it is useful when deciding a running cycle, a running rate, and running time for a task described below.

Furthermore, by providing, in addition to the counter value memo 230 (Refer to FIG. 22), a task end counter value memo, and by storing a value of the internal counter register 204 (Refer to FIG. 21) in the real time clock 201 (Refer to FIG. 21) in the beginning of interrupt processing and using a value obtained by subtracting a value in the task end counter value memo from a value in the counter value memo 230 as a number of ticks indicating a period of time when the task run continuously, it is possible to obtain a true time when the task ran excluding the time for interrupt processing.

As described above, the control software execution system A6 for an NC unit according to Embodiment 6 is based on a system with a function to check an actual running time of a task, and control software for an NC unit is executed according to this system.

With Embodiment 6, the control software execution system A6 for an NC unit can easily execute such operations as running time allocation to each task by checking an accurate time required for execution of each task realizing functions of the NC unit, and because of this feature system construction becomes easy.

Next, a description is made for Embodiment 7 of the present invention. General configuration of the control software execution system A7 for an NC unit according to Embodiment 7 is the same as that in Embodiment 6, so that description thereof is omitted herein.

Next, a description is made for operations of the control software execution system A7 according to the present invention. The RTOS in the control software execution system A7 according to the present embodiment is set so that, if a value of internal counter register in the real time clock 201 is decremented to zero (0), previously or for instance, when service operation of the system is started, the default value is set again, and an interrupt will not be generated even if a value of the internal counter register is decremented to zero (0).

Also immediately before execution of a task is started, the counter value is read and stored, and immediately after execution of the task is finished, the counter value is read again, and a difference between the value and the value having been stored is computed. The value is a clock number indicating a period of time when the task ran last. A site for storing therein a sum of the values is prepared for each task, and by accumulating the values at the site, a total of running time of each task is recorded. Furthermore an ICB processing executed by a scheduler in the conventional technology is executed not by a scheduler, but by a task having the highest priority.

Next, further detailed description is made for operations in execution of the control software for an NC unit according to the present Embodiment. FIG. 25 is a flow chart showing a sequence of processing by the scheduler, and FIG. 26 is a flow chart showing a processing sequence of a task for interrupt processing having the highest dispatching priority. As data structure, the same ICB (Interrupt control block) as that in the conventional technology is used. The interrupt processing in this embodiment is the same as that in the previous embodiments, so that description thereof is omitted herein.

FIG. 25 shows operations of a scheduler in the RTOS according to the present embodiment, and it is assumed in description of the present embodiment that an idle task is provided and the idle task is always queuing for execution. Step M1 is a processing executed when there is a queue matrix for task processing (TCB), and to execute the queue matrix, at first an interrupt is inhibited. In step M2, a header TCB is removed from a list of queues matrix for interrupt processing. In step M3, a value of the internal counter register 204 (Refer to FIG. 21) for measurement of a running time in the real time clock 201 (Refer to FIG. 21) is stored in the counter value memo 230 (Refer to FIG. 22).

In step M4, inhibition of an interrupt is canceled. In step M5, an environment for execution of a task stored during interrupt processing is taken out from the TCB removed from the queue matrix (list) for task processing in step M3, and the task is executed. In this step, system control jumps to the processing, and does not return to this step.

FIG. 26 shows operations in a task for executing interrupt processing according to the present embodiment. Step N1 is a processing for determining whether there is a queue matrix for interrupt processing or not. Step N2 is a processing executed when it is determined that there is a queue matrix for interrupt processing, and to execute matrix the queue, at first an interrupt is inhibited. This operation is executed because, if an interrupt is generated and it is tried to add the interrupt to the queue while the list of the queue matrix for interrupt processing is being processed, consistency of the list is lost.

Step N3 is a processing for acquiring a header ICB from a list of queue matrix for interrupt processing. In step N4, inhibition of an interrupt is canceled. In step N5, an environment for execution of interrupt processing such as an execution address or a register stored during interrupt processing is taken out from the ICB removed in step N3, and the processing is executed. Step N6 is a processing for returning the ICB removed in step N3 to the ICB pool. Then system control returns to step N1, and a sequence from N1 to N6 is repeated while there is a queue matrix for interrupt processing. Step N7 is a processing executed when there is no queue matrix for interrupt processing (ICB), and in this case an SVC for terminating a task is issued, and a right to use the main CPU 1 is delivered to other task.

As described above, after the control software execution system according to the present embodiment is run for a necessary period of time, by checking the task running time table 231 (Refer to FIG. 22), it is possible to know the period of time in which each task actually ran (the processing was executed).

Furthermore by executing interrupt processing at a level of task processing, a running time of a task for execution of interrupt processing can be regarded as a time for interrupt processing, also a time required for interrupt processing can be measured. Also by designing the system so that a running time for each cause for an interrupt can be recorded within a task for execution of interrupt processing, a time required for processing according to each cause for interrupt can be measured.

As described above, the control software execution system A7 for an NC unit according to the Embodiment 7 is a system in which a function to know an actual running time for execution of a task as well as for a time required for interrupt processing is added, and executes control software for an NC unit according to the system.

With Embodiment 7, the control software execution system A7 for an NC unit can easily execute such a processing as allocation of a running time to each task by knowing an accurate period of time required for execution of a task realizing a function of the NC unit as well as a time required for interrupt processing, and for this reason system construction becomes easier.

Next, a description is made for Embodiment 8. In an NC unit having a means for measuring a running time for a task or interrupt processing, and furthermore having a means for changing a running time for a task, there are a plurality types of general configuration for a control software execution system A8 for an NC unit realizing the functions described above according to a way to specify a running time or running rate for a task. However, in this embodiment, for convenience in description, description is made for a case where a running rate for a task can be specified.

General configuration of the control software execution system A8 for an NC unit according to Embodiment 8 is substantially the same as that in Embodiment 2 (Refer to FIG. 9), so that description thereof is omitted herein. A processing for insuring a running rate for a task is substantially the same as that in Embodiment 2 (FIG. 11 to FIG. 12), and the required data structure is also the same as that therein, and the system comprises a task start tick memo 210 (Refer to FIG. 10), a region 211 for storing a reference cycle (Refer to FIG. 10), and a task running state memo 212 (Refer to FIG. 10). The task running state memo 212 (Refer to FIG. 10) has columns for a remaining running tick number, times of repetition, and a running inhibited flag.

Furthermore, to measure a running time for a task, a task running time table 231 (Refer to FIG. 22) is provided in the system like that in Embodiment 6. Also the task running time table 231 (Refer to FIG. 22) has a column for a total tick number for each task. It should be noted that a counter value memo 230 (Refer to FIG. 22) is not used herein because it plays the same role as the task running state memo 212 (Refer to FIG. 10). Also a sequence of reference time interrupt processing and a sequence of running time alarm interrupt processing are the same as those in Embodiment 2 (Refer to FIG. 11 and FIG. 12), so that description thereof is omitted herein.

FIG. 27 shows a flow chart for explanation of a processing sequence in general interrupt processing, and step O1 is an operation executed first in interrupt processing when an interrupt is generated, and in this operation generation of other interrupt is inhibited. Generally this processing is automatically executed by the main CPU 1. In step O2, one ICB not used yet is acquired from the ICB pool (a site for storing therein ICBs not used yet).

In step O3, an environment for execution of this interrupt processing (itself) is stored in the ICB. This operation includes also a storage of a header address for a processing in step O8 as an address for an command to be executed next. In step O4, the ICB prepared herein is added to an ICB queue matrix to be executed by the scheduler. In step O5, inhibition of interrupt by step O1 is canceled. From this step and on, there is a possibility that an interrupt is generated again. The processing described above is for making a time of interrupt inhibition as short as possible.

In step O6, determination is made as to whether the interrupted processing is interrupt processing or RTOS, or a task in execution. Step O7 is a processing executed in a case where it is determined that the interrupted processing is interrupt processing or an operation of the RTOS, and system control directly returns to the interrupted processing. Step O8 is a processing executed in a case where it is determined that the interrupted processing is a task in execution, and at first a TCB for the interrupted task is searched out. In step O9, an environment for execution of the interrupted task is stored in the TCB searched out in step O8.

Step O10 is a processing for subtracting a value of the internal counter register 202 (Refer to FIG. 9) from a value stored in the reference cycle 211 (Refer to FIG. 9). The result is a number of ticks indicating a period in which the task continuously ran. The value is added to a column for a total tick number for the task in the task running time table 231 (Refer to FIG. 22). Step O11 is a processing for determining whether the task currently in execution is a task as an object, a running rate of which is insured, or not. More particularly, determination is made as to whether the task is a task having one or more columns for a remaining running tick number in the task running state memo 212 (Refer to FIG. 9) or not.

Step O12 is a processing executed in a case where it is determined that a task is a task as the object of a processing in step O11, and the value obtained in step O10 is subtracted from a value of the column for remaining running tick number for the task in the task running state memo 211. In step O13, the value obtained in step O10 is added to a value provided in the internal counter register 205 for the running time alarm in the real time clock 201 (Refer to FIG. 9). Time for running tasks other than those insured for a running cycle increases in proportion to a period of time in which tasks insured for a running cycle ran.

In step O14, the prepared TCB is added to the TCB queues matrix to be executed by the scheduler according to an order of the d