Dynamic base offset changing

  • Hi,


    I started (not long time ago) my adventure with kuka.


    Actually im waiting for KRC4 Compact 8.3.43.


    Im not sure about Kuka possibilities.


    I will have moving conveyor. I want to send distance (in mm) from PLC to KUKA, and change BASE offset.



    Will be this, written in SPS:

    Code
    $BASE_DATA[1].Y = $BASE_DATA[1].Y + $IN[Distance]

    enough for dynamic movement? In other words, will robot be capable to calculate new movements in time?


    I want to do same path of paint injection with diffrent conveyor speed.

    Regards Adam

  • Place your Ad here!
  • No. Standard motions are pre-planned. As such, once a motion has been loaded in the Advance Run, changing the Tool or Base data has no effect on that motion.


    You need the ConveyorTech option from KUKA, at minimum.

  • That might kind of work, but probably not well enough to follow a moving conveyor. Basically, the motion is loaded into the path planner when the Advance Run Pointer reaches that motion command. This is typically 3 motions ahead -- in your example, PTP P3 would be "loaded" when PTP P1 motion physically begins.


    Non-motion commands in between motion commands are executed "on the fly" as the ARP passes over them, except for commands that break the ARP: setting outputs, WAIT commands of any kind, etc. The KUKA programming manual has an entire section on this. Which means that the value of $IN[Distance] at the moment PTP P1 begins executing will be what is loaded into PTP P3.


    Your example also lacks approximation -- as written, the robot will come to a very brief halt at each position. You would need to add a C_PTP or C_DIS tag to each motion command to get the robot to "flow" through these motions continuously. And to make those tags work, you'll need to set your $APO variables correctly.

  • Thx for second answer. I delete previous message (with code below) becouse i found your post from 3 years ago. (" The diffrence between main run and advance run")


    I think at first i will try this. Painting spray positions have good deviation and maybe it will be enough.


    Becouse at this moment im not sure about how much this bonus option cost and if it will be working with data from PLC

    Code
    $BASE_DATA[1].Y = $BASE_DATA[1].Y + $IN[Distance]
    PTP1
    $BASE_DATA[1].Y = $BASE_DATA[1].Y + $IN[Distance]
    LIN2
    $BASE_DATA[1].Y = $BASE_DATA[1].Y + $IN[Distance]
    PTP3
  • Apart from advance pointer making any changes irrelevant (at that moment) for the preplanned motions, the controller can't execute any commands that have any influence on robot kinematics by non-robot interpreter. E.g. no lin, ptp motions, active base or tool changes.


    If the conveyor speed is constant or can be measured/calculated, then do you really need a rapid adaptation by the robot?

  • Apart from advance pointer making any changes irrelevant (at that moment) for the preplanned motions, the controller can't execute any commands that have any influence on robot kinematics by non-robot interpreter. E.g. no lin, ptp motions, active base or tool changes.

    Im not sure what u mean. But I used to modify points frames etc with input signals from PLC and it always work (e.g cognex making photo and doing offset for frame to tighten screw)


    It is constant for one ride, but when cycle will end someone can change speed ( max will be 150mm/s, and avaible speed will be for e.g only 10/30/50/100/150mm/s).


    I was thinking about changing speed (OV value ) or make structure where in BAS setup speed will be INPUT value. But for now i think changing frame offset is easiest way. ( for now i cant think about other solution, except KUKA ConveyorTech, as SkyFire said.)

  • Of course you can change frames that are used later to calculate kinematics- that doesn't change what the robot is currently doing, only what it will.


    If the speed is constant (even if only for one cycle) and you know the coordinates of the target, then instead of base you can just change trajectory. It would mean keeping the trajectory in pos arrays which won't work well if the poses have to be taught manually.

  • Hi again,


    one more time Im not sure about one thing ,and Im searching for solution


    I want to know predictor of linear speed with robot $OV_PRO.

    For example:


    - I got linear move with 2m/s ( 100% in pendant).

    - I change OV_PRO to 50%

    Now robot will move with 1m/s?


    I must teach points for conveyor with is moving 150mm/s . But during testing i want to reduce that speed ( for safety purposes)

  • $OV_PRO is just program execution override. Always assume it is at max since operator can set it as such at any time.


    This is just one of several multipliers that may be applied at any given moment. One of others is T1 reduction which is some 10% or so. Then there is a safety controller speed limit, programmed speed etc.


    The only one you should consider to set by program is the last one - programmed speed (hence the name). Using and abusing of others such as $OV_PRO is a bad practice and usually is a sign of desperation.


    Just stick to using things as they are meant to be used and keep the hacks for desperate times, when you really really really see no other way out.


    To teach points, you must use T1 mode because that is the only mode that allows jogging. And in T1 mode speed is already limited.


    Also for tracking conveyor you want to maximize robot speed so robot can catch up to moving products.

    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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners