SRVO-050 (collision detect) on first move of the day

    I have an R2000iA-165F robot (RJ3iB controller, V6.31) that's started throwing a SRVO-050 Collision Detection error on J6 on the first move after power on. I just found out that this started last week; the operators have been "fixing" the problem by cycling power which apparently fixes the issue somehow... Anyway, it threw that error again today after it had been sitting idle for an hour over lunch. I tried jogging in joint; even with the override speed set to very fine it still threw the error when I tried jogging J6. I was able to jog J1, 2, 3, and 5 with no issues - J4 threw the alarm at 100% override but the axis disturbance on the status menu was still showing J6 as being the issue. Dropped J4 override to 50% and could job it. After jogging away from the home position, I was able to jog J6 with no problem and the robot ran fine for the rest of the day.

    Nothing changed as far as payload, acceleration, or any other configuration issues that I can find. As far as I can figure, that leaves the possibilities as:

    Bad reducer

    Bad motor

    Bad brake

    Bad cable

    Bad servo amp

    I don't want to start replacing parts without diagnosing what the problem is first, how would yall go about troubleshooting this?

    When its only 1 axis affected you can almost always rule out the servo amplifier. Usually an intermittent issue, meaning you can get it, reset it, continue on but then presents again in roughly the same physical location would be a brake cable. The physical location repeatability of the fault is caused by cable 99.9% of the time. Also, the brake circuit is a single 24v circuit, meaning that you can swap brake cables from j6 motor to j4 motor. If the alarm changes to J4 its the cable. If it stays with J6 its the motor or reducer. My guess would be that it will change with the cable unless the srvo-050 is accompanied by an ovc srvo-053 alarm. If 053 is also experienced it is likely the the motor is trying to overcome a physical resistance after the brake has been released. Another method of ruling out the brake would be to remove motor from the j6 axis and attempt to jog j6. If the motor spins you can rule out the brake. Its then likely the reducer. It could also be the input gear but usually you'd get an srvo-024 move excess if it was the input gear

    The nature of the fault suggests there is opposite force being applied on JT6:

    - Ask operators if any actual collisions have taken place, if so at what position.

    - Any part of process that has been retaught, causing force applied to JT6 in operation.

    - When was last maintenance performed regarding grease replenishment.

    - Any possibility new bolts have been added to EOAT coupling that are too long.

    - Any noticeable increase in motor body temperature on JT6 during production.

    - Is error produced at a specific location in terms of robot posture.

    - When in error, can you manually jog it free, manual brake release it free.

    - How much displacement occurs with JT6 when running in repeat mode - is JT6 completing full rotations.

    - Have you thought of creating a standstill test program to just exercise JT6 around error location.

    - Swapping motors between 5 and 6 may result in new mastering being required, but possible to try.

    - Inspect JT6 motor coupling for damage (requires removal of motor to inspect).

    I swapped the brake cables and unfortunately, the fault stayed on J6.

    - Ask operators if any actual collisions have taken place, if so at what position. - Nobody knows anything. Of course, I've personally watched them crash the robot before and they didn't know anything then either, so that isn't really saying a lot.

    - Any part of process that has been retaught, causing force applied to JT6 in operation. - Nothing different than what's typical

    - When was last maintenance performed regarding grease replenishment. - January 2021. We run about 2000 hours of production on it per year, and replace grease every 3 years.

    - Any possibility new bolts have been added to EOAT coupling that are too long. - No

    - Any noticeable increase in motor body temperature on JT6 during production. - I don't have a baseline to compare it to. When production starts back up on Monday, I'll check to see if that motor is running hotter than the others.

    - Is error produced at a specific location in terms of robot posture. - Yes, BUT - the error only occurs after the robot has been sitting for a while. The only place it does this is at the home position. So I'm not sure if the robot faults at that location because of the location, or because that's where it hangs out most of the time. I'll go move it to a different location and let it sit there to see if the error reoccurs.

    - When in error, can you manually jog it free, manual brake release it free. - Today, I reset the error and could jog it. Last time, I had to jog it away from that position (in joint mode, avoiding axis 6) before axis 6 would respond without alarming. I don't have a cable to manually brake release.

    - How much displacement occurs with JT6 when running in repeat mode - is JT6 completing full rotations. - Will go check

    - Have you thought of creating a standstill test program to just exercise JT6 around error location. - Can't. Home position is right next to the tool rack and cell wall.

    - Swapping motors between 5 and 6 may result in new mastering being required, but possible to try. - Will give it a try when I'm not the only person in the plant. With the motor removed, JT 5 and 6 will be free to move, right? Do I need any sort of blocking to prevent this? The manual doesn't mention blocking for J4,5, or 6 but just want to be sure.

    - Inspect JT6 motor coupling for damage (requires removal of motor to inspect). - Will have a look when I swap the J5 and J6 motors.

    Yep, the usual response from operators - through fear of blaming culture no doubt.

    I'd remove motors as a last resort to be honest, carry out the least intrusive first and see if they yield anything........

    Regarding a test program, just 2 positions in mid air rotating JT6 between max pos and max neg limits and run at it a very slow speed not fast, any tight spots should yield errors.

    This is what I'd be doing first and foremost especially from cold if possible.

    Worth checking the brakes in situ with another person, whilst they are in T1 before requesting motion, place you hand on the motor and feel for resonance.....not just the audible click.

    Get the other person to inch it round too.

    Removal of ANY motor removes the brake with it so the relevant joint is free to move.

    However with minor axes and the usual gearing mechanism, back driving freely is usually quite difficult to do, in terms of blocking/hoist etc, that would be purely your call.

    Unlike the major axes, remove the motor without any blocking/hoist and the joint is likely to drop under gravity and possibly cause injury.

    Do not forget removal of any motor/mechanical linkage will likely result in you having to remaster.

    So I'd really only do this as a last resort, if the above doesn't yield anything conclusive.

    I realize it's been a few months, but figured I'd post the final result here:

    The issue went away for several months, then popped back up earlier this week. (Turns out ignoring problems doesn't actually make them go away). Ended up swapping out the J6 servo and the fault went away. Tried blocking the EOAT as best as possible to keep it from moving, but ended up with a little bit of movement. Here's what I don't understand:

    Recorded the J6 position before powering off. Changed the servo, powered back on. Got a BZAL alarm as expected; the J6 angle reading was about .4° different from when I powered it off. I set master_done to true and calibrated it, then ran the robot to the zero position and put an angle indicator on it to see how far off the mastering was. It was dead on.

    How? I thought for sure that changing the motor/encoder would result in it losing mastering, but it even realized that it moved .4° while I was changing servos. Is this lucky coincidence or is there some sort of electrical wizardry involved?

    As far as the mastering goes, I don't think you lose mastering data when disconnecting/replacing, you just receive different values from the new replacement and then the mastering data is referencing the new received values and usually always there will be a difference.

    Therefore remastering is required to resync the new values to the controller.

    I know in Kawasaki, if it's a motor issue and not an encoder, you can lock the joint in place, make a note of the current joint angle, remove/replace the motor and encoder and re-zero it by entering the noted joint angle at the locked position.

    Then when you move the joint back to 0 degrees, the scribe lines will be aligned at mechanical zero.

    Not too sure if you can with Fanuc (never had the opportunity to try it).

    Usually I replace everything, move the joint back to mech scribe lines and remastering it there.

    I may not be 100% accurate in this though......

    Thanks for reporting back you results, glad to hear you've resolved it..... :top:

Advertising from our partners