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.
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.
Display MoreDCS 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.
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?
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.
I'm reading into it more and I don't think there's any reason I couldn't make the change provided I find out exactly what it is that needs changed. We don't use BG Logic or PMC in any of our robots so that's not an issue. We use an Omron PLC and the robot uses STYLE to call the main job. So I don't see why I couldn't have it just send a start signal and carry on. We already have it setup to recover all I/O upon power recovery. I think our restart issue is not with the robot config but with the start signal sent from the PLC. Either way our production is almost over for the night so I will continue this Monday when I have the line to myself to tinker away while they run the other line. I really do appreciate all your help this far.
Ok, so doing some quick reading it would seem I may need to change a System Configuration setting "USE HOT START" to "TRUE" and I will be able to continue the program after a power recovery. So I will try this next, although I do believe i'll have to set it and cycle power first for it to be "enabled".
*EDIT* Scratch that, they are already setup to start "hot" so I will need to do a little more reading on that subject. I remember seeing something about START for CONTINUE only or something along those lines.
As for the cables, yes I can get to most of them fairly easily so if this HOT START idea works like I think it should I will be able to test this out.
Yes normally when we get this fault we drive the robot up to clear the jig and remaster. I'm sure we will have another fault before the end of my shift and I will try your method to see what happens. I'm not sure that we are setup to continue after a power loss though which is the only way to clear the alarm. This extended axis also isn't near any other cables and the encoder cable is ran on the outside of the robot away from the bundle. I'm wondering if this could be an issue with the power/brake cable inside the robot? Possibly temporarily shorting and stopping power/communication to the servo? Honestly I think that's the only thing we haven't swapped.
After a DTERR alarm our process is usually to cycle power and return home to restart, or pull the pulse coder cable to re-calibrate and then return home. Pulling the cable seems to make it go longer without a fault so lately I've been doing this every time.
I will start recording that as well as the positional data.
Originally I did wonder if it was another axis' cable causing us grief but the new cable is ran entirely outside of the robot currently so I really don't know.
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
J1: -52.717 J2: 5.614 J3: -32.251
J4: -.000 J5: -57.758 J6: 27.306
J2/J3 Interaction: -26.636
G2: Forgot to document
J1: -53.366 J2: -.451 J3: -32.805
J4: .000 J5: -57.190 J6: -157.210
J2/J3 Interaction -33.259
G2 J1: -68.682
This is the positional data for the last three occurrences i've had so far. The first and third time have been basically the same spot in the program. The second one was on a different weld with a couple of the joints in a relatively similar position.
