Posts by SHIFT_Lock

On ours we were able to remove the servo and jog it outside of the robot and then try to move the robot physically without the servo on and that's how we determined that it was the reducer. I'm not sure how easy that would be on your model as i've never worked on one before.

Check the grease for metal flakes. It almost sounds like the reducer is starting to fail. We had one lock up on us on J2 and it would allow us to smoothly jog in one direction but collision detect it the opposite direction.

I thank you all again for your suggestions and I will get with our engineer about possibly making a change. I would like to see some dowl pins or something installed here because I do agree that it started with the drive gear shifting and causing wear inside the bolt holes. Then over time, like you guys mentioned it got worse and worse until it then started destroying the track itself.

I think both of your alarms are related to the mastering being off. Like I said right now your robot thinks it's in one place but is in fact somewhere else more than likely one of the soft limits is being hit. You can check the physical position of the robot and look at your axis limits to see if that is indeed the case. Under MENU>NEXT>POSITION it will tell you the current position of the robot (or at least where it thinks it's at) and then under MENU>NEXT>SYSTEM>AXIS LIMITS you can see where the soft limits are currently set.

You don't necessarily need DCS zones set up to adjust the collision detect within a job. Add in a line before it calls the move home such as "COL GUARD ADJUST 130" and it will adjust it on the fly. Just know that your payload settings must be properly setup or this will just cause issues for you. But you can do this anywhere in the program so if you want to decrease the sensitivity after it's home write it back in as "COL GUARD ADJUST 100" which is default or whatever it is you want it at.

Grounding seems to all check out so the next thing we did was our third shift guy put another new encoder cap on and we went about a day and a half or so without any problems. Then maybe one or two a day the following days. I remembered reading about someone changing the optic cable that goes from COP10B from the aux amplifier to COP10A on the drive board so I swapped that out with one from our other robot but we got another today on the same robot. I'm still curious about this drive board and whether or not it's simply plug and play or if i'm going to run into any kind of issues at all. It's the next thing in line that the amp plugs into. If I get some time tonight i'm going to do full AOA and Image backups of both robots and swap these drive boards out and try to run some parts through.

I would be having a talk with your maintenance department for sure! But as TitusLepic suggested using data registers is a great way to prevent this. Another idea would be to also make the move to home a little slower and call a collision adjust right before hand so if there is a mishap it won't cause much, if any damage. You can always readjust the collision detect immediately after it is home.

To add, for a temporary quick fix while you work on the other program changes you could always add in a line at the top of the main program to wait until the "At Perch" output is on before executing the main job. That'll force them to take the robot home manually before being restarted after an abort all and give you a bit of "peace of mind" while you work to correct the issue permanently.

I'm assuming he changed the batteries with the power off and more than likely lost mastering. Stroke limit is a soft limit setup in the robot to avoid damaging anything by smacking a hard stop. So I would say he probably mastered it way off and now the robot thinks that it is somewhere it's not. Like JuiceeMan said, remove the protective padding and find the witness marks on the robot and redo the mastering properly and you should be fine. Search through the forums about Mastering and you will find plenty of info on the how-to's.

Yes, if you look at the first picture closely you will see what i'm talking about with the holes being worn out into an oval shape. There is no spline, key way, or dowl pins holding our gear in a fixed place so what you say makes perfect sense and it's not really anything i had thought about. Now that you've mentioned it I honestly can't believe I hadn't already thought about it. Thank you for pointing that out to me! I will see what we can do about having something done to correct this issue because we now have four robots that are rail mounted and they are all done the same way.

Thank you all for your input! I also believe this is a backlash issue as well as foreign contaminates and lack of lubrication. We have since greased the track and gear and are now doing so on a regular bases. Our foreign contamination issue is a bit harder to take care of though. In our process we friction stir weld aluminum to steel and then eliminate the burrs leaving bits of aluminum everywhere. These bits of aluminum fall off in different areas one of which is around the material handler which runs on this track. So far everything is looking good now and I did go through and slow some of the moves down just a bit because it was moving relatively fast. I did notice that the holes in the gear where the bolts hold it to the drive motor were quite worn out and I don't know if that is a result of the track failing or a reason the track failed.

If the USB is in the controller cabinet is UD1 selected as the currently set device?

Quote from TitusLepic

I'm not really sure what you mean about adding multiple JMP LBLs in the same line. A JMP LBL is basically a GOTO statement; you can't jump to two places at once.

Line 12 is completely irrelevant to your program; if your logic on line 12 is true then line 12 jumps to lbl[3], if it's false then you jump to lbl[3] on line 13. Either way, nothing between line 13 and lbl[3] will be executed.

As far as having limit faults trying to go home, generally you'll want to do a linear move to safely clear the workpiece and then a joint move for the move home.

I'm wondering if line 14 is an intermediate move to get to a safe position to then move to PR1 and since it is never executed the robot tries to move straight to PR1 resulting in the limit error.

On lines 12 and 13 I noticed that they both have JMP LBL [3]. So whether it is greater than 1800 or not it won't matter because either way it is jumping to label 3 and skipping line 14. I would assume this could have something to do with why you're hitting limit faults because no matter what you're jumping to line 15 and 16 moving to PR1 without ever executing line 14.

EDIT* I typed this out a little over an hour ago and got called off to fix something and just came back and hit send. I didn't see where TitusLepic had already pointed out the mistake.

Quoted from andreic on another post but maybe when you did the restore some logging settings got changed? Sometimes I have issues with things like this if there is no specified folder on the drive to save to. I've not really messed with image logging myself so these are just some generic ideas.

"MENU=>iRVision-> Vision Config -> Enable logging and Log Path.

After that on your vision process you must enable logging for failed images."

Skooter, thank you for your response. I went through with a multimeter and checked the robot base ground with various point on the robot and all was good. I removed the ground and scuffed the area with sand paper as there was some surface rust around it. I then went through the controller and checked the robot base ground at its grounding point on the rail where all of the other cables with open shields ground to and everything Was good there. All shielding had good continuity to the rail and every other grounding point I could find seemed fine back to the main ground coming into the controller by the disconnect. When they leave for the night I will pull some covers and check each plugs grounding wire as well.

Just a little update on this matter. After throwing everything we could think of at these robots the problem stopped for over 24 hours but this was a day or two after we had stopped changing things. And then magically returned again but only one or two a day. Now we are back to one every 30 minutes. Something I noticed today while looking things over and just trying to find anything that could be wrong I noticed something. These robots have been sitting idle for over 5 hours and the AUX axis servo is still hot to the touch. Like not scolding hot but hot like they would normally be after running a few hours. Every other servo is cool to the touch except these. Is this a sign that maybe something isn't right in the configuration? All this excess heat could absolutely be what's killing our encoders so this is something that concerns me.

Also i'm still looking for some answers about my above questions if anyone has any incite for me i'm all ears.

Quote from Hazard

My experience with this has been that certain pieces of equipment will sometimes generate enough vibration to cause a momentary misalignment with the light curtains or cause a connector to lose connection. If I see it happening only when certain programs are run that's the path I follow.

Also watch out for fans on summer days. I've had plenty of situations where a fan would blow a piece of paper past a light curtain. Area scanners can be even worse with this. I was tracking down a random E-stop related issue a while ago where within the 30 seconds it took me to get to the line the E-stop alarm was gone and the line would just start back up. I went up into our overhead cage and caught an associate pushing an E-stop and resetting it quickly.

Quote from alive15

What was the solution to your issue?

I wish I could tell you. After replacing literally every single piece of the puzzle (besides the drive boards which was my next go to) the problem just went away. We've been two days of almost 20 hours of running per day with no DTERR alarms from this robot but nothing was done for almost a week before this. After doing everything I mentioned on the original post we got it down from 10-12 a shift to like 3-4 a shift then after a few more days of not messing with anything maybe 1-2 a shift and then it just stopped randomly with no further changes made.

If you want to elaborate on your issue a bit maybe I can try and shed some light as i've been through this entire setup haha.

EDIT: like right after I posted this I got another one.

I would say don’t do it as you risk damaging the servo motor which is set up to run off a certain AMP with a certain current output.