DTERR SRVO-068 G:1 A:3

    • New

    Got a SRVO-068 error, after looking over a few things and doing some investigating it seems that the M1P cable is damaged. As far as I'm aware the only fix for this is to replace the cable dressing throughout the robot. Trouble is that this happened while the arm was extended so it is far from being in the ideal place to replace anything but I can't seem to find a way to move the robot at all.


    Is there anything I am missing? Is there a way to move the robot into a better position for replacing the cable and is there a way to replace it without replacing the entire cable dressing? This is mostly a hail mary, I am expecting that I am probably stuck with having to make the swap with it extended like it is.

    • New

    It is not possible to solve this problem without changing the cable. You have already mentioned the subject, but I am definitely against trying these methods of "taking the brake in vain, suspending the robot with the help of a crane" while the cable failure is continuing. It has happened to me many times that when the cable is faulty, moving the robot leads to a much bigger malfunction. I'm writing this as someone who damaged the driver card or CPU card. If there is a break in the cable, it may not be a problem, but if there is a short circuit, your failure may become impossible. I don't think anything mechanical is removable either, and wherever you need to disassemble to replace the cable, whichever closed cabinet you need to disassemble, I think just disassemble it.

    • New

    That makes sense, my biggest concern with replacing the cable system is that the maintenance manual says to do so while in zero position and I worry that by changing cables in a different position something unexpected might happen. Might just be paranoia but as much as possible I like to do things by the book so I can more securely anticipate the result.


    Definitely will take into account your advice though, I certainly don't want to make anything worse by forcing a move.

    • New

    Batteries were freshly changed a month ago. TP cord? I was talking about the cable running to the pulse coder itself, there is visible damage to it. I hadn't considered the TP cable at all but thats an easy swap to try just in case.

    • New

    Worth a shot is usually gives a different code! But if you have it on hand might as well.

    Then do these steps

    Press the [MENU] key.
    2 Press [0 NEXT] and select [6 SYSTEM].
    3 Press F1 ([TYPE]), and select [Master/Cal] from the menu.
    4 Press F3 ([RES_PCA]), then press F4 ([YES]).
    5 Cycle power of the controller.

    • New

    I'm not sure why that worked but it did. I taped up the visible damage figuring it may be more superficial than previously thought, swapped the teach pendant cable and it all worked like nothing had happened, I'm honestly shocked

    • New

    Is it typical to need to remaster or anything after RES_PCA? My TCP seems off and I'm not sure if it was off before and I just wasn't paying close enough attention or if this fix requires any reteaching or remastering after.

    • New
    Quote from EPeters1

    Is it typical to need to remaster or anything after RES_PCA? My TCP seems off and I'm not sure if it was off before and I just wasn't paying close enough attention or if this fix requires any reteaching or remastering after.

    No, you will not need to remaster the robot.


    Your robot will not run in auto, or jog in any coordinate system other than joint, if it is not successfully mastered.


    If you try to run in auto or jog other than in joint mode, a MOTN-117 ROBOT NOT MASTERED alarm will be generated which will prevent the robot from moving.

    • New

    It is possible to move a robot in this situation by disabling the axis affected $SCR_GRP.$AXISORDER. Remove the assigned number replace it with a zero and reboot the controller.


    However it is important to disconect the brake cable at the motor for whichever axis you disable.


    Brake power will be applied to all brakes when robot is commanded to move.

    • New
    Quote from ROBOT_G

    It is possible to move a robot in this situation by disabling the axis affected $SCR_GRP.$AXISORDER. Remove the assigned number replace it with a zero and reboot the controller.


    However it is important to disconect the brake cable at the motor for whichever axis you disable.


    Brake power will be applied to all brakes when robot is commanded to move.

    Aren't all axis brakes power off style brakes - hence the robot stopping in a sudden power cut? Removing brake power would cause the axis to lock.

    • New
    Quote from wolf95

    Aren't all axis brakes power off style brakes - hence the robot stopping in a sudden power cut? Removing brake power would cause the axis to lock.

    Yes, but the robot will drive through a brake in an emergency maintenance situation much more gracefully than compared to falling flat on it's face with no servo power AND no brakes. 8o

    • New
    Quote from pdl

    Yes, but the robot will drive through a brake in an emergency maintenance situation much more gracefully than compared to falling flat on it's face with no servo power AND no brakes. 8o

    Ah, I see what you mean, good point. I was thinking of the one scenario I needed to get the dead axis to move and was unable to under servo power. Didn't think of it from the dropping the arm when powered back up perspective haha.

    • New

    The issue with a disabled motor is you can't disable the brake power. By disconnecting the brake power you ensure the brake won't release. The servo amp will not send power to a disabled motor. So a disabled motor with brake power will free fall.

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