BASE and NULL are 2 entirely commands.
Kawasaki do not have WORLD BASE references, only BASES.
BASE sets whatever parameter that follows it:
- BASE NULL will set the base to 0,0,0,0,0,0 (null values - that what null means).
- BASE frm_test will set the base to whatever values are defined as frm_test.
- BASE TRANS(0,0,0,0,0,0,0) will set the base directly using the TRANS values.
- BASE NULL + TRANS(0,0,0,0,0,0) will set the base and add the TRANS values to NULL values.
If you are using compound commands such as:
BASE wrld+part_frm, then the righter most values are an offset to the left values.
But when changing bases, make sure you have set the correct base when teaching/tickling locations.
BASE is just a frame (without the frame command) and I recommend to everyone, if changing bases (frames), make sure you are in the 'right frame of mind' before teaching/tickling locations.
I personally steer clear of BASE changes where I can and leave it as NULL and use compound transformations to form motion segments instead.
The robot is rotated by 65 degrees on the floor relative to everything surrounding it. If the world coordinates of the robot could be changed it would be more intuitive moving it relative to everything else. Eg. now when moving the robot in the NULL-base it will move diagonally over pallet-positions etc.
Yes with a 65 deg rotation change and then using NULL would cause a diagonal motion segment.
Myself, just having the 2 coordinate systems available (Tool and Base) simplifies things as you physically mount the robot, then adjust the BASE to suit the world it's living in.
Any additional coordinate systems would usually be via FRAME command and make the location relative to the base then.
There is no command or reference to any World base components. (AFAIK).
KROSET Simulation includes a World interpolation, but no command.
You just need to make sure where this BASE is to be set, as the robot uses this for all it's kinematic calculations and having the robot physical position and base coordinate too far apart could introduce motion out of range areas......but that is dependent on your programming unless you are using joint angles of course.
It would also make it easier to set the workspace area limitations if the robot "believed" it was facing the fencing at 90 degrees (when in reality at 65 degrees) since the workspace limitations does not contain any rotational component.
Correct.
Workspaces are relative to the applicable BASE coordinate, yes there is no rotational component associated with Kawasaki workspaces.
worldbase = trans(0,0,-900,65,0,0)
You sure -900 is correct as your placing the robots measurement system 900mm through the floor?
-900 is because it is placed on a pedestal.
Ah right, you said it was mounted on the floor, that's why I asked.
So your taught locations are referencing from floor height I expect.
One would have a separate base for each pallet position, pick table and any other workspaces surrounding the robot.
If you weren't using the BASE for the world coordinate, many people use the BASE for that purpose but depending on the application, could get messy with many BASE changes.
For instance if an operator was tickling locations, very easy to just jump in and out of programs without executing the BASE command first.
Then they would potentially be tickling locations using the wrong BASE, which could lead to an 'amazing robot demolition show'.
So a frame in kawasaki is essentially what is called a base in other brands and base in kawasaki is essentially what other brands refer to as a worldbase?
Pretty much yes, but due to Kawasaki's powerful AS language, it allows programmers to use 'artists choice' on how it is deployed.
Do not get confused with your use of frame above as Kawasaki also has the FRAME command which is not BASE command.
Sounds like you've got it.............. 
If you weren't using the BASE for the world coordinate, many people use the BASE for that purpose but depending on the application, could get messy with many BASE changes.
I'm in trouble with BASE command now
I have some subroutines with some different BASE respectively
So, I write a "safety" subroutine, it's purpose is move robot to the "safety position" no matter where the robot is.
When I call "safety" subroutine, I change base to BASE NULL and check the robot's coordinate, then based on that position, give the corresponding movement command.
The problem is: although i change to BASE NULL but it seems robot still use the previous base in subroutine
Below is my code
.PROGRAM escape_safety()
BASE NULL
rtn_x = dext(dest,1)
rtn_y = dext(dest,2)
rtn_z = dext(dest,3)
;----base on above value to jump to correct command---
IF (rtn_x <= -1200) THEN
safe_return = 1
GOTO escape1 ;inside_molding
END
IF (rtn_x <= -795) AND (rtn_x > -1200) THEN
safe_return = 2
GOTO escape2 ;molding -> waitdoor
END
;----command to return safety-----------
escape1:
LMOVE #be4_setup_md
escape2:
LMOVE #waitdoor
done_escape:
JMOVE #safety_pos
RETURN
.END I know that we can use transformation value by operator "+" in stead of change BASE. But is there solution for this problem?
Thanks in advance
Where was the location 'dest' taught with reference to what BASE?
I suspect that is your issue.
When doing recovery, you should really use HERE and obtain a current location referencing the current BASE you are using and carry out element comparison arguments using the HERE elements instead.
Where was the location 'dest' taught with reference to what BASE?
I suspect that is your issue.When doing recovery, you should really use HERE and obtain a current location referencing the current BASE you are using and carry out element comparison arguments using the HERE elements instead.
Yes, I misused it.
"Dest" return the transformation values of the destination of current robot motion NOT for the current position.
Btw, can you show me how to use compound transformation value?
Eg: I had a base call "frmaster" and a point "setup" relative to that base
BASE frmaster
LMOVE SHIFT(setup by 2, 0, 2)
Without changing base to "frmaster", how to implement this movement use BASE NULL?
I tried frmaster + setup + trans(2,0,2) but it seems wrong
Btw, can you show me how to use compound transformation value?
This is explained in the AS manual under the section 'Using compound transformation values' and includes a nice picture and working example.
Going from SHIFT to TRANS is not straight forward (you are talking about apples and pears.
Both are fruits (cartesian references) but have fundamental differences (look and taste different).
SHIFT is relative to the current BASE in XYZ only.
TRANS is relative to XYZ and orientation direction of the TOOL or taught transformation values.
I suggest to read further about these in addition to the compound section in the AS manual and also take a trip over to here Kawasaki tutorial videos
Kawasaki has provided some excellent webinars to view as educational demonstrations which are very good entry level examples and don't forget to pass on appreciation (Reaction) to Amsterdam for providing the link.
