Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Kuka KRC2 CAMROB machining setup Rotary table issues

#1
Hello you roboDK geniuses,

Having issues getting my 7th axis/rotary table working correctly with RoboDK. Wondering if anyone has any insight on this.

The main issue I am having is that when I post code using the KUKA KRC2 CAMROB post I have no problems running 6 axis code. The robot does exactly what the simulation shows. When I run 7 axis code (with a rotary turntable) instead of doing exactly as the simulation shows the robot rotates the spindle in sync with the turntable toward the robot which would eventually cause a collision. I believe since the robot head rotates perfectly in sync with the turntable that RoboDK is posting code with the rotary table and robot kinematically linked. This makes sense as I understand that kuka robots require any external axis to be kinematically linked in order to run simultaneously with the other 6 axis of a robot I do have them linked in RoboDK. Correct code should rotate the 7th axis while the robot rotates in the opposite direction (in relation to the linked kinematic system) so that in reality the robot stays in a relatively stationary orientation while the rotary table does all the rotating motion. Unfortunately something is not correct with the posted code in relation to the machine parameters and/or the CAMROB parameters on my KRC2 controller . I have the kinematic link set up correctly on my controller as I can rotate the table when I have base 17 called up and the robot moves perfectly oriented to the table as a kinematically linked base should. 


In addition to the above issue I have a few other related things I want to address.
1. I have been able to get base 17 to stay active when I run a program by editing the .src file to include "BaseDataNum = 17, $BASE=BASE_DATA[17] , $ACT_EX_AX= 17 and $ACT_BASE = 17. Even when base 17 stays active the robot still rotates into itself instead of staying in 1 orientation while the rotary table does most of the moving. This leads me to believe the EK(external kinematic) codes are not being called. I have read that if you call up an external kinematically linked base # (IE my base 17) that the EK codes are implied. I have also read posts that claim the opposite is true. Guess I need someone more knowledgeable on this to tell me what is correct.
2. If I add $BASE=EK(MACHINE_DEF[2].ROOT,MACHINE_DEF[2].MECH_TYPE,BASE_DATA[17]:{FRAME: X 0.000,Y 0.000,Z 140.000,A 0.000,B 0.000,C 0.000}) the kinematic link is activated but the machine gives me a "work envelope exceeded" error. I can verify the kinematic link is activated by jogging the rotary base after this code is called. When I jog the machine with this code called the robot stays in orientation with the rotary base. When I jog the rotary without this code the robot does not stay in orientation with the rotary base. It actually overrides the kinematic link until I manually call up base 17 again in the configure, set tool/base menu.
3. When I call up tool 2 with CAMROB inline forms the tool # defaults to tool 1 regardless of the tool # I have called once the .CSV file starts to run.

I have attached some sample code. A .src file that I have altered with the $base=EK command,  base 17 codes, and tool definition. Also added "CR_iUSER_PARAMS_VERSION = 2" to call up the newer version camrob parameter file. A csv file goes along with this but it is too large to attach. 

Could also share my camrob parameter files if anyone wants to look at them. They might give some insight into what formatting my robot expects the code to use. 

I have contacted RoboDK about this but they are not being particularly helpful. I'm hoping they will eventually help me with this but am reaching out everywhere I can to get some help with this ASAP. Getting pretty desperate to get this resolved. Having to cut everything indexed is ok but it would be so much faster with the rotary actively moving. Really hoping I wont have to resort to getting one of their competitors software packages. I really believe roboDK is capable of doing what I need it to do and I really want to believe in RoboDK. Just need someone with the expertise to make it happen. Actually I like roboDK a lot. Would be a great advocate for it if we can get it to work correctly with my entire setup.

 I am a machinist, not a python programmer. I am learning python in the hope that I can eventually understand everything that is going on in the post processor and edit it successfully myself but I'm not there yet. Tried chatGPT. It actually gave me functional post processors but they did not resolve my issues. I knew that was a long shot.

 It would be in roboDK's interest to get this to work. The company that made this robot cell "Robotic solutions" made hundreds of cells that use this configuration. At the moment everyone that has one would have to buy Eureka robot @ 18k$, robot master for 16,500$ or suffer through using powermill which comes with it but is absolutely a nightmare to use. They could sell a lot of licenses if they got this to work correctly.

Thank you for reading this! Hopefully some kind soul has the information I need and is willing to share it. You would be really helping me out!


Attached Files
.txt   Buddharotarytest1031_3src.txt (Size: 1.5 KB / Downloads: 7)
#2
We have a dedicated section in the documentation of RoboDK that explains how to configure external axes for KUKA robots:
https://robodk.com/doc/en/Robots-KUKA.ht...ADriverExt

In short, the KUKA BAS function does the trick of properly configuring the turntable or any external axes. You should be able to setup your system by calling the BAS function properly.
To better understand this behavior you can take a look at the BAS.src file and related config.dat and machine.dat files. Each controller can be setup in many different ways. The BAS function in the end sets the $BASE as an EK and you could this this in one line as well.

You can also customize the post processor to output the correct code for the configuration of your controller. You can check the many different options available in the post processor below and feel free to choose the option you like best.
Code:
# option 1: Build the kinematics based on the MACHINE_DEF array and the provided offset
#self.addline('$BASE = EK (MACHINE_DEF[2].ROOT, MACHINE_DEF[2].MECH_TYPE, { %s })' % self.pose_2_str(pose))

# option 2: Build the kinematics based on the EX_AX_DATA array and the provided offset
#self.addline('$BASE=EK(EX_AX_DATA[1].ROOT,EX_AX_DATA[1].EX_KIN, { %s })' % self.pose_2_str(pose))

# Option 3: Build the kinematics based on the EX_AX_DATA array and the pre-defined offset
#self.addline('; Using external axes')
#self.addline('; $BASE=EK(EX_AX_DATA[1].ROOT,EX_AX_DATA[1].EX_KIN,EX_AX_DATA[1].OFFSET)')
#self.addline('; $ACT_EX_AX= %i' % (self.nAxes - 6))

# Option 4: Use the BAS(#ex_BASE) init function from the BAS.src file
self.addline('; BASE_DATA[%i] = {FRAME: %s}' % (self.BASE_ID, self.pose_2_str(pose)))
self.addline('BAS(#ex_BASE,%i)' % self.BASE_ID)

# Option 5: Use the BAS(#BASE) init function from the BAS.src file
# self.addline('; BASE_DATA[%i] = {FRAME: %s}' % (self.BASE_ID, self.pose_2_str(pose)))
# self.addline('BAS (#BASE,%i)' % self.BASE_ID)

# Option 6: Directly take the base from the BASE_DATA array (usually what the BAS(#BASE) does)
# self.addline('$BASE=BASE_DATA[%i]' % self.BASE_ID)

Let us know if you still have issues. This is just a configuration setting that should be the same no matter what software you use.
  




Users browsing this thread:
1 Guest(s)