[sculptyourbrain]

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!

[Albert]

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.

[sculptyourbrain]

Albert,

Thank you for your reply. If I am reading this correctly, any of the options above would work regardless of the way my controller is set up? One only has to enter the correct entries into the code?

So I have tried "$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})". I believe this is option 1 formatting. I was trying to set the program 140mm above the rotary table root point. Copied this code from some sample code I found online. Not sure it is correct by any means.

I set up the external kinematic system with the Kuka axis configurator on my krc2 controller. I believe it is set up correctly as when I select base 17 with the correct tool definition for the tool I have in the spindle, the robot stays perfectly in orientation with the external axis when it is rotated.

So my external kinematic linked base is #17
the position of that base is (x 2038.9, y 3.23, z 88.3, A 0.0, B 0.0, C 0.0) in relation to the robot base.
I believe MACHINE_DEF[].ROOT should always be [2] for external axis?
I have the external kinematically linked base set as "EASYS' in '$EX_KIN" in ET 1 of Ext. kinematics tab of axis configurator. I believe that needs to be inserted into the BAS function definition but not certain where. I have played with it with no good results.
Configured "$ET#_AX" as E1 In Ext. kinematics tab of axis configurator.

I can give you the base.src or config.dat file from my controller if that might be helpful.

Thank you for your assistance!

[Albert]

Thank you for your reply. If I am reading this correctly, any of the options above would work regardless of the way my controller is set up? One only has to enter the correct entries into the code?

That's correct. Only one of the 6 options provided should be implemented.

The indexes you use highgly depend on the BAS.src, machine.dat and config.dat files. You can find these files here:

• KRC\R1\System\$config.dat
  
• KRC\R1\System\bas.src
  
• KRC\R1\Mada\$machine.dat
  

If you can share these files we may be able to help you better.

You can find more information here:
https://robodk.com/forum/Thread-How-to-c...2#pid13742

[sculptyourbrain]

Albert,

Great, thank you for confirming that. 

I have attached my machine.dat and bas.src files. Config.dat is too large to attach here. Can I send it to you some other way? 

Really appreciate you looking at this for me!

[Albert]

The first function you can find in the BAS.src file is the BAS function, and you are currently using the base definition as if you didn't have any external axes like this:

Code:

BAS(#BASE,0)

Instead, since you have external axes, I believe you should do something like this:

Code:

BASE_DATA[5] = {your offset from the turntable root point}
BAS(#EX_BASE,5)

Here the second index is the base number used and the machine index is hardcoded to 0. You should take a look at the MACHINE_DEF index 0 to see how it is built and get a better hint to double check if it is the correct index. There may be multiple machine.dat files in the controller. Did you provide the correct one?

Who installed your system? Did they provide any sample programs to move the turntable in synchronization with the robot?

[sculptyourbrain]

Albert,

I tried the BAS function within my test .src code as you suggested. It gives me the error "array index inadmissible". I tried it exactly as you suggested and also as follows.

BASE_DATA[17] = {FRAME: X 0, Y 0, Z 0, A 0, B 0, C 0}
BAS(#EX_BASE,17)

Am I entering this correctly and In the correct place? Is this something I need to alter in the post processor or machine config files?

Just to be sure, I looked on our controller. I only see 1 machine.dat file on the controller in KRC/R1/MADA. Copied that exact file from the controller and attached it to this message along with the bas.src file from KRC/R1/System.

We bought this system second hand from an auction website. The OEM is Robotic Solutions inc. We actually had them come out and show me how to set the machine up. Cost us almost 9k$ to have them come out. The problem with them unfortunately is that they exclusively sell Eureka robot simulator and wont give me any assistance with code or machine parameters unless I buy that software. They wont even give me any sample code. I asked them but they tried really hard to get me to believe RoboDK is incapable of synchronized external axis output and refused to give me any viable code to troubleshoot with.

 We also had another guy come out. A good KUKA tech but he is a robotmaster retailer. Same story with him. Since he sells robotmaster his main objective is to try to sell me robotmaster. He also attempted to convince me that roboDK is incapable of synchronized external axis output. Im certain neither RSI or the other tech we used are knowledgeable enough with RoboDK to give me an informed opinion, much less an unbiased one since they both sell more expensive competing software packages. Unfortunately the people who had this system before us cleaned up after themselves too well and there are no remaining programs on the controller that involve the rotary table. 

I found a couple of threads where others were experiencing the same issue, or a very similar issue at least as I am.

https://robodk.com/forum/Thread-Problems...-KUKA-KCR2
https://www.robot-forum.com/robotforum/t...functions/

You may be able to decode what the solution was from these posts. Neither of these threads involve CAMROB, so I am not sure if they translate to my setup but its worth taking a look at.

Again, thank you for your assistance!