Posts by KonstantinosP

  • Backlash Determination

    Hello Uberdoom
    I followed SkyeFire's advice. Think of the robot stretched out vertical. Then I used incremental angle jogging at the minimum step. That takes care that little movement cushion that you mentioned. For A1,A2,A4,A5 and A6 you can can still put those axis in the mastering position while the arm fully stretched, and actually use the mastering dial and see the response in the change of direction from the movement of the needle. A3 is a bit tricky.

  • KRC4 Smart Pad strange behavior

    Hello everybody.

    Robot KR120 R 2500 Pro
    Controller KRC4, KSS v 8.3.12
    Smart Pad v 8.3.17

    I was wondering if anyone ran into this problem before.

    For no apparent reason, the jog keys and the keys for setting the jog and program override, once pressed they bring up the Main Menu or they select a program or they open a file, completely randomly. We cannot move the robot using them, or change jog speed. Other than that, if we use the space mouse instead, everything functions normally.

    Any ideas what might have caused it and how we could go about fixing it?

    Many thanks in advance.

  • Absolute accuracy package

    vvelikov:

    I hired last year RoboDK (http://www.robodk.com/) to come and calibrate with Creaform Stereoscopic cameras my robots. I can tell you with all honesty my KRC4 robot is now in the range of 0.150mm of positional accuracy, and my older KRC2 robots consistently less than 0.5mm. I would never use a robot again for highly detailed milling if not being calibrated and error compensated.

    Great people to work with, awesome products that truly work, they will listen to your problem and will give you the right solution that you need for professional use.

    PM me if you need more info.

  • Normalizing speed along path

    Marco:

    I think we all had similar issues with the robot dropping the feed rate while entering parts of the path very dense in points. I believe your problem is more pronounced in roughing, especially if your strategy involves mainly straight paths and only some areas, probably around the part, where the path is curved and the density of points very high. If you planned your feed rate for the entire program based on how fast the robot moves over long straight lines with only two points basically defining the two end points, then it comes without surprise that it becomes painfully slow around tight curves and dense in points areas.
    One solution would be to plan your speed based on the slowest areas instead. Try the following test. Generate a Toolpath with two straight lines, both 1000mm long. The one it only consists in two end points. On the other line space out points as near as the tolerance of your tool set in CAM. So if say your tool is set at 0.1mm tolerance then put on a 1000mm line 10000 points 0.1mm apart. (By the way, if you are milling large scale with soft materials and large tools, 0.1mm is a ridiculous number to set your tool tolerance by, but I put it as a worst case scenario).
    Run the two lines at the same feed rate with a timer. See how much the speed drops. Divide the min into the max and this is your scaling factor for adjusting your rates in your program.
    Clearly now the problem transfers from the slow areas to the fast areas that now become extremely fast. If you now read again my previous post to your question, it will probably make more sense and you can get an idea of how to deal with it. Once more, the idea is to keep your paths everywhere (reasonably)dense in points so the robot will never have the chance to move as fast as it can, and program your speed as we said based on its speed through the slowest areas but adjusted upwards using the scaling factor found as said.
    Of course that would result in a much heavier file but your feed will become much more consistent.
    The added benefit of having paths with consistent high density in points is the following: it will enhance path accuracy if you ever decide to calibrate your robot for positional accuracy with companies as Dynalog or RoboDK. If you have an error compensation filter that can take the robot safely with accuracy on two subsequent points, unfortunately if they are way apart the one from the other, nothing can assure you that the robot will travel on a dead straight and positionally accurate path whereas if the path is dense in points, then all these points have already been filtered and error-compensated, hence you travel on a straight line.
    I hope that makes some sense.

  • Normalizing speed along path

    SkyeFire:

    I looked up the $FILTER system variable. Would you be able to elaborate a bit on the effect of choosing a certain value from the range of integers 0-16, and how the magnitude of that value would affect acceleration versus some other smaller or larger value?

    Many thanks in advance.

  • Normalizing speed along path

    Marco,
    You can deal with this problem in a number of ways. A very basic way could be a script that would parse your code and estimate the distance between subsequent points and when it encounters a length greater than X then divide that distance into smaller line segments by inserting a number of equidistant, colinear points(LIN commands)set by you. That forces the robot to go through dense in points areas all the time and maintain a more or less consistent speed. More sophisticated scripts could adjust speeds and acceleration on a per-point almost level where needed, considering again changes in length between two points.
    A more practical way is to choose for roughing especially, contour milling strategy. Never worked with Sprutcam but I am sure they have it. Contour roughing will output for the most part curves (hence dense in points)that they are offsets of the intersection curves of a plane with the geometry of the part. If there is an area in your part that is planar then it will output straight lines again as a contour but you can trick it by placing only for the roughing a dummy surface geometry with a slight convexity( not more than a mm) right on top of that area which will brake the linearity of the contours and get you curves again instead of lines. This method will give you a much more consistece in speed Toolpath but at the cost of very large files.
    I hope you found this a bit useful.

  • Backlash Determination

    Hello Everybody,

    One of our oldest robots, a KRC2 KR210 recently started loosing it's crispness of movement.
    I believe that backlash has gotten worse in one or some of the gearboxes, but I can't determine with certainty where the problem is.
    Is there a method that anyone here would recommend me following in order to correctly determine backlash?
    Many thanks in advance.

  • Importing PID file from RDC card, KRC2 ed05

    Hello,

    We just acquired a KR210 2000 series robot. We only needed the mechanical part, we are just replacing an existing KR210, same exact TRAFO as the replacement arm. The only difference is that the new one is a medical robot and the label Absolutvermessen indicates that it must have been an Absolute Accuracy robot.
    Our controller is KRC2 ed05 KSS v5.6.12
    Once we connected the new arm to the old controller, we enabled in the Options.dat file the absolute accuracy option by changing the Boolean variable $ABS_ACCUR from FALSE to TRUE and the under Robot Data, we chose to accept the data on the RDC instead of the HD and once we corrected the serial # we selected Import PID and applied everything and exited that window. We rebooted with cold start but we got an error saying that the PID file was not found. We checked in the folder IR_SPEC for the <robot_serial>.pid file but we only found a <robot_serial>.cal from that same robot.

    Did we make an error somewhere in the process?
    If the .pid file exists in the RDC card shouldn't be imported along with the .cal file?
    Is there a different way that we could go about retrieving the pid file from the RDC card?
    We know that we can try KUKA and see if they still have it in file but for our own education I would appreciate if someone could point us in the right direction so we know how that also works.

    many thanks.

  • KRC2 to KRC2ed2005

    I did this upgrade with my older KRC2 KR210 robot. I only had to send KUKA a copy of my archive and they configured the new unit for me. It's a simple as you stated it. Apart from a small issue with a bad connection that in the end was successfully located and fixed, it was as simple as swapping PC's.

  • KRC 2 ed05 upgrade failing.

    Quote from the leg


    You can not install Ed 05 in to a none ed05 cabinet the esc and wiring will not be correct
    And you will get errors

    When installing the software at around 10% it is looking at hardware

    The Leg, this statements is incorrect. The problem was a bad connection in the MFC card, KUKA USA fixed it. The controller now works perfectly fine and has not compatibility issues with the rest of the cabinet or the robot. It is actually a very common upgrade, so common that KUKA made me wait 5 months before my turn came to get a hold of a new PC due to rapid increase in similar requests from people wanting to swap the old PC's with new Ed05 before they get discontinued end of this year.

Advertising from our partners