Robot Drifts Offf Position

    Ok, so we have a MA2010 with a DX200 controller used for a welding application. Our job coordinates are set by robomove and rhino software. We set the table or fixture coordinates correctly, as well as the TCP. Our issue is that when welding, the path drifts further and further away from where the scan is telling it to weld. This robot has been doing the same jobs for the past 6 years with no issues. Nothing has changed, but yet the robot position still drifts. When I drive the robot to zero position, all witness marks line up perfectly so we are not losing anything on our axes. Does anyone know what could cause this issue? I'm at a loss.

    Not familiar with what a robomove and rhino software are. Sounds like there is something that is feeding the robot information to direct its path. Is the thing scanning defective, been moved, or mounting loosened up?

    I know a thing or two, because I’ve seen a thing or two. Don't even ask about a third thing. I won't know it.

    Ok, so we have forging dies that are repaired by a weld robot when they are damaged. Basically, a person gouges out bad spots in the die, then places the die in a fixture and a scanning head scans the die. It then compares the scan to the actual CAD drawing of the die, and establishes a path and coordinates through the software somehow. It is second hand software that someone jailbroke and modified, then sold to our company. I am the robotics engineeringg tech and I am trying to explain that the robot is going to the exact coordinates it is being told to go, and that the problem isn't with the robot itself, but they just aren't listening to me. I've come to the conclusion that there is either an issue with their software, or their setup procedure for their dies.

    Quote from 95devils

    Not familiar with what a robomove and rhino software are. Sounds like there is something that is feeding the robot information to direct its path. Is the thing scanning defective, been moved, or mounting loosened up?

    Or the scanner of the "good part" is not so good.

    Definitely the robot gets wrong data. Only things is ro find out if the error is being made in software or hardware, or part used as the perfect part.

    I'm sure you've done this, but - run another job generated by the software (ideally one you know works), and run a job programmed on the bot exclusively. That should tell you where the problem seems to be.

    If it's the software, check the frame your jbi code says you're working in on the robot and make sure it's where you want it to be; if it's a userframe, try re-teaching it. If it's a robot or base frame, recalibrate the manipulator and see if that helps.

    If it's the software (believe me, I know what that can be like) and it's under a license, your only "legitimate" fix is to get ahold of support and be at their mercy. That said, if they're not helping enough and you're comfortable fiddling around in the language that the libraries its using are in, then the sky is the limit.

    But it could just be a setting in the software's configuration somewhere, so first, go over all your settings and make sure everything is aligned with your cell - that's the main drawback to OLP; if the robot cell and your virtual cell are out of phase even slightly, then... yeah.

    If you are using COMARC at all for your welds, let me know - COMARC drastically deviating was a major problem for us but we solved it; I won't waste anyone's time explaining that though unless it applies to this situation. Let me know.

    Quote from WhyDoesMyRobotHateMe

    I'm sure you've done this, but - run another job generated by the software (ideally one you know works), and run a job programmed on the bot exclusively. That should tell you where the problem seems to be.

    I would totally have tried that if it were possible. However, every program we run is generated by the software, and they were all off. On the bright side, I found and resolved the issue. I found that after reteaching the home position after a motor was changed, the software was not set up to properly reconfigure to new tool frame positions. I added a 10mm offset to the tool frame and "Voila" issue resolved!

Advertising from our partners