SRVO-068 Continued...

Ok so a while ago I posted a topic about us having a major issue with this SRVO-068 on one of our robots. I'm talking 8-10 in an eight hour shift. The alarm comes up on the G:2 A:1 which is a continuous turn axis used to cut aluminum burrs off of friction stir welded parts. We currently have four identical robots running the same job (two lines, one robot does half of the frame and another robot does the other half) and we are still only having issues with this one. Here is a list of items that have either been replaced with brand new, or swapped from a knowingly working robot to see if the issue follows...

The entire EOAT. Blades, tooling, bearings, housing, everything.
Servo motor x2
Encoder cap x7 or so haha
Encoder cable from ARP2 to the encoder x10 haha
The internal cable from ARP1 to ARP2
Encoder cable from external servo AMP to ARP1
External Servo AMP
Batteries
Power/Brake cable from robot to servo
Power/Brake cable from AMP/Brake to base of robot
Brake board
Moves have been slowed down to reduce vibration

Ran a new ground from controller to robot base then from base to EOAT

Swapped drive control board

Swapped Optic cable from aux axis amp to drive board

Installed an air line to the encoder trying to reduce heat

Some of these parts new would get us a few hours to even a few days without a fault but it would always come back some days worse than others.

This is an R-30iA Controller and R2000iB robot.

Yet we are still getting this stupid alarm
One thing I was thinking of trying is swapping the Drive PCB board (A16B-3200-061) that the external servo amp is plugged into. Again I have another identical robot to swap parts with and see if the problem remains so i'm willing to start trying some new ideas. This board appears pretty quick and easy to swap and I would think it's just plug and play but i'm getting into some stuff i'm not familiar with so i'd like some input.

Another idea I had today was taking an AOA/IMAGE backup of the other robot and dump it into this one in the hopes that it might be some silly variable or setup config issue that we've overlooked or not found. Obviously I'd be reteaching the job(s) but it's not really an issue since there aren't a whole lot of points. (And if my boss is reading this I can come in Saturday to do it )

Do these sound like logical things to try or would you guys have a better idea of what we could do next?

Thank you Droth for sharing this information. I was able to find the original thread on that and I have some questions to add.

1. The SIF is the axis control module correct? I found all sorts of pictures of this board but none that match what I have in my controller. Is this the drive board maybe that I mentioned in my first post? Part number A16B-3200-061?

2.How about the Servo Driver AMP Baseboard A20B-2101-022 and also A20B-2101-023? I'm wondering if there are just different terms for these?

3. It also mentions the DSM module? Couldn't find a whole lot on this other than it's something related to the pulsecoder side of things.

If anyone can confirm what the part numbers i've posted are and what they do I would be very grateful. I'd also like to know if I do go to start switching these boards between two robots is there anything I should be careful of or anything special I need to do? Or is it literally just plug and play? And which one is most logical to have a hand in our DTERR alarms for an added axis?

Also we did check the cable grounds inside the cabinet throughout this whole process I just forgot to mention it.

Quote from R47

Hi Shift_Lock,
Sometimes this happen when you get a strong magnetic field. Check the enviromentif there goes a high Voltage Cable parallel with you encoder cable.

The original cable was buried in a cable tray covered in aluminum shavings so that was all cleaned up and when I installed the new cable between the robot and the controller I tie wrapped it to a fence up away from everything and it didn't seem to help. The other three robots are in the same condition with no issues so I don't think it's our issue. Thank you for your input though as that is a good idea to look into.

Quote from alive15

What was the solution to your issue?

I wish I could tell you. After replacing literally every single piece of the puzzle (besides the drive boards which was my next go to) the problem just went away. We've been two days of almost 20 hours of running per day with no DTERR alarms from this robot but nothing was done for almost a week before this. After doing everything I mentioned on the original post we got it down from 10-12 a shift to like 3-4 a shift then after a few more days of not messing with anything maybe 1-2 a shift and then it just stopped randomly with no further changes made.

If you want to elaborate on your issue a bit maybe I can try and shed some light as i've been through this entire setup haha.

EDIT: like right after I posted this I got another one.

Just a little update on this matter. After throwing everything we could think of at these robots the problem stopped for over 24 hours but this was a day or two after we had stopped changing things. And then magically returned again but only one or two a day. Now we are back to one every 30 minutes. Something I noticed today while looking things over and just trying to find anything that could be wrong I noticed something. These robots have been sitting idle for over 5 hours and the AUX axis servo is still hot to the touch. Like not scolding hot but hot like they would normally be after running a few hours. Every other servo is cool to the touch except these. Is this a sign that maybe something isn't right in the configuration? All this excess heat could absolutely be what's killing our encoders so this is something that concerns me.

Also i'm still looking for some answers about my above questions if anyone has any incite for me i'm all ears.

Skooter, thank you for your response. I went through with a multimeter and checked the robot base ground with various point on the robot and all was good. I removed the ground and scuffed the area with sand paper as there was some surface rust around it. I then went through the controller and checked the robot base ground at its grounding point on the rail where all of the other cables with open shields ground to and everything Was good there. All shielding had good continuity to the rail and every other grounding point I could find seemed fine back to the main ground coming into the controller by the disconnect. When they leave for the night I will pull some covers and check each plugs grounding wire as well.

Grounding seems to all check out so the next thing we did was our third shift guy put another new encoder cap on and we went about a day and a half or so without any problems. Then maybe one or two a day the following days. I remembered reading about someone changing the optic cable that goes from COP10B from the aux amplifier to COP10A on the drive board so I swapped that out with one from our other robot but we got another today on the same robot. I'm still curious about this drive board and whether or not it's simply plug and play or if i'm going to run into any kind of issues at all. It's the next thing in line that the amp plugs into. If I get some time tonight i'm going to do full AOA and Image backups of both robots and swap these drive boards out and try to run some parts through.

Quote from kluk-kluk

Again check your connectors.

I had a robot with the same error and as with yours, it went and came back.

It was a pin in the connector at the base of the robot.

The pin was not locked anymore, so when I inserted the plug, the pin was pushed in and made barely contact, and when I pulled the plug, the pin came back in it's normal position and there was nothing special to see.

In six months I almost swapped every part, and when I finaly noticed the faulty pin, it was solved in ten minutes....

The internal harness and robot connectors are brand new. As are the cables from robot to servo and from robot to controller. Every part of this system has been replaced with new except the amp and servo which were swapped with another working robot. Could it be one of the other base cables causing a DTERR on an extended axis?

Quote from Skooter

Sorry you're still dealing with this.

After rereading everything - lets talk about the temperature. Is the motor also hot at idle? High temperature of the aux amp could be from improper configuration or the amp may be too small for the motor and over working to maintain position. Seen high motor temperatures degrade Pulsecoders and cause DTERR alarms.

I also noticed the Fanuc part #s you listed are missing the last digit (Axxx-xxxx-xxxx). That last digit would be printed in the small yellow box at the end of the part #. It may have come off during cleaning.

Yes I have left the robots at idle for 5 or so hours and come in and felt the servos and they are still just as hot as they would be if they were running the whole time. I've mentioned this to some of the other guys that when we installed larger servos that we never upgraded the amps and this could be an issue. But it's only causing issues on one out of four robots. Fanuc requested a Diagnostic backup be pulled as soon as a DTERR happens so that was done this morning. According to Fanuc we are experiencing high levels of noise during the time of the alarm and they have requested that we run a separate grounding cable from the EOAT to the base of the robot. So I am going to do that today. I will gather some part numbers for the servo, amp, encoder, and whatever else you would like. While i'm in the line today I will try and check the connectors and pins as Kluk-Kluk mentioned.

Ok, so I don't want to jinx it but we have been one full week without any DTERR alarms! I wanted to update this in case anyone were to read through this looking for answers. Fanuc sent a field tech to our plant to replace the entire internal harness but upon arrival discovered that they had sent us a harness for a 2000iC robot with vision rather than the 2000iB with aux axis. He left but had a cable sent to us next day that runs from the controller cabinet (amp) straight to the aux axis encoder effectively bypassing the internal harness and connectors (all of which were brand new). So the only thing I can think of is that the internal cable (ARP1 to ARP2) was the culprit even though it was brand new shipped to us from Fanuc and installed by our guy on first shift who I trust a great deal as he's the one who has taught me most of what I know about robotics (I know he's reading this). I'll update the list of things we tried prior to this and hopefully it'll help someone else one day.

Quote from kwakisaki

Thought I would just add a post as this thread has made for a very interesting read, not only in the problem, but also the progression of troubleshooting it to.

It would be very nice to categorically prove the internal harness is at fault and I would offer the advice of using a megger to test it's integrity, should you have the time and availability to do it.

Obviously disconnect both ends and carry out tests across all signal conductors associated with the pulsecoder, with any luck, should yield a result in line with the applied solution.

From what I have read, I think this would give you peace of mind that this fault has indeed been located and resolved.

This has been a great thread to follow (not that I have been able to assist in any way with as I am new to Fanuc).

But has given me some great troubleshooting tips I will pop in my toolbox for future reference.

Thanks for sharing this SHIFT_Lock and all those who contributed.....

Display More

I've used meggers before in the electrical field but unfortunately as far as I know we do not have one where i'm at now. Although if given an opportunity I would love to remove this cable and test it to determine for sure it was the problem seeing as how this cable replaced three cables and all connectors on the robot. Kind of makes it hard to narrow it down to what the specific problem was. If we get the chance to do this I will update further but I think for the time being we are just happy to be back to full production with no more nuisance alarms!