Status: RDK_DriverSocket works perfectly allowing control of arm and positioner.
Problem: mod file produced by ABB IRC5 Post creates a wobjdat (base) from RoboDK, but references the tool flange of the positioner table (per RoboDK tree). When the code is loaded on the pendent, the values in the base created are identical, but the pendent base is referencing some other predefined position - we call this "pendent world frame". This results in the robot trying to follow the programmed path in the wrong place (correct path but wrong point in space). ABB IRC5 Post output, HIMOM_M003_2_.mod, attached for reference.
Question: How do I control the reference frame that the ABB IRC5 Post wobjdata coordinates are referenced to? Alternately, how do I change the ABB pendent to call out the point that a base is referenced to?
A few interesting observations:
* When posted out via the RoboDK Python Post (as opposed to the ABB IRC5 Post) and run from the computer via RDK_SocketDriver.mod, the robot and positioner table motion is correct
* The python file generated from the RoboDK Python post only shows moves for the robot (x, y, z, euler angles) and nothing for the positioner table, yet the positioner table moves when the python program is run.
* The output mod file from the ABB IRC5 Post shows the same move definitions as seen in RoboDK (program generated from Robot Machining Project as seen in the tree).
I assume you customized some settings in your post processor as I see you specified the STN axis unit in your wobjdata variable (workobject held by your turntable).
By looking at the coordinates of your wobjdata we find this:
XYZ=[119.387,-222.565,-145.955] (the negative Z coordinate looks suspicious, it is usually positive and centered on XYZ)
Quaternion=[0.70823511,-0.00006789,0.00000606,0.70597665] (which is the same as a 90 deg rotation around the Z axis).
I would check if the flange of the turntable has been properly defined (kinematics and Tool flange position). And any coordinate system directly attached to your positionner will be your workobject.
If you can share your setup as an RDK project file we can better help.
02-09-2024, 08:02 PM (This post was last modified: 02-09-2024, 08:14 PM by gsl130.)
Set up of positioner table is a bit tricky, but your comments got us squared away there - the flange frame is now sitting on the flange itself (rather than at the intersection of the B and C axis where the calibration puts things). However, we are still seeing mismatch between the RoboDK simulated motion and the motion generated by the module run from the pendent.
Attached:
rdk project file
module generated by ABB IRC5 Post - post file modified with mechanical unit name "STN1" and EXTAXES_IDX = [1,2]
Video showing actual robot motion when run from module file on pendent
in the next post is a video showing actual robot motion when same program is streamed from RoboDK via RDK_SocketDriver.mod
This last video is the same mod file as above streamed via RDK_SockedDriver.mod (compare with the mod file run on the pendent) and you see very different behavior). When streamed from RDK, everything is aligned correctly whereas when from the pendent it is misaligned - too far forward, too close to the bottom of the screen, and was manually stopped to avoid a collision with the table.
The fact that the same program works when streamed but not when run from the pendent is odd.
When you use the driver, RoboDK sends the joint values that have been simulated to the robot, and the robot makes the kinematic calculations to make the real robot match the simulation even if the coordinate systems have not been properly defined in RoboDK or the real setup.
Therefore, a quick workaround to make this work with your setup is to output linear movements using joint targets. You can output joint targets for linear movements by changing this setting:
Select Tools-Options
Select the Program tab
Set Output for linear movements: Joint data
This will force calculating the Cartesian targets for all MoveL movement using joint values on the robot controller (therefore, using its own coordinate systems even if they don't match with the ones you setup in RoboDK). For ABB this will force using the CalcRobT function and you'll see a much of MoveLs with CalcRobT as shown here:
Trying to better understand and solve this issue so you can generate Cartesian targets, I believe we should review the root coordinate system of your turntable. To do so, you can add a coordinate system called Turntable Flange attached to the turntable and set to zero (all values of XYZWPR set to zero, as shown in the attached image and project). By doing so, you get the coordinate system shown in the attached image. Also, if your tool is set to toolRDK (as shown in the robot panel), you should see the same coordinates of the position of your TCP with respect to the turntable (for example on the robot teach pendant or RobotStudio). Is this the case? There is probably something different. My guess is that the turntable flange can be rotated by +/- 90 deg or 180 deg. Or it could be that the turntable flange has its own fixture defined. In that case, we should transfer the modifications you have to do to this Turntable Flange to the Tool pose of the turntable parameters (so it is part of the kinematic system).
