maximum point density for KRC2

  • Hi All,


    I have a KRC2 (see details below) and use it for printing. This works fine in general, but with high point densities the robot will choke/stutter (don't know the right term) and does not move continuously. This is also the case with points in a straight line, so maximum acceleration limits should not be the problem. Knowing the limits of the robot (spatial point density and speed) would enable me to check the toolpath before the start of the print. I have searched for a system variable that indicates the 'overload' situation but could not find it, neither could I find intricate details about the path planning.

    Anyone can put me on the right track? Any help is highly appreciated.


    My setup:

    Controller: KRC2, WinXP, 256MB RAM, Software version 5.6.8

    Manipulator: KR210-2000

  • Place your Ad here!
  • Depending on how the robot is programmed the answers differs. what type of movements are used in the program PTP, LIN ,Spline? If i would have to guess it would be LIN.


    Then the second question are you using approximate motions? like C_DIS and C_VEL. if yes which one and what are the settings $apo.CVEL and $apo.CDIS.


    Could you post a (part of) program?

    Every problem has a solution, that isn't the problem. The problem is the solution.

  • Point density is not a fixed limit, but in general any point spacing under a few mm is probably going to be problematic. The motion planner only looks up to five motions ahead (3 by default), so a series of points too closely spaced probably prevents the planner from generating smooth motion approximation on the fly.


    With KSS 5.6, the SPLINE type motion is available. Spline blocks are pre-"compiled", so might be more amenable to higher point densities. However, Splines have strict rules about accel/decel and avoiding really sharp corners, so you might have to test this for suitability.

  • At the moment I cannot access the controller. What I do know: $advance = 3,$apo.CDIS = 1 (what will the pathplanner do if the next point is within the cdis radius?), and $apo.CVEL is default, i.e. not overridden in the program.

    I will post a copy of the motion program as soon as I have access.

  • The problem is really the number of points too close together. Can you check the program you are using to generate the positions whether a kind of data reduction is available.

    We agree on that. And data reduction is possible in many cases. I would like to know if the is a hard constraint (like a maximum number of points per second) so I can 1) assess the need for data reduction beforehand, or 2) program a reduced speed in point-dense areas.

  • Point density is not a fixed limit, but in general any point spacing under a few mm is probably going to be problematic. The motion planner only looks up to five motions ahead (3 by default), so a series of points too closely spaced probably prevents the planner from generating smooth motion approximation on the fly.


    With KSS 5.6, the SPLINE type motion is available. Spline blocks are pre-"compiled", so might be more amenable to higher point densities. However, Splines have strict rules about accel/decel and avoiding really sharp corners, so you might have to test this for suitability.

    I hoped for a fixed limit. So increasing $advance to 5 might improve the capacity to handle close points?

    What I do not understand is what limits the path planner to generate smooth motion. Is it cycle time of the controller program? Should the points ahead cover at least a minimum distance?


    I did not know SPLINE motions so will research that.

    Are you aware of a system variable that I can use to objectively determine an overload situation?

  • We agree on that. And data reduction is possible in many cases. I would like to know if the is a hard constraint (like a maximum number of points per second) so I can 1) assess the need for data reduction beforehand, or 2) program a reduced speed in point-dense areas

    No there is not. In blending you can not get faster as programmed by the two moves you want to blend over. Also you always have to be able to stop at the intersection point if blending is not possible. The reachable velocity therefore is mostly determined by the accelaration for short distance LINs. If distance of LIN is short you no longer get a trapezoidal velocity profile (having a constant velocity phase) but a triangle shaped one connecting maximal acceleration to maximal deceleration. Obviously you also want to keep blending velocity as high as possible, i.e. blending should not start when you are already in the deceleration phase (which is probably what you are experiencing). This is achieved best with using C_VEL instead of C_DIS blending. C_VEL basically tells the system to choose blending radius such that velocity does not need to be reduced. Also blending is automatically reduced by the system to half point distance no matter what you programmed as blending radius.


    Fubini

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