How to turn a turntable continuously at a set velocity

    Hey, I am working with a KRC4 and it has a small turn table in front of it.

    I am trying to write a program that just has the robot stay in place while rotating the turn table continuously so the tool is relatively moving at a set velocity.

    This is a simplified version of the program. The robot does move the turn table without the arm moving, but the turn table slows down to almost a stop between each motion.

    I have tried setting velocity in the loop (which doesn't make sense) and the turn tables just moves very very slowly after the first move.

    I'm not sure what I need to do to get the turn table to keep going at the set speed as it moves through each position.

    I tried re-writing the program and it still has the same behavior; the robot pauses at the end of each move.

    I have tried adding and changing $APO.CDIS and $ACC.CP but it doesn't seem to change anything.

    You use base 0, so the turntable is not integrated into transformation.

    Using Lin doesn't make sense in that case (doesn't make sense if turntable is integrated). Look at the xyz coordinates uduring motion, you will see that the cartesian coordinates don't change. So the linear velocity doesn't make sense as the turntable should move from one point to the other in 0 seconds. That's impossible and errors are prevented by Kuka system software, it limits the velocity of the turntable.

    You should use ptp movements, or integrate turntable in transformation and use circ movements.

    SkyeFire

    1. KS V8.5.465_HF3

    2. The turntable is typically configured to be the base coordinate system. It works this way when running our typical programs. I am using Base 0 so I can just tell E1 to move without updating the position's XYZ values. I could put in in our normal base, but then I would have to specify XYZ and A with E1 to keep the tool in the same position. Also, the turn table seems to be configured so that a LIN move is more like an Arc. I am not sure how this was setup, but the LIN moves in the program do not move the arm, so if a pen was attached to the tool it would draw an arc on the turn table.

    3. I am using LIN because it actually makes arcs, I could use PTP, but I want to specify the relative velocity at the TCP instead of a percentage of the max rotation speed.

    4. I will try C_VEL. I haven't used this before. I will also try a PTP move to see if it also pauses.


    hermann I am using Base 0 so that the turntable transformations are not taken into consideration. Our other base numbers have the base transformed to the turntable and moving with it, so I would have to specify XYZA and E1 to keep the tool in a fixed location as the turntable rotates (which is how my typical programs run). You do make a good point that the velocity of the LIN move doesn't make sense if I am using Base[0] because the tool doesn't have a calculated relative movement. I will look into this more. It seems like this would be an issue with the velocity, but it shouldn't cause the turntable to pause after each motion (I don't think).

    Quote from mjnewsum

    2. The turntable is typically configured to be the base coordinate system. It works this way when running our typical programs. I am using Base 0 so I can just tell E1 to move without updating the position's XYZ values. I could put in in our normal base, but then I would have to specify XYZ and A with E1 to keep the tool in the same position. Also, the turn table seems to be configured so that a LIN move is more like an Arc. I am not sure how this was setup, but the LIN moves in the program do not move the arm, so if a pen was attached to the tool it would draw an arc on the turn table.

    That sounds like the E1 axis is kinematically integrated, such that it has a particular Base that moves with the turntable. If that's the case, then you may need to bite the bullet and do the full XYZABC + E1 math.

    Assuming your E1 Base is at the dead center of the table (and E1 is set as Rotary or Endless), you might be able to use a series of CIRC commands. Alternatively, you might be able to use the attached ellipse generator to create a series of LIN points on a circle for the TCP, and add in the E1 values to keep the TCP physically stationary while it moves "virtually" relative to the E1 Base.

    SkyeFire, thanks for following up. I am about to go play around with the bot some more to see if I can get it to behave. I think you are right that CIRC moves might be the easiest way to go. I can probably just make each rotation in 2 moves by Negating X and Y, adding 180 to A, and 180 to E1.

    I guess I could LIN to a E6Axis position, with only the E1 changed.... I think. This should even work in our typical base.

    I am still surprised that the robot pauses. I could understand it it was moving the wrong speed, but the pause is still strange to me.

    Also, thank you for the generator program. I will keep this as a backup plan.

    Edited once, last by mjnewsum (January 11, 2023 at 6:53 PM).

    SkyeFire I modified the program to use PTP. The turntable did not pause, but I seem to have almost no control of the rotation speed. The turn tables moves very slowly no matter what I set in PDAT_ACT.

    I did notice a very strange behavior in this program. If I Block Select the PDAT_ACT line, the turn table would turn much faster (I am assuming this is the speed I set). The turntable would turn at the faster speed for one move then go back to a painfully slow speed that it would normally go if I did not block select the PDAT_ACT line. Not sure what is going on there.

    The first move after doing a Block Select is a BCO move (basically, the Advance pointer has been wiped and all path planning has been deleted), and often moves faster than any moves after BCO has been achieved.

    Setting PDAT_ACT and FDAT_ACT have no effect on anything unless you run BAS. BAS copies those variables into the various System Variables like $VEL_PTP, VEL_CP, etc, which actually control motion. PDAT and FDAT are just "helper" variables at the user level, added by KUKA to support Inline Form programming.

    In this case, you should run BAS(#PTP_DAT) to activate your PDAT/FDAT settings. #PTP_PARAMS tells BAS to set the parameters for PTP motion (#CP_PARAMS would be used for LIN or CIRC motion).

    Thanks for explaining that @skyfire. Is there any way to set the PTP velocity to be relative to where the TCP is located?

    I was trying to think through another idea of just having the pose as an E6Axis type.

    pose = $AXIS_ACT

    While true

    pose.E1 = pose.E1 + 90

    ; convert E6Axis to E6Pos position using tool and base

    LIN position

    EndWhile

    I am not sure how to convert an E6Axis to an E6Pos. Is that possible?

    Edit - I looked into it more and I think the Forward function should get me the E6POS I am looking for. Trying this next.

    Edited once, last by mjnewsum (January 11, 2023 at 8:44 PM).

    Ok, so I tried converting E6Axis to E6Pos, and that motion works well. The robot goes where I want it to.
    But, the robot still pauses at every position. I am not using our typical base. I don't understand why the robot keeps pausing.

    I realized I forgot C_DIS after LIN position. Tried that and it didn't change anything. I also tried C_VEL.

    I also tried adding $APO settings, but that didn't do anything either.

    $APO.CDIS = 10.0

    $APO.CVEL = 100

    I am really stumped. I can't figure out why it pauses between each move. It is like $Advance is not actually being read or something.

    Those lines simply define limits. That is not enough...

    Line 23 also need to be told that approximated motion path is needed and what types of approximation motion planner is to consider.

    LIN Position C_DIS

    or

    LIN Position C_DIS C_VEL

    without something of that kind there will be momentary stop at the end of motion.

    Also $ADVANCE need to be greater than 0. Line 8 will set that to default value which is 3 unless someone changed it.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from mjnewsum

    ... I am using LIN because it actually makes arcs, I could use PTP, but I want to specify the relative velocity at the TCP instead of a percentage of the max rotation speed...

    You can't specify the linear velocity without having the table integrated as base. It's impossible.

    Already told you in my first post: the cartesian position in your program stays fix, so the robot has to move zero mm with the linear speed of, let's say 0.2m/s, but for moving zero mm he needs exact zero seconds, so mathematically he is doing the movement with velocity 0.0/0.0 m/s. I'm not aware of what the path planner does in that case with the axis E1 and blending.

    It's a singularity, they have to handle it in a way that it's working mechanically, but for us as users the behavior is nearly unpredictable.

    You must go the hard way, described by Skyefire. Don't waste your time with ptp, or movements without integrated base coordinates.

    You can't evaluate the speed in T1, you have to use T2 or auto. In T1 the robot makes strange things with the speed.

    Ok, I figured out the issue. I was not using BAS(#FRAMES ) and I guess there is something in Frames ( ) that was required to the motion to work correctly in the moving frame of the turntable.

    Here's what I had to do.

    Code
    BAS (#INITMOV, 0)
ROBOT_FRAME.TOOL_NO = tool
ROBOT_FRAME.BASE_NO = base
FDAT_ACT = ROBOT_FRAME
BAS (#FRAMES )

    Thank you all for the help! This was a very confusing little problem. This was the first time I am making a program from scratch that runs on a robot using a turntable as the coordinate system. I'm not sure what in Frames ( ) made the difference, but I will use the BAS functions more in the future.

    hermann You are totally correct. The last program I posed is using Base[2] which is the integrated base of the turntable. Instead of calculating where the points will be or figuring out the ABC angles, I used an FK E6AXIS pose as the variable that I could modify E1. Then, I used Forward() to get the E6POS position of that pose. Then I can LIN to the position. That way, I get everything other that E1 calculated by the controller (XYZABC). I think it is a nice way to do it. This will let me put the tool in any position and any orientation and still drive the turntable at a set velocity relative to the current tool position.

    Edited 2 times, last by mjnewsum (January 12, 2023 at 6:15 PM).

    If you are satisfied with the movement now it will be ok. But something must be wrong anyway.

    You create a movement where only the external axis moves, the robot should stand still. The two coordinates are 90 degrees away from each other on the turntable.

    You program a linear movement between those two positions.

    If the integration of the external axis is correct, the tcp should move on a straight line on the turntable. When you attach a pencil on the tcp you should see a straight line on the table, as you programmed a linear movement.

    But when the robot stands still and only the turntable moves, you will get a arc with the pencil.

    So I think something is going wrong.

    hermann that is correct. After getting the turntable integrated correctly into the motion, it did move the arm in and out along the motion. I put in a variable to control the angle that is added to E1 each loop. Right now it is running with 1 degree, but that could be an issue if the robot is very close to the center of the table. I wanted to do this with CIRC moves, but was advised to avoid them without a good reason why. I think lots of people just have had bad experiences with CIRC moves so they linearize the arc at some resolution.

Advertising from our partners