Posts by SHIFT_Lock

I completely agree with you that we have been playing parts roulette with this robot. I think some of it is due to us just not knowing what to do next and the fact that we have identical robots to interchange parts with at no cost to us. Not to mention the sheer frustration we've all been through.

1. At the point of failure, what position is the physical posture of the manipulator in (axis 1 - 7).

I actually had a DTERR fault while typing this and this is what I got.

J1: -53.521 J2: -.359 J3:-32.809

J4: .000 J5: -57.187 J6: -157.068

J2/J3 Interaction: -33.169

G2 J1: 170.556

This is typically the same general area where our DTERR fault occurs although it has happened in a couple other positions as well

2. Can you tabulate the positions of axis 1 - 7 at the point of failure.

I will begin to collect this data at the failure points throughout the night to check for any consistencies.

3. Have you an infra red thermometer you can shoot at ALL the encoders and tabulate them at the point of failure.

I believe we do somewhere in the plant and I will talk with our facilities guys to see about getting it. As a last stitch effort I do have a really good infant thermometer in my truck that is designed to check in a no contact manner that I could try haha.

4. Are there any other errors associated with this at the point of occurrence.

This is the only error we receive during this failure. Every failure we disconnect the encoder and re-calibrate the extended axis. It's a continuous turn so it only takes a couple minutes.

5. I would be very tempted (not that I would recommend) to force this error by disconnecting the pulse cable from the external axis whilst it's running and see if the resulting error is the same.

With this it would be hard to do "safely". I imagine I could put the line in teach and rotate the extended axis via the TP and then unplug it. Or during normal operation I could probably just unplug the amp side of the cable to achieve the same effect.

I do appreciate all of your help and interest in this matter. I would still consider myself a novice when it comes to robotics as i've never been to any kind of training and what I do know i've learned by playing with a TP, reading on the forums, or learned from a co-worker.

We aren't %100 sure it's the cable but that cable is what resolved our issues for over two months. As far as the connectors and pins ect. the encoder cap is new, and the external axis amp was swapped with the other robot. These cables bypass the internal harness entirely and it's a direct unbroken run from amplifier to encoder so the plugs on the robot do nothing at this point. I almost feel as though something is intermittent and possibly "shorting" out these cables. Although i'm at a loss with why the brand new cable doubled our occurrences of this alarm. Besides the external axis amp i'm unsure of what else could be swapped inside the controller cabinet to narrow this down but i'm open to ideas as i have an identical cabinet to swap parts between. Only thing would be getting the time when they aren't running production. Overtime is pretty much locked out currently.

Hey guys, me again.

So after installing the one piece cable from the servo amp to the encoder we rid ourselves of this dreaded DTERR alarm for about 2 months or so and assumed it had to have been the internal harness. Well guess what has come back to bite us yet again? Luckily we had ordered more of these one piece cables so our third shift guy ran a brand new cable back out from the amp to the encoder and this made our DTERR fault occurrences DOUBLE to almost 4-5 in two hours! The cable was ran correctly and grounded and blah blah blah. Meanwhile 4 other robots are doing the exact same job and are set in the exact same environments and we have zero issues out of them. What in the world could possibly be killing these cables? I threw another encoder cap at it a few days ago and we had zero change in the amount of DTERR's we have a night. The cable itself is wrapped in leather for added protection and even wired to its own battery box inside the cabinet.

I would hate to think that the cables are so fragile that it was damaged during the install process. It's not like the guy was swinging from it and dragging it across razor blades

The only reason i revived this thread instead of making a new one is because of all the info I've already typed out is in here.

Another question, is there any way to use this servo as a simple ON/OFF without needing to worry about the encoder data? I know they make motors like that but it would be way to costly for us to switch to this method this late in the game since these lines won't be around but another year or so. Also, just to reiterate, I have an identical controller and robot that I can pull and swap whatever pieces I need from so give me some ideas please!

Like HawkME mentioned you could pull the motor and run it with it disconnected from the robot and then physically move the robot with the motor off and see which one is causing your issue. Since this is something you pulled from a warehouse with dead batteries i'm sure redoing the mastering won't be an issue for you at all.

Quote from keyboard7

Got another new battery from crib this morning and checked the voltage which was 3 volts.

Swapped out battery I put in last week, cleared alarms all good at power up, no alarms.

Checked voltage on new one from last week and found .85 volts.

This is the first time in 17 years this has happened. I took the the bad one out of the sealed box myself, so I know it wasn't used, but don't know how old it was. I will from now on check voltage, and date the box on the batteries when we receive them. It was the battery that is in the controller.

I will check them again before I replace them in the controller also because we are prone to short power outages in our building. We normally order these replacement batteries in pairs for each robot.

We just went through something similar only it was the pulse coder batteries in the base of the robot. After our guy replaced them two robots alarmed out for battery alarms and upon checking the voltage they were bad. Luckily we hadn't shut them off for the weekend like we usually do. Then we checked the date on the box and they were past their shelf life. Not a bad idea to take a few seconds to check to save some real headaches later. Glad you got it figured out.

Quote from keyboard7

That was just what I was wondering, I get them from the tool crib, I normally check the voltage before I put it in but was trying to due too many things at once this time. I am going to get A new one again and check voltage before I swap out the one I changed last week.

I don't ever trust the batteries in our tool crib when it comes to "special" batteries. AA and AAA sure, they get used all the time and are consistently restocked. But anything else could have been in there for who knows how many years.

You could calibrate it where it currently is and then finish jogging to your zero marks and recalibrate it properly.

Quote from pdl

You can also replace just the encoder, but if you go that route you have to be careful with the re-installation.

I agree, I think the motor is likely ok since the BZAL error is an encoder issue. Save that motor!

Quote from pdl

A power cycle is not necessary after setting $MASTER_ENB to 1, it takes effect immediately.

I do have one R30iA controller that will not display the master cal option until after a power cycle. I did think it was odd because i've never had to do it before on any of our other robots.

Quote from EPeters1

Working on a robot set up by another guy so I don't know all the details but I am getting the BZAL alarm on Group 1 Axis 3. When it was first set up a couple weeks ago I am told they replaced the 4 1.5 V batteries in the base and I just replaced the 3V battery in the controller this morning because no one was certain if that had been done last time. I went into the mcr variable and changed spc-reset to true and then cycled power just like the maintenance manual says but the error persists.

From what I have read the fact that it is only on one axis and all batteries are accounted for means that i need to replace the cable running to axis 3 and then remaster. If at all possible I would rather not but if that's it then that's it.

When the other guy first set up the robot he got the error but was apparently able to clear it and we used it for about two weeks until this morning. I find it strange that he could clear it only to have it return now. Maybe the cable was borderline before and now it's totally shot?

Any suggestions are appreciated.

Display More

I've never been able to clear a SRVO-062 using this method either. You may want to try and go to MENU>SYSTEM>MASTER_CAL and hit F3 for RES_PCA and then F4 for yes. You will need to cycle power afterwards but I assume you've already lost your mastering for this axis anyways so it shouldn't matter at this point. Then you will at least be able to jog the robot as needed. Sometimes the MASTER_CAL option won't be available (should be option 3 under variables) if it isn't then open up your variables and set $MASTER_ENB to a 1 then cycle power and it'll show up.

Do you have any other alarms active in your alarm log? Maybe a SRVO-068 DTERR? Swapping the cables as Lynx suggested is a good idea although now you will be mastering two axis instead of just one. I'd try to swap the encoder cap off of your spare robot to A3 and see if it'll clear up. If not i'd say your cable is bad.

Did you by chance hit a physical hard stop on the robot?

You could open those limits up to +360/-360 but i'm not sure that would work for your situation. To continuously rotate I imagine you will need the option which will cost $$.

Quote from pdl

J6 can also be setup for continuous turn, if there are no cabling restrictions. You'll will need to buy the software option from Fanuc.

I thought that maybe you could do that just wasn't %100 sure.

If you look under MENU>NEXT>SYSTEM>AXIS LIMITS What is J6 set to currently? You might need to look into running an external 7th axis and using the continuous turn option from Fanuc.

Quote from Pkmphd

Hello all. I'm in quite a pickle atm and trying to get things figured out. Currently I have a Fanuc robot stuck in a over travel limit and cannot move it. The problem I'm running into is that I cannot manually move the robot since the fault is still present (MCTL-003). Does anyone know how to get the fault to clear (SRVO-402 DCS Cart. Pos. Limit) so that I can manually move it and send it back home?

I appreciate any and all help!

I believe all you should need to do is open MENU>ALARM Log and reset the single channel fault to clear it out and then you should be able to move the robot away from the limit. This is what I did when one of our engineers ran into this issue and it worked for us.

Uninstall a software option?

Check this thread out. Seems like there isn't a way to uninstall the option but you may be able to reinstall everything excluding the option you don't want.

Also this is what your screen would essentially look like if you have a "Home" position recorded under the Reference Position menu. It's under MENU>SETUP>REF POSITION. If one is enabled then select F3 for "Details" to see if there is any recorded data.

Is there a reason the robot is currently in "STEP" mode? When in "STEP" mode your robot will not run in auto. And while in "teach" mode you will only execute one line at a time in the logic. Other than that i would assume if this was running fine and then just "decided to fault out" i'm not sure the lack of a Home Position is your issue. Unless someone deleted the Reference Position somehow by mistake.

What error keeps coming back? If it's the BZAL error then you need to reset the pulse coder alarm before cycling power under Menu>System>Master_Cal.

I double checked on one of our R2000iB R30iA controllers and that's where it is. I believe I read on the forums somewhere that on the R30iB controllers it's under $UI_CONFIG.