I have an ABB IRB2600-12/1.85 6 axis robot arm with an ABB IRBPA750 2 axis positioner table. The TCP and table are calibrated in both RoboDK and on the robot pendent.
To test the coordinated motion of the system, I have the robot TCP following a point on the table as the table rotates +/-90 and tilts +/-90. When I generate a program as joint moves, the simulated RoboDK behavior matches the actual behavior of the robot. However, when I generate the program to use linear moves, the actual behavior deviates. The TCP drifts in the Y (~10mm) and Z (~80mm). The discrepancy between the MoveJ and MoveL behaviors suggests a base frame error. However, given the 10 and 80 mm shifts in Y and Z, I don't know where this offset is occurring (numbers are too big to be an offset of the mechanical unit but too small to match flange to calibration offsets).
Please help identify the cause of this discrepancy between the MoveJ and MoveL based programs.
In addition to the first question, there is a (related) question about user and object frames of the wobjdata. The RoboDK post outputs a wobjdata as follows:
Where robhold = false (robot is not holding work object), ufprog = false (moveable user coordinate system) and ufmec = user frame mechanical unit is named STN1, uframe = user frame as pulled from robot machining project/program with respect to the robot flange, and oframe = object frame is set to all zeros.
Reading the ABB RAPID manual, wobjdata should be defined as [FALSE, FALSE, "STN1", [uframe],[oframe]] where the user frame is the base frame of the positioner holding the workpiece (this is what the manual says, but in practice it appears to be the reference frame of the flange) and the object frame should be the reference frame with respect to the flange. When I output a program with respect to a reference frame (e.g. a toolpath along a part), RoboDK changes the user frame of wobjdata, not the object frame.
For example the RoboDK output is:
PERS wobjdata Adjustment := [FALSE, FALSE, "STN1", [[-217.173,-113.601,51.955], 0.99999749,0.00133557,0.00027939,0.00177687]],[[0,0,0],[1,0,0,0]]];
But, I think ABB is looking for:
PERS wobjdata Adjustment := [FALSE, FALSE, "STN1", [[0,0,0],[1,0,0,0]], [[-217.173,-113.601,51.955], 0.99999749,0.00133557,0.00027939,0.00177687]] ];
Can you please clarify how object frames are defined in RoboDK?
08-23-2024, 11:46 AM (This post was last modified: 08-23-2024, 11:46 AM by Albert.)
Since you have a turntable and the coordinate system of the part is attached to your turntable I believe you should use something like this for your ABB controller:
This is the default output of RoboDK, however, you should update the name of your mechanical unit for the turntable (not the robot). I believe this should be different from STN1. Maybe more like T6003 or IRBP_L.
Having the pose data in the uframe or the oframe fields should not make a difference. It should be on one or the other one. ABB accounts for the combination of both.
08-23-2024, 02:03 PM (This post was last modified: 08-23-2024, 02:49 PM by gsl130.
Edit Reason: Add pictures
)
(08-23-2024, 11:46 AM)Albert Wrote: Since you have a turntable and the coordinate system of the part is attached to your turntable I believe you should use something like this for your ABB controller:
This is the default output of RoboDK, however, you should update the name of your mechanical unit for the turntable (not the robot). I believe this should be different from STN1. Maybe more like T6003 or IRBP_L.
Having the pose data in the uframe or the oframe fields should not make a difference. It should be on one or the other one. ABB accounts for the combination of both.
I agree that the wobjdata should be defined as you suggest. However, RoboDK outputs the adjustment frame in the uframe, not the oframe (e.g. as the first frame, not the second).
I have updated my station to include identical sets of targets in a frame identical to the flange and at an arbitrary offset with respect to the flange (frame 11, [ 18.812915, 177.425007, -155.525247, -0.000000, 0.000000, -0.000000 ] WRT flange).
When I run TurnTableSTN1, the robot is close to the desired targets (offset in Y and Z per the MoveL vs MoveJ discrepancy). When I run TurnTableFrame11, the robot misses its targets by approximately the offset defined in the TurnTableFrame11 uframe. When I manually adjust TurnTableFrame11 to put the Frame11 offset from uframe to oframe, it behaves the same as TurnTableSTN1. RoboDK is not outputting the adjustment frames into the oframe as designed. Please advise on how to fix.
shows the -90 rotation of the TurnTableSTN1 program (first MoveL of program) comparing the programmed position (top) to actual position (bottom, read in from controller). Note the significant vertical offset.
shows the -90 rotation of the TurnTableFrame11 program (first MoveL of program) comparing the programmed position (top) to actual position (bottom, read in from controller). Note the significant offset in Y and small offset in Z.
The manually adjust oframe program produces the same result as TurnTableSTN1.
These images show the need to get the oframe set correctly (adjust my RoboDK output) and the MoveL discrepancy of my station (TurnTableSTN1 offset from programmed position).
Please also comment on the discrepancy between the MoveJ and MoveL. I don't understand what frame is misaligned to cause such a discrepancy. The good alignment when running MoveJ suggests the cell is accurately modeled and calibrated, and suggests a frame error somewhere.
I believe that setting the pose in the oframe or the uframe should show the same behavior as long as the other one is the identity.
However, if you want to output the frame in the oframe instead of the uframe you can customize the setFrame function of your post processor as shown in the attached sample code (note the comment called: Custom edit to output the frame offset on the oframe instead of the uframe).
Code:
def setFrame(self, pose, frame_id=None, frame_name=None):
"""Change the robot reference frame"""
if frame_name is not None:
if pose == eye(4):
self.WOBJDATA = "RobotBase"
else:
self.WOBJDATA = FilterName(frame_name, 'w', (set(RESERVED_NAMES) - set(self.FRAME_LIST)), self.CHARACTER_LIMIT)
set_data = ''
if self.HAS_TURNTABLE:
if self.TURNTABLE_IGNORE and self.FR_EXTERNAL_POSE is not None:
pose = self.FR_EXTERNAL_POSE * pose
set_data = '%s := [FALSE, TRUE, "", [%s],[[0,0,0],[1,0,0,0]]];' % (self.WOBJDATA, pose_2_str(pose))
else:
# set_data = '%s := [FALSE, FALSE, "%s", [%s],[[0,0,0],[1,0,0,0]]];' % (self.WOBJDATA, self.MECHANICAL_UNIT_NAME, pose_2_str(pose))
# Custom edit to output the frame offset on the oframe instead of the uframe
set_data = '%s := [FALSE, FALSE, "%s", [[0,0,0],[1,0,0,0]],[%s]];' % (self.WOBJDATA, self.MECHANICAL_UNIT_NAME, pose_2_str(pose))
else:
set_data = '%s := [FALSE, TRUE, "", [%s],[[0,0,0],[1,0,0,0]]];' % (self.WOBJDATA, pose_2_str(pose))
if self.WOBJDATA in self.FRAME_LIST:
self.addline(set_data)
else:
self.FRAME_LIST.append(self.WOBJDATA)
self.FRAME_DEF.append(ONETAB + 'PERS wobjdata %s' % set_data)
It is better if you can contact us by email to get the source code of the full post processor.
