DTERR SRVO-068 G:1 A:3

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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. :winking_face_with_tongue:

    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.

    We have an M10-iA with an R-30iB control cabinet, E-61257, which we purchased second-hand, and we need help clearing the SRVO-068 error code. The robot and the cabinet have been without power and batteries. Today, we installed new batteries and performed a quickmaster.

    It is connected to the power grid via a European plug for 400 volts because we are only testing it for now.
    We have tried switching the phases without any success.

    During startup professional programmers have assisted us but we still have an error code that we nore programmers can clear.
    We have not been able to jog the robot at all due to various error codes.

    There is a possibility that something might have happened during transport,

    We have the SRVO-068 DTERR alarm (grp:1 Ax:4) , which we have not been able to resolve and need your help with.

    • We see no visible damage to the cables
    • We have performed several types of resets and restarts in consultation with the programmers

    We tested moving the M4P connector from pulse encoder 4 and connecting it to pulse encoder 3.
    After that, the error codes changed to SRVO-068 DTERR alarm (grp:1 Ax:3) and SRVO-062 BZAL alarm (group:1 Axis:4).
    This means that the SRVO-068 error moved from pulse encoder 4 to pulse encoder 3.
    The connector for pulse encoder 3 was then not connected to anything.

    Question: Do you find the above-mentioned error code change normal?

    We have also measured connection between the M4P connector and the connector that connects to the amplifier(, CRF 8, ( i dont know if the image is going to show)

    The red numbers are from the M4P connector.

    M4P connector numbering that we have used as a reference.

    Do you have any ideas on what we need to do to resolve the error code?
    Question: Do you find the above-mentioned error code change upon connector movement logical?
    Are there any minimum ohm values, e.g., for grounding, that we should take into account?

Advertising from our partners