Posts by SHIFT_Lock

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.

Same reason of why we never modify a job when it comes to “testing”. We copy it, modify it, test it, and then implement it.

Well as much as I hate to say it, I hope I have a few faults tomorrow (later today I guess) where I can start pulling on the bundle and see what happens. As well as check these setting mentioned above.

I’ve learned from these forums that one little oops can cause hours of downtime and frustration. So I’ve went through every robot we have and made full backups stored on two separate USB’s and our network at work.

I will have to do a controlled start on this robot first thing tomorrow to see about finding the AUX axis settings. As far as some variables I have found; to my knowledge the gear ratio is set to 0 across the board (I’ll find the variable tomorrow where I got this info), and the max speed is I believe 18,000 d/sec but we are set to 16,000 currently. I’ll have to find these variables again as it’s been a while since I’ve looked at them.

As far as changing parts out I would think that none of those pieces actually retain any kind of data that would need reconfigured upon swapping. Although if anything would I’d say the amp maybe? But it was swapped from the A robot which is mirrored off this one so I would assume if there were any “settings” they’d already be good? I’m not sure though.

Oddly enough we only had one of these DTERR alarms during production yesterday so I didn’t get much tinkering done as far as messing with the bundles ect. I spent more time skimming for payload and other variables.

Also, I already have current AOA and image backups of these robots in case of any “oops” moments.

I checked out what I believe to be the payload settings (i've never had to mess with this personally so it's new to me) under $PLST_GRP[1] and 2 going through each one and the four robots I compared it with all match. Group 2 is actually all 0.000 across the board on every one of them. I'm not sure where to find the aux axis inertia but that does bring up a good point. The robot has been constantly displaying:

CNTR-009 Warn-Cont Vel too high(G:%d^2)
Cause:  Continuous turn axis velocity is too high. cn_turn_no will not be valid because of high rotational speed.
Remedy:  Lower contaxisvel. This warning may be ignored if cn_turn_no is not used.

This has been up on this robot for quite some time and A robot does not display this message. I found the cn_turn_no variable and it's a negative number whereas A robots is positive. But I have no clue where to check to lower the contaxisval.

I still find it odd that our "problem robot" is the only one i've seen so far of the several others I checked that has this "delay" issue on all 7 axes. The two pendants in the video are the same robot performing the same job (mirrored) so I wonder what extra data this one is using compared to the others? Like you said according to the manual it's an obvious break in communication between controller and encoder it just stood out to me today while going over things. And the fact that it doesn't return to 0.000 like the other robot(s) we have performing the same job. My thought was maybe this slow transference of positional data is why it's not reaching it's 0 also.

The DTERR we just had happened in a different area than the last four i've documented. So far J3, J4, and J5 are the only three consistencies i've noticed. J4 and J5 are probably the least relevant as the cable bundle doesn't travel down to those axes. But J3 however is right around where everything is ran through and a highly probable pinch point so I will start there on the next DTERR. I won't rule anything out entirely just yet but to me J3 is just the best first choice.

Something else i've noticed is that when the POSN button is pressed and displaying positional data on this robot (while sitting still at HOME) some of the numbers will jump back and forth rapidly unlike the other robot. Also when calibrating sometimes instead of displaying all 0.000 the first set of numbers which is for G2 J1 will read 0.006 instead. Am I looking too far into useless information?

Data Processing Slowly1.MOV

The servo motor was swapped between another similar robot a while ago and since then we've replaced it again but I can't remember the fault we got that lead us to change it. It was something directly related to the servo being faulty according to the manual. As for the grounding this new cable doesn't have anywhere to ground it besides the bar inside the controller where all other cables ground to. Normally the internal harness would be grounded through the connection points in the arm and the base but since this cable bypasses those it just runs straight to the encoder.

I did notice something odd today that may or not be of any relevance but it's worth mentioning. I opened up the positional data screen on both robots for G2 J1 and noticed that Robot A is processing the data much much faster than B robot. The data moves so quick on A robot that I can't really catch any specific number but on B robot I can almost read every one. I don't know if this makes sense so I've uploaded a video to show what I mean. Also at "home" position A robot returns this axis to .000 while B robot is usually around -.084. Both reference positions for home are set at 0.000 +/- 1.000 for this axis. So to me it would appear this may be the CPU processing data at a really slow rate? Maybe the communication issue is timing related and not a broken connection or noise? Or possibly the noise is causing this slow down? Either way whether it's important or not I wanted to throw this out there because it seems odd to me. It's also the only robot we have that's processing this data so slowly and it's on all 7 axis as well. I watched both robots multiple times in G1 and G2 and it's the same result.

**EDIT** the video uploaded in poor quality and upside down so i'm going to send it again in a minute.