Posts by SHIFT_Lock

Assuming you call this homing routine from multiple different positions? J6 is taking the quickest path to -30.0. Probably a few ways to get around this but the easiest for me is to just add a point before your PR in your homing routine to force J6 to rotate the direction you wish.

MENU>SYSTEM>MASTER CAL then select single axis master and see if you've lost the pulse for axis 3 (i'm assuming you have). Under the (ST) column it'll show 0 instead of 2. If it does back out to the MASTER CAL screen again and hit F3 to reset your pulse coder alarm and then FUNC>8 to cycle power. If you haven't lost mastering on J3 DO NOT CYCLE POWER as you will likely lose it then. If I remember right you should be able to move the robot in JOINT even with a bad encoder as long as you don't move J3. Otherwise you may need to get the pulse back on J3 and master it and hope it holds out long enough.

Quote from Joey1Kenobi

If you go to your gun master menu, there should be a reset BZAL button. F3 I think. That should reset the BZAL and you should be good.

Quote from Jerryl859

We have a used RJ31ib welding robot which came with bad batteries. After changing the batteries, we are getting the SRVO 062 and 075 alarms. We have done the RES_PCA reset and subsequent power cycle. We have also set the variable Master_Enable to 1. The robot is in joint mode but we are unable to get any joint to move. We are able to reset the alarms for joints 5 and 6, but they are remaining for the other 4 joints. We have referenced the comments on the forum but are still having no luck. Any suggestions would be greatly appreciated. Thank you.

Setting system variable $Master_ENB to 1 just allows access to the Master Cal option under Menu>System. It doesn't do anything for the actual mastering of the robot. You can't master it until you can jog in joint and establish a pulse on each axis. Have you checked the encoder connections on the robot to make sure they're not loose, corroded or disconnected? Voltage on your battery box as pdl suggested? Check through associated wiring as well to see if somethings been disconnected or damaged.

There may be another way but on real world scenarios i've typically used "Remarks" to ignore wait instructions within the program. Or just simulate the DI on.

You won't be able to master until you establish a pulse on each affected axis. Under MENU>SYSTEM>MASTER/CAL select Single Axis Master and look under the ST column you likely have one or more axis showing "0" in this column. Jog each of the axis in JOINT + and - about 20 degrees and then enter a "1" in the SEL column and hit enter. This should change the "0" to a "2" in the ST column verifying you now have a pulse. Then you can master the robot.

Quote from vipinpunneri

This option is not what I'm looking for. This enables once you move the robot from a paused position. I'm looking for even a single non motion line moved alarm prompt message. This is basic function. But my particular robot doesn't shows the prompt

Ok I misunderstood but I do know what you are talking about now. I don't know the answer to this unfortunately but i'm intrigued now. I've never had a robot NOT show that prompt because I typically use that to jump back to where I was in the program quickly by selecting no.

Go to MENU>SETUP>RESUME TOL and set "Enable Tolerance Checking" to "TRUE" then you can set up your distance and orientation tolerances ect. I believe this is what you're talking about.

I didn't find much on recalibrating the touch screen but you mentioned it was brand new? Is the screen still covered with the protective film? If so there may be dust between it and the screen.

For one reason or another your UTOOL and UFRAME were changed likely by running a different program. As jpla21 said you need to define these before the moves in the program.

Under Menu>Program Adjust you can select the program to be adjusted and then which lines within the program to be adjusted. We used this to adjust our deburring robots a lot. Instead of adjusting each position individually you can adjust multiple lines all at one time.

You need to start with getting a "pulse" on your J4 and J6. Without a pulse you can't calibrate the robot. Move each axis individually in "Joint" back and forth around 20-30 degrees and then under the SEL column for that axis enter a "1" and hit "Enter". You should see the "0" change to a "2" under the "ST" column then you can calibrate.

That's a good point. I have specific USB's for our backups so I never worry about it.

I got this command from the forums here a few years ago and it's what I use to make our backups. I paste it into Notepad and save it as Backup.CM and then just execute it from the file menu on the TP. Does your AoA and Image all in one shot.

MKDIR UD1:test

IGALBKUP UD1:\test

EXIT

Are you just trying to change the payload in the job? Like our material handlers have two payloads setup on them. One for empty and one for carrying the load and we just call out the payload in the jobs on the fly.

Yes it will delete whatever is on your flash drive and then save the backup.

Quote from alive15

One thing I noticed on my own robot controller (R30iA) is that it won't read anything greater than 2 GB flash drive, I can only use 2 GBs or less on all my robots. I think it's supposed to be like this, but someone else can confirm. And Welcome to the forum

Yes, a lot of people have reported issues with trying to use anything larger than a 2-4gb flash drive.

We have sealant dispensing robots as well that require tip cleaning as well and use the light curtains to drop the safety circuit as mentioned above.

Quote from i_Robot

DCS is really what I was looking for.....it is not an option on my controller. not on the TP.

I was afraid of this....In the fully forward position the Robot would break the operator Light screen.

Since this Robot cell does all of it's work in the forward area with some side to side.... it is the farther side to side I am concerned with as the robot could only really go 60 degrees right or left before smashing into something, I increased the collision detection but, it caused many unnecessary faults, so I lowered it back to around 110%

I will have to come up with something to make this safe !

As for adjusting the collision detect you can actually do this within the job itself. So if you're reaching an area that gets close to an operator or fence you can turn it up to say 170 or whatever using a slower move and then on its retreat you can turn it back to 110 where you have it now.

When you get the alarm is the robot in a very similar position on one or more of the axis? If it does happen in a similar position each time wait until you get the alarm and check your resistance again to see if you then have a short somewhere. My guess would be that the cable is being pinched somewhere but only when the robot moves a particular way.

Quote from mbull

SRVO-062 BZAL just means that the current battery state is that no battery voltage is detected by the pulsecoder. If the arm has not lost power, you will still have your pulse count held in the encoder memory.

Also from the wording in the error manual, the SRVO-065 indicates a charge is still left in the batteries, just that it's below the allowable minimum. Anyone able to clarify if this is just to indicate a difference between an intact connection in the battery circuit where the encoders will still lose count memory, or does it just indicate that the low batteries are capable of still sustaining the count for a much shorter period of time?

According to the manual SRVO-065 BLAL is low battery voltage detected but if not replaced soon then you will get the SRVO-062 BZAL which means the encoder has lost connection to the batteries entirely whether they are dead or the cable has become broken or unplugged and you've already lost mastering. In my experience you won't get a BZAL alarm until you've already cycled power. We have to remaster an AUX axis a few times a day due to a bad cable and I can unplug the servo encoder cable with no alarms until i've cycled power. That's when the BZAL alarm comes up is after booting. So in other words the batteries probably started going dead and due to them not being replaced they died completely and the next time he turned the controller on he received the BZAL alarm. Or he had a BLAL alarm and cycled power to get rid of it without changing batteries and then got the BZAL alarm. Either way his mastering is lost if he has an active SRVO-062.

SRVO-223 DSP dry run (%d,%d)
Cause:  A servo DSP initialization failure occurred due to hardware failure or wrong software setting. Then, the software
entered DSP dry run mode. The first number indicates the cause of the failure. The second number is extra
information.
Remedy:  Perform an action according to the first number that is displayed in the alarm message.
1: This is a warning due to $SCR.$STARTUP_CND=12.
2,3,4,7: Replace a servo card.
5: Invalid ATR setting. Software axis config (FSSB line number, hardware start axis number, amplifier number, and
amplifier type) might be wrong.
6: SRVO-180 occurs simultaneously. Controllable axis does not exist on any group. Execute aux axis setting to add
axis at controlled start.
8,10: SRVO-058 (FSSB init error) occurs simultaneously. Follow the remedy of SRVO-058.
9: There is no amplifier that is connected to the servo card.
•  Check the hardware connection.
•  Check the optical fiber cable.
•  Check whether the servo am plifier power is supplied.
•  Check whether the fuse on the servo amplifier has blown.
•  Replace the optical fiber cable.
•  Replace the servo amplifier.
11: Invalid axisorder setting. Non-existing axis number is specified. Software axis config (FSSB line number) might be
wrong or auxiliary axis board is necessary.
12: SRVO-059 (Servo amp init error) occurs simultaneously. Follow the remedy of SRVO-059.
13,14,15: Document the events that led to the error, and contact your FANUC technical representative.

According to the manual on SRVO-223 this is the cause and your second number is "9" so it is something to do with your servo amp not being connected to the servo card. Is this the same robot that you had battery issues and you cycled power with dead batteries?

Ok, so I did a controlled start today and went to the maintenance menu to view the AUX axis settings and everything was identical. The gear ratio, the motor type, speed, ect ect. As far as the software and memory available and all things related everything is the same between the two robots as well. I did make one change to the "problem" robot though. I dropped the speed down from 18,000 to 16,000 to match the other robots and then COLD started the robot.

As far as the processing speed of the pendant display I can try to swap the pendants tonight at their lunch break and see if the issue follows the pendant to the opposite robot. I was really hopeful that I was on to something here with maybe the CPU running slow and not sending/receiving data fast enough causing a communication type fault. I'll pocket that idea for now so i can focus on some more likely culprits. If it's just a separate pendant issue then i'm not concerned with it at the moment.

This is the only active alarm of any importance besides the miscellaneous TP faults and the CNTR-009 I mentioned a few posts above. And this is a Group 2 Axis 1 servo set up as Continuous turn for a deburring process.

I have also been monitoring the torque values recorded on these axes and comparing them. I'd like to see if I notice a spike of any kind during the fault.

*EDIT* I did see a higher "Max Torque" on this axis than the other robot. At the time of the fault the torque recorded was 20.015 MAX and the Average was 17.153 whereas the other robot saw a max of around 3.6xx.