Patent Application
20080091301
The present invention relates to a system according to the pre-amble to claim 1. The invention also relates to a method for controlling the movements of an industrial robot during a work cycle including visiting and performing work on a plurality of workstations in a work cell.
Before an industrial robot is to be put in operation for a certain task, it must be programmed to carry out the task. The person controlling a robot is denoted an operator. When programming an industrial robot, a robot language is used. There exist a plurality of different robot languages, since each robot supplier has developed its own robot language. A robot program comprises a series of robot instruction written in the robot language. The use of a programming language offers the advantage of great flexibility, but also requires that the operator, who is programming the robot, must have knowledge of robot programming, and in particular of the robot language of different robots. However, in industry it is not always possible to have operators with knowledge of robot programming. Thus, it is a desire to make it possible for operators without any knowledge of programming language to program the robot in a simple and intuitive way.
Robots are usually placed in robot cells or lines, in order to facilitate the automation of a complex series of actions. The robot cell may comprise a number of different workstations, including machines, process units and/or other equipment, and the robot is programmed to perform different tasks at the different workstations.
Programming of a robot includes programming the robot to perform a work cycle in accordance with an application served by the robot. Within robotized manufacturing, materials and components are moved between the different workstations. Normally, the process follows a certain pattern, which depends on a desired part flow. The part flow is the order in which a part, e.g. a workpiece, should be handled by different machines and process units. To control the movements of the robot when it moves between the workstations in a robot cell, a robot program is written in advance describing in detail the necessary movements of the robot to perform the work cycle. The robot program also has to take into account events, such as faults or emergency stop, occurring during execution of the robot cell. This means that a plurality of different paths have to be programmed in advance to cover all necessary movements of the robot.
However, in industry, the manufacturing process often changes, for example when a new type of part is to be produced, and then the robot cycle has to be adjusted. Adjusting the robot cycle means that the robot has to be reprogrammed, i.e. the robot program has to be rewritten. This reprogramming is time consuming and sometimes difficult to do since a large number of program routines has to be changed.
The object of the present invention is to provide an attractive solution, which alleviates the problems mentioned above, and which makes it easy for an operator to program a robot to execute a new work cycle and makes it quick and easy for the operator to make adjustments of an existing robot program.
According to the invention this object is achieved by a system as specified in claim 1.
A workstation is a physical location on which the robot may carry out work. According to the invention, a set of predefined workstations is stored in a memory location. Each predefined workstation represents a real workstation, including a specific type of machine or equipment, and a defined task to be carried out by the robot at the workstation. The predefined workstation is a model of the real workstation and comprises preprogrammed robot code, an entry point defining the entrance position to the workstation, and one or more predefined paths to be followed by the robot at the workstation. The preprogrammed robot code is specially designed for controlling the robot so that it carries out the defined task at the workstation and the code is adapted to the specific type of machine or equipment of the workstation.
Examples of workstations are: an injection mould machine, a die-casting machine, a scrap station for throwing away rejected parts, a device for vision control of the part, one or more stations for subsequent treatment of the part, and an output station such as a conveyer. Examples of tasks are: pick a moulded object from the mould, throw the object in the wastebasket, hold the object during a vision control, move the part in a predefined way in relation to a treatment tool, put the part in an assembly with other parts, place the part on the conveyor. The subsequent treatment is for instance flaming, deburring, degrading, dispensing, polishing, grinding or painting.
The operator creates a robot program by selecting one or more workstations from the predefined set of workstations and specifying a desired part flow between the workstations. The part flow is the order in which a part should be processed by the workstations. The user interacts with the user interface during creation of the robot program. A robot program is generated based on the stored, predefined workstations including predefined robot program code, and information entered by the operator. The predefined workstations includes predefined movement path for carrying out the task. This helps the operator, who does not need to bother about programming complicated movements at the workstations.
The system further comprises a scheduling unit, which is adapted, during execution of the work cycle, to schedule the execution order for the workstations based on the workstations selected by the operator and the part flow input by the operator, and to move the robot based on the scheduled execution order and the predefined paths. The scheduling makes it possible to automatically modify the execution order for the workstations during execution of the work cycle and thus makes it possible to let the robot work asynchronously with the different work cells.
The invention makes it possible for an operator without any knowledge of robot programming to program a work cycle for a robot. The invention makes it easy for an operator to make adjustments in the work cycle in connection with adding and removing workstations to the robot cell, and to make changes in the part flow. The part flow can easily be changed without any recoding, and workstations can be added and removed from the work cell without any recoding. The operator does not have to do any changes in the program code when reprogramming the robot. The only thing the operator has to do is to select one or more new workstations from the set of predefined workstations and input a new desired part flow.
According to an embodiment of the invention the system is adapted to receive information about external events and the scheduling unit is adapted to determine which of the workstations to be executed next based on said information about external events. External events are for example changes in the status of the workstation, for instance that a machine is ready to be loaded, a machine is ready to be unloaded, or a workstation is not ok, due to the fact that an error has occurred in a machine. According to this embodiment the execution order is event-driven. The execution order is determined in run time, instead of in advance as in prior art robot systems. Thus, the work cycle for the robot does not have to be programmed in advance. Another advantage with this embodiment is that the execution order will automatically change in run time when something goes wrong or a workstation is not ready. Thus, it is not necessary for the operator to intervene.
According to an embodiment of the invention the system is adapted to receive information regarding the status of the workstations and the scheduling unit is adapted to determine which of the workstations to be executed next based on the current status of the workstations. In particular, the system is adapted to receive information regarding changes in the status of the workstations. If the scheduling unit knows the current condition of the workstations and the desired part flow, the scheduling can be done generically, which in turn provides that the part flow can easily be changed without any recoding.
When the robot is allowed to work asynchronously there is a risk of deadlocks, for instance if the robot has extracted a part from a die-cast machine and has to place it in a trim machine, but the trim machine is not ready to be loaded because it has not yet finished trimming the previous part. To avoid this there must be some sort of buffer station, where the parts can be temporarily placed waiting for the machine to be ready.
According to an embodiment of the invention the system is adapted to provide a possibility to point out an alternative workstation to be executed if the ordinary workstation is not ready to be executed, and that said scheduling unit is adapted to determine which of the workstations to be executed next based on pointed-out alternative workstations. Thus, if a station is not ready to process a part, the robot moves to the alternative station. The alternative workstation may be a parallel workstation which reduces the cycle time of the work cycle. In this way failures and delays can be handled automatically in a predefined way.
According to an embodiment of the invention the system is adapted to provide a possibility to assign different priorities to the chosen workstations, and that said scheduling unit is adapted to determine which of the workstations to be executed next based on the assigned priorities. This embodiment makes it possible to have different machines that work with different parts in parallel to increase the output from the workcell. For instance, when one part is machined in a saw station, another part is extracted from a die-cast machine.
According to an embodiment of the invention each of said predefined workstations comprises a model of a real workstation including a software object having an interface with one or more properties, methods and events, and the object is adapted to interact with the surroundings through its properties, methods and events. Each workstation is modeled as an object independent of the other stations in the workcell. This embodiment makes it easy to create new workstations.
According to an embodiment of the invention said properties include the status of the workstation.
According to an embodiment of the invention said properties include the alternative workstation to the workstation.
According to an embodiment of the invention said properties include the priority of the workstation.
According to an embodiment of the invention said methods include one or more interrupt routines defining what to do when a specific interrupt signal arrives and said scheduling unit is adapted to execute the interrupt routine upon receiving the specific interrupt signal.
According to an embodiment of the invention the interface has an event adapted to trigger on a change in a signal corresponding to the status of the workstation and based thereon to update the status of the workstation.
When a fault occurs during a work cycle, it is desirable that the robot is automatically moved out of the workstation and then moved to a predefined home position, which preferably is the starting point of the work cycle. From this position a new work cycle should be started as soon as possible.
According to an embodiment of the invention said predefined paths comprise a predefined station path defining the robot movement into and out of the workstation, wherein the station path comprises an entrance path defining the robot movement from the entry point to a process point defined inside the workstation and an exit path defining the robot movement from the process point out of the workstation. In order to get a structured way to programming the workstations, the robot movements within the workstations are structured into predefined categories of paths. Due to the fact that there are predefined entrance and exit paths for all workstations it is possible to automatically move the robot out of the workcell when an error has occurred.
According to an embodiment of the invention said predefined paths comprise at least one predefined process path defining the robot movement inside the workstation, wherein the process path comprises a second entrance path defining the robot movement from said first process point to a second process point defined inside the workstation and a second exit path defining the robot movement from the second target point back to the first process point.
According to an embodiment of the invention said predefined paths comprise an array of predefined path points and said scheduling unit is adapted to retrieve the path points from said array upon execution of the path. Due to the fact that the path points on the predefined paths are stored as an array of points, it is possible to move the robot forward as well as backward along the predefined paths. This is advantageous, for instance, when an error has occurred.
According to an embodiment of the invention said predefined path points comprise information about whether the point is a move-in or a move-out point, and the type of movement in the point, e.g. whether it is a linear or a joint movement. This information teaches how the robot should be moved between the path points. This information is also useful during fault recovery.
According to an embodiment of the invention said set of predefined workstations comprises at least one predefined work cell comprising: an entry point of the work cell defining the entrance position to the work cell, predefined paths to be followed by the robot between the entry points of the workstations, and predefined paths to be followed by the robot from each entry point of the workstations to the entry point of the work cell. Preferably, the entry point of the work cell is the home position of the robot. What fault recovery all comes down to is to move the robot to home position safely and as fast as possible. This embodiment makes it possible to automatically move the robot to the home position from each workstation in the workcell.
According to an embodiment of the invention said predefined work cell comprises a model of the real work cell including a software object having an interface with one or more properties, methods and events, and the object is adapted to interact with the surroundings through its properties, methods and events and that the software object of the cell has the same interface as the software objects of the workstations. According to this embodiment the workcell itself is modeled as a station object.
According to an embodiment of the invention the scheduling unit is adapted, upon receiving a fault interruption signal, to move the robot out of the workstation and to the entry point of the work cell by moving the robot along said predefined paths in dependence on the current position of the robot. A condition for this is that the scheduling unit knows in which workstation the robot is, and on which of the predefined path the robot is when the fault occurred. Then, it is always possible to safely and automatically move the robot back to the home position when a fault has occurred.
According to an embodiment of the invention the scheduling unit is adapted to move the robot along said predefined paths in dependence on one or more predefined rules. For example, the rules comprises, in case the failure occurs when the robot position is on the entrance path, the robot will reverse on the entrance path, and in case the failure occurs when the robot position is on the exit path the robot will continue to follow on the exit path. According to this embodiment faults are handled without prior specific programming of various failure cases.
According to one aspect of the invention this object is achieved by a method as specified in claim 21.
According to a further aspect of the invention, the object is achieved by a computer program directly loadable into the internal memory of a computer or a processor, comprising software code portions for performing the steps of the method according to the invention, when said program is run on a computer. The computer program is provided either on a computer readable medium or through a network.
According to another aspect of the invention, the object is achieved by a computer readable medium having a program recorded thereon, when the program is to make a computer perform the steps of the method according to the invention, and said program is run on the computer.
The invention is useful for programming and controlling industrial robots for any application including visiting and performing work on one or more workstations. The invention is particularly useful for programming robots in connection with handling moulded parts from moulding machines, for example in connection with injection moulding, die-casting, well machine tending and material handling in general.
The invention will now be explained more closely by the description of different embodiments of the invention and with reference to the appended figures.
a shows an example of robot movements between two workstations.
b shows an example of robot movements between three workstations.
In the following the invention will be described in a relation to a die-casting machine. However, the invention is not limited to applications including die-casting machines. On the contrary, the invention is just as well applicable for any applications including visiting and performing work on one or more workstations.
The robot performs a work cycle including visiting and performing work on the workstations 6-11. The workstations are, for example, a die-casting machine (DCM) and surrounding equipment for handling or machining the parts produced in the die-casting machine. The workstations are for example a die-casting machine 6, a cooling device 7, a sensor for checking the part 8, a trimming machine 9, a sawing machine 10, and an out feeder conveyor belt 11. In the figure the robot holds a part 12.
A typical robot cycle for serving a die-casting machine includes several or all of the following tasks:
The functionality of a workstation is installation specific, e.g. a die-casting machine is provided with or without an insert, a quench is provided with or without a fixture, and the customer wants a signal to be set at a certain point in time. This differs a lot and software that can handle all different customer demands in a generic way would be very complex and difficult to maintain. The idea according to the invention is instead to model a workstation as an object with properties, methods and events. The properties, methods and events are the interface to the surroundings. The library 20 comprises a plurality of objects representing different workstations, for example one object represents the die-casting machine, and other objects representing the trimming machine, the sensor, the sawing machine, the pallet station, the conveyor belt and the cooling station.
The workstations should be executed in a certain order, which depends on the desired part flow. The part flow is the order in which a part should be processed by the workstations in the workcell. During the work cycle, the robot moves between the workstations and moves in and out of the workstations. A task for the scheduling unit is to keep track of the current condition of the workstations. Another task for the scheduling unit is to keep track of the current position of the robot. The scheduling unit determines the next station for the robot to be moved to based on the part flow input by the operator. The part flow is stored in a string array. When the scheduling unit has determined which workstation to be executed next, the robot is moved to the next station along a predefined path, and when the robot has been moved to the next station the predefined robot code of the station is executed.
The property “name” is the name of the workstation. The property “priority” is used during scheduling to determine which station to be executed next. The priority is a number ranging from one up to a maximum number. Preferably, the operator sets the priority of the workstations. To make the robot cell in
The property “status” is dynamic and changes during run time. The status can, for example, be assigned: workstation is ready to be loaded, workstation is ready to be unloaded, workstation is busy at the moment, but will in a while be ready to be unloaded, station is busy at the moment but will in a while be ready to be loaded, and station is not okay, which means that the workstation is in a failure state.
Another important property is “alternative station”, which is the name of the workstation to be executed if the current station cannot be executed. For example, if the station is in a failure state, not ready to be loaded, or unloaded, the next station to be executed is the alternative station of the station. For instance, the alternative station to a trimming station could be a scrap station. It is also possible to have more than one station of the same type, for example to have a first and a second trimming station, wherein the second trimming station is the alternative station for the first trimming station and vice verse.
A station object must always have a predefined station path, and could besides the station path have an arbitrary number of process paths. Any processes like grinding or spraying may require one or several secondary path starting from and ending in the primary process position. Each path comprises an entrance path, a process position, and an exit path. A path is defined as an array of path points and could have an arbitrary name. A path may comprise different types of path points such as an entry point, a process point, a move in point, or a move out point. A path point is described by the following properties: the type of point, the type of movement in the point, i.e. weather it is a linear or a joint movement, the position of the point, the speed of the robot to the point, the zone around the point, and the name of an attached procedure. The attached procedure will be executed when the robot arrives at the path point.
The entry point for the first 41 and second 42 process path is the process point 44 for the station path. The process path 41 also includes a process point 49, move in points 51, and move out points 53. The process path 42 also includes a process point 50, move in points 52, and move out points 54. The robot has to finish a process path before it can start moving on another process path. For example, the robot can not move to the first process path process point 49 and from there start moving on the second process path. The robot has to move back to the entry point 44 of the first process path before it can start moving on the second process path 42. For each workstation an entrance path defining the robot movement into the workstation, and an exit path defining the movement for the robot to leave the processing point have to be defined.
If a workstation should do anything like checking its status, unloading a part, or returning a path, the methods of the station object are called. The station object shown I
It is important that the values of the arguments be updated according to where the robot is. For example, a workstation has a cooling rack with ten shells. Such a station includes a station path, ten unload path and ten load path. Thus the station includes twenty-one paths.
The events of a station object are interrupts defined to trigger on a signal change. If an interrupt affects a station's status, the interrupt has to be connected to an interrupt routine and the interrupt routine must in turn execute the method check status.
The scheduling unit could be seen as the brain and motor of the workcell. Its responsibilities are to ensure a correct and fluent scheduling of the workstations, to secure a valid fault recovery and to provide a set of constants, routines and events, which are used in the programming of the stations. The bottom line when it comes to scheduling is to pick the station to be executed next, based on the status of the stations, a define part flow, the history of the part and the status of the robot tool. In order to get the status of a station, the scheduling unit has an array, denoted xctStation-list, which holds, for all stations, the name of the station, the priority of the station, the current status of the station, and the alternative station to the station. The stations alternative station is the name of the station to be executed if the station cannot be executed.
The status of the tool is, for example, tool is open or tool is closed. When the tool is open, the robot can grip a part, and then the only stations of interest are those that can deliver a part to the robot. Those stations are included in another list denoted a xctQ-list. For example, the xctQ-list only includes stations that will be or are ready to be unloaded.
To be able to schedule when the robot holds a part during normal production, it is necessary to know where the part has been and at which station the part is supposed to be next. For scheduling when a robot holds a part, the scheduling unit uses two variables: an array variable describing the part flow, denoted xctPf-list, and another variable holding the history of the parts, denoted xctPart. The variable holding the parts history holds the name of the part, the name of the station where it was last processed, and a Boolean telling the scheduling unit weather the part shall follow normal part flow or not.
Central to the scheduling is to know if the tool of the robot holds a part or not. A variable, denoted xctTool, of a custom defined type, holds the name of the tool and the status of the tool. Tools status can be either of the following three: open, closed and not okay.
The first thing the scheduling unit does during scheduling is to check the status of the tool. If the tool is open, the next station to be executed is picked from the xctQ-list with respect to priority and status. If the tool is closed, the next station to be executed is picked from the execute part flow list, based on where the part has been earlier (xctPart), and where it is supposed to be according to the part flow. The third condition the tool could have is to not be okay. This is a failure state that forces the scheduling unit to move the robot to its home position.
Independent of weather the next station was picked from the xctQ-list or from the execute part flow list (xctPF-list), the result is that a variable, denoted NextStation, is assigned the next station to be executed. But before the schedule station can be executed, it is necessary to check the status of the next station, and then the robot is moved to the scheduled station.
In the following the scheduling when the tool is open will be described. When the tool is open the next station to be executed is picked from the xctQ-list. The stations that can either be unloaded directly, or can be unloaded in a while, are included in the xctQ-list. The stations are sorted in decreasing priority order in the xctQ-list.
In the following, scheduling when the tool is closed will be described. Scheduling when the tool is closed and the robot holds a part is based on at which station the part was last processed and where the part is supposed to be processed next, according to the defined part flow.
It is possible to depart from the normal part flow and force a part to any station, by setting an object station of the xctPart variable to the name of the next station and setting the alternative route of the execute part variable at true. Thus, the wanted station will be executed and normal scheduling will then continue. Depart from normal part flow could, for example, be used by a sensor station. If a part is not sensed, something is wrong with the part and the part should not continue on the normal route, but instead it should be delivered to the scrap station.
Before the robot is moved to the scheduled station a check has to be made to ensure that it is possible to execute the scheduled stations entry point, and if not, the alternative station of the scheduled station is instead scheduled to be the next station to be executed. For example, let us say that the robot has picked a part from a cooling rack and the next station for the part, according to the part flow, is the trimming station. Thus, the trimming station is scheduled as the next station, and before the robot moves to the trimming station the status of the trimming station is checked. But the trimming station cannot receive a part because it is in a failure state, or there is already a part in the trimming station, then the alternative station to the trimming station will be executed instead.
When the robot has moved to and arrived at the entry point of the scheduled station, the status of the station is checked a second time. Depending on the status of the station, the scheduling unit either executes the scheduled station, waits at the entry point for the scheduled station to be executable, or executes the alternative station. Table 1 below will show what the executing unit will do depending on the status of the scheduled station and the status of the tool. Such a check is done twice, a first time before the robot moves to the scheduled station, and a second time when the robot has arrived at the scheduled station's entry point. Thus, a status change of the scheduled station will be caught.
Moving the robot between the workstation is taken care of by the scheduling unit. The robot is moved from a workstation's last point to the next station's entry point.
b shows another embodiment of the invention in which the entry point 91-93 and the exit point of the station path are the same point. The path between the workstations is denoted the main path 94 and it goes between the entry points of the workstations. If not specifically defined, the robot selects the shortest way between the different entry points. If needed, the main path can be customized in order to avoid obstacles. The main path defines the main sequence of the process. For each station a secondary alternative station has to be defined. If a station is not ready to process the part the robot moves on to the alternative station. In this way, failures and delays can be handled automatically in a predefined way. If two stations are incompatible, it is possible to either define that the robot shall move via another station, or include a dummy station. The dummy station is nothing more than a point.
It is virtually impossible to make a process so robust that it does not interrupt or any failures occur. To avoid manual intervention it is essential to have an algorithm and a strategy that automatically redirect the robot in a predefined way. The failure handling is done according to a few simple rules. In the following the rules will be described in a general manner.
If the robot is on the main path, and the next schedule workstation is not ready to accept a new part, the robot will be directed to the alternative station of the scheduled station. If this station is also not available for processing, the robot will commence until the end of the chain that preferably could be a wastebasket or storage. If a failure occurs when the robot is inside a workstation there are three possible cases of failure occurrence:
1. During the movement towards a process point.
2. When the robot is in the process position.
3. When the robot is on its way out from the process position. This applies to the station path as well as to any of the process paths.
If the robot is moving along the entrance path on its way towards the process position and a failure occurs, the robot will reverse along the entrance path, and bring the part, for example, to the scrap bin.
If a failure occurs when the robot is in the process position of the station path, the robot will follow the ordinary exit path. After reaching the exit point, the robot will, for example, commence to the scrap bin. If a failure occurs in a second process position, the robot will immediately go to the first process position of the station path via the exit path of the process path, and then for example to the wastebasket via the exit point, disregarding possible other secondary process points. If a failure occurs on the way from a process position, the ordinary exit path will be followed.
One object of the fault recovery is to move the robot to its home position safely and as fast as possible. If the robot holds a part in its tool, the robot should throw the part in the scrap bin, before moving to the home position. When the robot is in its home position all its axes are in its zero position. The home position is the initial position of the robot, i.e. the starting point of the workcell. Fault recovery is based on two major fundamentals, one is that the robot cell itself is modeled as a station object, and a second is that the scheduling unit at every given moment knows where the robot is, and can get information about which path the robot was on when the fault occurred. The first fundamental is used to tell the scheduling unit that the robot shall move to the home position. The second fundamental is necessary to know to be able to move the robot out of a workstation.
As mentioned before, the work cell itself is modeled as a station object. The work cell object has the same properties as the other station objects and the same methods as well. The entry point of the cell object is the home position. The robot must always have a station to put a part, for example a scrap beam to prevent that the robot moves to home position with the part. The status of the cell object is set at unload okay which tells the scheduling unit that the robot shall move to the home position, and eventually the work cell object will be scheduled as the next station to execute.
It is desirable for the robot to be able to move to home position from every point on any path in any workstation. For the scheduling unit to be able to move the robot to the home position from every point in the cell, it is required that the movements in a station be made with dedicated move-routines provided by the scheduling unit. The move-routines provided from the scheduling unit have two arguments. The first argument is a path ID, which tells the scheduling unit about the type of the path, and the second argument is the path itself. The scheduling unit defines four different path IDs:
1. Robot on main path, which is used internally in the scheduling unit when the robot moves between the stations.
2. Robot on station path, which indicates that the robot is on the station path on its way into and out of the workstation.
3. Robot on process path 1, which indicates that the robot is on the first process path of the workstation.
4. Robot on process path 2, which indicates that the robot is on the second process path of the workstation.
To keep track of which path the robot is on, the scheduling unit has a variable, denoted PathPointer. The PathPointer can be assigned any of the path IDs described above. The scheduling unit also needs to keep track of at which path point the robot is. Thus, two further variables are needed, the first variable points at the station path, denoted PointAtMain, and the second variable points at any of the process paths, denoted PointAtSub.
Since the robot knows from the scheduling in which station the robot is, or will be, and it is known in which station the robot was last, the scheduling unit has all information needed to be able to run the robot to the home position from every position in the cell.
The following example explains how the home running works. Assume that the robot is in a die-casting station at point four 115 on the first process path in
For the station path the scheduling unit uses the Point-AtMain variable to get where to start on the station path. The robot moves to the end of the station path i.e. to the entry point 113 by following the exit path of the station path. When the robot is out of the station a scheduling is done, and since the status of the cell station was set at active when home running started, the cell station will be scheduled as the next station which means that the robot will move to the home position.
There are basically three types of faults:
1. Station faults, which occur when the status of the station is not okay.
2. Predictable faults, which are faults that occur at a certain position in the code, for example a watchdog exceeds its maximum time.
3. Unpredictable faults, for example emergency stops and joint errors. This type of faults terminates execution and restart is required.
The same rule will apply to all three types of faults and the rule is: Move the robot to home position before continuing production. If the robot holds a part at the fault occurrence, scrap the part and then move to home position.
The present invention is not limited to the embodiments disclosed but may be varied and modified within the scope of the following claims. For example, it is possible to use an external computer to implement the invention. It is also possible to control the movements of a plurality of manipulators with a common system according to the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0402891-6 | Nov 2004 | SE | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SE05/01676 | 11/7/2005 | WO | 5/29/2007 |
