Posts by SHIFT_Lock

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 !

Display More

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.

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.

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!