The present invention relates to a control system for an industrial robot, wherein the control system comprises a memory unit intended to comprise at least one robot program intended for controlling the movements of the robot, comprising movement instructions for controlling the movements of the robot, and a program executer designed to generate instructions based on movement instructions included in the program as well as data necessary to be able to carry out said instructions, to a path planner configured to receive said instructions from the program executer and hence to plan how the movements of the robot are to be designed in order to be able to carry out said movement instructions.
Today, off-line simulation is used when designing industrial robots, robot cells and the task programs of the robots, based on the performance requirements imposed by the user, for example the loads that the robots shall manage to carry, the work the robots are to carry out, or the number of executed work cycles per defined period of time. However, sometimes the users subject the robots to higher loads than what was originally intended, which, for example, may be due to the fact that the robot tool is heavier than what was originally intended or that the objects to be processed are heavier than what was intended. Another reason for robots being overloaded is that they are forced to carry out more work cycles per unit of time, for example per hour, than what was originally intended. The problems that arise when robots are subjected too frequently to overloads are, among other things, that the parts of the robots are worn more rapidly than what was expected, with an insufficient production result as an immediate consequence. Further, this implies that the service life of the robots is reduced, that the production stoppages increase, and that the service intervals are closer.
If a user today wants to know if it is possible to increase, for example, the load or the number of work cycles without this having a negative influence on a robot, it is currently not possible to get an answer to this without first checking the task program to see what loads can be used and then carrying out a plurality of time-consuming off-line simulations, which often have to be carried out by consistently counting on values that imply that the risk of faults occurring on the robot or on the work carried out is greatest, which still in many cases does not provide a sufficient amount of data to give an answer that is completely correct or completely solves the problem arisen. This is due to the fact that, when carrying out simulation, there are no data whatsoever as to how the robot has performed during previous work cycles, while at the same time there are no data showing how much the robot has been in operation compared to its downtime.
Another question often put by the user to the manufacturer is, for example, why a robot has failed completely or partly, does not operate satisfactorily, or does not perform the work conceived as planned. Also in this case, the program must be checked to see what how the robot was supposed to have operated, after which time-consuming simulations, according to what has been described above, have to be carried out. Also these simulations fail to provide a satisfactory answer or solution as to why the problems have arisen, for the same reason as previously described.
Another frequent problem arises when a user wishes to know when service is to be scheduled to allow him to carry out this service before the robot is damaged in some way, in order thus to suffer the least possible loss of production. Today, this can only be estimated with the aid of time-consuming simulations which do not provide sufficiently precise answers to the above-mentioned question. To obtain good safety margins, the service to the robot is currently scheduled to take place much earlier than what is really necessary, which, spread over the entire life of the robot, means that it is stopped unnecessarily many times for service.
One disadvantage of known simulation methods is that it can only be roughly estimated how often a certain part of the program is run. In addition, with known simulation methods it is not possible to see how the robot is influenced by the number of work cycles carried out, which makes it difficult to predict when the robot will break down.
Another known problem-solution method is to read and save the control signals that control the motors of the robots since these signals are generated based on the phase-angle values measured on the respective shafts of the robot by sensors provided thereon. Depending on the quantity of the phase angle, the output motor torque for the respective motor is controlled. The problem with this, besides being time-consuming work just as the previous problem solutions, is that it only answers the question what has happened to the robot but does not give the reason for the problems. The reasons for the problems may, for example, be:
Solving these problems, however, is not possible without first working out proposals for changes, such as reconfiguration of the robot or the robot program, and then verifying these proposals for changes on the robot.
Today, it is also necessary to be physically present around the robot in order to carry out different measurements for the purpose of gathering measurement data in order later on to carry out simulations with the object of trying to see what could possibly have caused the problems. This is both expensive and time-consuming and also causes stoppages in production.
The object of the present invention is to provide a control system for at least an industrial robot which increases the possibilities of identifying any sources of error and which increases the possibilities of providing an answer as to whether the robot for a certain specified application is capable of running heavier loads than what the robot was originally specified for, or when it is suitable to plan production stoppages into the schedule for service of the robot.
This object is achieved with the initially indicated control system which is characterized in that the control system includes a recording device designed for the purpose of recording and storing the instructions sent to the path planner from the program executer as well as data necessary to carry out the instructions to the path planner.
Data necessary for the path planner to carry out the instructions are, for example, values of variables and parameters referred to in the instructions. Examples of data are variable values such as the position of the next point to which the robot is to move, at what speed the robot is to move, and what load the robot is to carry.
When later on it is desirable to carry out an analysis, for example as to:
Further, this solution results in a number of additional advantages, such as:
According to an advantageous embodiment of the invention, the recording device is configured to record and store time indications showing the actual instant in time when the instructions and said data were sent from the program executer to the path planner. By this embodiment, the exact time when an instruction was carried out is given, which is not possible by only by looking at the task program which contains a large number of commands implying that the robot is maintained in a position of rest.
According to another embodiment of the invention, a communication link is arranged for the purpose of transferring the instructions recorded and stored by the recording device as well as said data to an external data-processing unit. Further, the transfer of the instructions and said data to the external data-processing unit advantageously takes place in real time. Said communication link may be a signal cable, but also a modem may be used to transfer said read-off instructions and said read-off data to an external data-processing unit via, for example, internal computer networks or via the Internet. By these embodiments, read-off data are readily available independently of one's physical position with respect to the robot. In addition, these embodiments make possible a dynamic configuration of the robot, since the control parameters of the robot may be configured for the production requirement that prevails at the time in question, which means that the wear of the robot can be minimized.
According to a further embodiment of the invention, a second recording device is arranged for the purpose of recording and storing control signals sent from the control system to the motors of the robot. By this embodiment, rapid information is provided as to what loads have been carried in reality, and this fact, together with the recorded movement instructions, will contribute to facilitate analyzing and detecting why one or more faults have occurred.
The object of the invention is also achieved with a method according to claim 6, and such a method comprises recording the instructions emanating from the program executer as well as said data before these instructions are received by the path planner.
In the following the invention will be described in greater detail with reference to the accompanying drawing.
What is saved is either:
From the recording device 9, recorded instructions and data are transferred to the data-processing unit 3, either continuously or on command, for further processing and analysis of data and instructions. In the embodiment shown, the data-processing unit 3 is arranged externally, but the data-processing unit 3 may also be arranged in the existing control system 2. For example, the recorded instructions and data are processed in the external data-processing unit 3 so that the movements carried out by the robot 1 are recreated. By simulating the re-created movements, different types of analyses may then be carried out with the aid of the simulation results.
Data to the path planner 7 comprise variable values which, for example, may be the position where the robot 1 is to move, at what speed the robot 1 is to move, or what load the robot 1 should carry. The variable values may:
The variable values that are to be forwarded as data may be indicated by the client via different channels, such as, for example, the task program 5, the programming equipment or via cfg files. These values may also be obtained via external sensors but will then enter as data via the above-mentioned channels.
One example of a program instruction in the task program 5 may be: “MoveJ p—Rep,v60,fine,t_pin;”
The program executer 6 generates, based on the above program instruction, the following instruction and data to the path planner 7:
“MoveJ[[0.34,404.47,1214.72],[0.00012,0.999974,0.00731,4.6E-05],[0,−1,−2,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],[60, 120, 500, 500, 500],fine,[TRUE,[[0,0,210],[1,0,0,0]],[6,[340,0,0],[1,0,0,0],0,0,0]];”
The task of the program executer 6 is to obtain the necessary data to the path planner 7, and to generate a matrix containing these data. The matrix is the used by the path planner 7 together with the instructions sent from the program executer 6 to plan the path of the robot 1.
The following example describes a task program 5 and what instructions are generated to the path planner 7, based on the instructions in the task program 5.
An example of a program:
“AccSet” is a command that determines the level of performance of the robot 1, where for example “100,100” means that 100% of the performance of the robot 1 is utilized, and “50,50” means that 50% of the performance of the robot 1 is utilized.
It may be that, for example, the movement carried out by the instruction “MoveFast” in the above task program 5 is so tough that the robot 1 does not manage to run this movement more than, for example, 10 times per unit of time. The instruction “MoveFast” is carried out each time the variable “i” has the value “27”, and if the variable “i” is then assigned the value “27” each turn in the “WHILE” loop, the robot 1 will break down very quickly. To be able to know how many times the instruction “MoveFast” is carried out, the value of the variable “i” must be known. Since the value of the variable “i” is difficult to know from the beginning, the value of the variable “i” must be estimated based on guesswork and previous experience.
To be able to determine whether the robot 1 will manage to run the task program above for a certain application without being damaged, it is necessary to know how many times the instruction “MoveFast” is run in reality per unit of time. In reality, the command “MoveFast” is perhaps only run once per year or never.
If only the task program 5 shown above is used to determine if the robot 1 will manage to run the program for a certain application without being damaged, attempts must be made to create “all” possible sequences of movements while considering the “worst case” scenario. However, this is a time-consuming task and the result is uncertain since the value of the variable “i” is unknown.
To avoid the work described above, which is both time-consuming and uncertain as far as the result is concerned, the instructions from the program executer 6 to the path planner 7 are recorded while at the same time the instant when the instructions are sent from the program executer 6 to the path planner 7 is recorded and stored on the memory unit 10. These recorded instructions and time indications show how many times per unit of time the instruction “MoveFast” has been sent to the path planner 7. Thus, it is not necessary to know the value of “i” in order to determine how many times the instruction “MoveFast” has been carried out per unit of time.
The recording device 9 will record and store the following data:
The data column will in practice also include a set of variable values which influence the conceived path according to which the robot 1 is to work.
In this situation, thus, all the sequences of movement-related commands will be known because of the recording device 9 which records the information quite correctly and hence indirectly makes possible an analysis of the actual movements of the robot 1 with the aid of the external data-processing unit 3.
Number | Date | Country | Kind |
---|---|---|---|
60126974.2 | Dec 2006 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP07/64155 | 12/19/2007 | WO | 00 | 6/22/2009 |