Posts by SHIFT_Lock

    We've seen some issues like this with cameras when lights overhead of the camera were replaced due to their brightness vs the old bulbs. Do you use red light on this system? We use red light to reduce glare and if the red light does not come on when it should you could end up with glare like this. It does seem to be related to over exposure or lighting though.

    As long as they don't sim the output that tells you that bits are simulated. ;)


    Another option is to setup the robot to force all sim bits off upon cycle start.

    MENU->SETUP->PROG SELECT-> Simulated I/O ->Detail, Check when run and resume, Force condition.

    I plan on using a very high numbered DO for mine just to ensure they don't do this haha.

    Sorry you're still dealing with this.

    After rereading everything - lets talk about the temperature. Is the motor also hot at idle? High temperature of the aux amp could be from improper configuration or the amp may be too small for the motor and over working to maintain position. Seen high motor temperatures degrade Pulsecoders and cause DTERR alarms.

    I also noticed the Fanuc part #s you listed are missing the last digit (Axxx-xxxx-xxxx). That last digit would be printed in the small yellow box at the end of the part #. It may have come off during cleaning.

    Yes I have left the robots at idle for 5 or so hours and come in and felt the servos and they are still just as hot as they would be if they were running the whole time. I've mentioned this to some of the other guys that when we installed larger servos that we never upgraded the amps and this could be an issue. But it's only causing issues on one out of four robots. Fanuc requested a Diagnostic backup be pulled as soon as a DTERR happens so that was done this morning. According to Fanuc we are experiencing high levels of noise during the time of the alarm and they have requested that we run a separate grounding cable from the EOAT to the base of the robot. So I am going to do that today. I will gather some part numbers for the servo, amp, encoder, and whatever else you would like. While i'm in the line today I will try and check the connectors and pins as Kluk-Kluk mentioned.

    Under MENU>SYSTEM>CONFIG there is an option to turn on a DO if either an Input or Output is simulated. Looks simple enough to configure but I have not done it on ours yet. I do believe you need to cycle power after you set the DO you want on the config screen. This reminds me though, I wanted to do this on our robots at one time and forgot until I saw this post. I think I know what i'm doing tomorrow!

    Before resetting the PCA alarm in the Master / Cal screen, some controllers require you to enable that option in the variables section. I can;t remember the variable name, but if you search your alarm on google or this forum, you will find.


    Then after enabling that screen, you can reset the PCA alarm, then cycle power as mentioned by Stare.


    Most likely, you will see another alarm about axis not being calibrated, so you will have to calibrate the right axis. You may have to jog the respective axis all the way around to establish a pulse if you are getting pulse encoder error as well.

    MENU>SYSTEM>VARIABLES> $MASTER_ENB

    If it's "0" then set it to "1" and hit enter. Sometimes when I do this I have to cycle power in order for the master cal option to be available.


    RobotChad you can PM me if you like and I can help you with this.

    Again check your connectors.

    I had a robot with the same error and as with yours, it went and came back.

    It was a pin in the connector at the base of the robot.

    The pin was not locked anymore, so when I inserted the plug, the pin was pushed in and made barely contact, and when I pulled the plug, the pin came back in it's normal position and there was nothing special to see.

    In six months I almost swapped every part, and when I finaly noticed the faulty pin, it was solved in ten minutes....

    The internal harness and robot connectors are brand new. As are the cables from robot to servo and from robot to controller. Every part of this system has been replaced with new except the amp and servo which were swapped with another working robot. Could it be one of the other base cables causing a DTERR on an extended axis?

    Code
    1. TPIF-140 Connection limit exceeded
    2. Cause: An attempt to log into the teach pendant menuing system from an external web browser has failed because the
    3. connection limit has been reached.
    4. Remedy: The system variable $UI_CONFIG.$NUM_CONNECT controls the number of external connections allowed. The
    5. maximum number of connections is five INCLUDING the teach pendant. Reconnect the external connections in your
    6. system so that no more than five exist.

    Resetting the SRVO-068 should just be a matter of FCTN>0>8 to cycle power and it should go away. Unless the cable is completely shorted or disconnected. As far as the axis order goes i'm not entirely sure what they are doing there. Does this usually require a remaster afterwards? If so it sounds like they are removing the axis to drop the pulse and recalibrate it which can be accomplished by unplugging the servos encoder. But this will require you to remaster that axis and possibly reteach the job. As far as PTA are you talking about resetting the pulse coder alarms under Menu>System>Master_Cal? This usually needs done with the pulsecoder is unplugged and you receive a BZAL alarm.

    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.