Posts by SHIFT_Lock

Ok, so I don't want to jinx it but we have been one full week without any DTERR alarms! I wanted to update this in case anyone were to read through this looking for answers. Fanuc sent a field tech to our plant to replace the entire internal harness but upon arrival discovered that they had sent us a harness for a 2000iC robot with vision rather than the 2000iB with aux axis. He left but had a cable sent to us next day that runs from the controller cabinet (amp) straight to the aux axis encoder effectively bypassing the internal harness and connectors (all of which were brand new). So the only thing I can think of is that the internal cable (ARP1 to ARP2) was the culprit even though it was brand new shipped to us from Fanuc and installed by our guy on first shift who I trust a great deal as he's the one who has taught me most of what I know about robotics (I know he's reading this). I'll update the list of things we tried prior to this and hopefully it'll help someone else one day.

PRIO-091 E-Stop PCB comm error %x, %x, %x (hex)
Cause:  Indicates that an error has been detected in communication between the MAIN PCB and Emergency stop PCB.
Remedy: -  Check the cabling between the MAIN PCB and Emergency stop PCB.
- Replace the cable between MAIN PCB and Emergency stop PCB.
- Replace Emergency stop PCB.
- Replace the MAIN PCB.

I would think starting here would be a good idea. Being that this is a communication issue between the Main PCB and E-Stop PCB it could also be the cause of the other E-Stop related faults.

Quote from Nation

Here you go. Never used it myself. Good luck.

This seems to be a frequently asked question on here and although I don't have any robots that require KFloppy maybe we could make this a sticky thread where the download is easily available? As long as it isn't against any rules of the forum that is.

You can buy the shells on eBay. I've seen them from $150US to $500US depending on model type.

https://www.ebay.com/p/10031090618?iid=273629595900&thm=5000

It says they are Fanuc brand but also says it ships from China so i'm not entirely sure on quality i guess. They also sell protective soft bumper covers on a few sites if you google search for them. *hint* *hint*

It would be entered in the actual program just before the move where you are encountering your collision. Like I said you'll have to play around with it a bit as i haven't been able to test it out yet. Although if I get some time tonight I may try to get mess around with it.

I've looked into this before but once I started getting all of the information I needed they moved the line to another building so I haven't done it yet. One option is Fanuc offers an "Auto Backwards Exit" feature that will allow you to record up to I believe 6,000mm of travel and when a collision is detected it will reverse back through the job. It is a paid option and I have not had the pleasure of working with it.

Another would be using a skip condition monitoring variable $MISC[1]_$HPD_TRQ[x] Using this you can watch to see which axis sees the biggest torque difference and execute the skip before it gets a collision detect. Again I've not been able to mess with this yet to tell you exactly how to set it up. But I was talking with another member on here about it and here is what he came up with for me to try.

SKIP CONDITION $MISC[1]_$HPD_TRQ[1] >= 20 // Here you will specify what condition you are using as a decision point. This will act like a branching instructione (if, then, else) that is checked during a move rather than between moves. You may not use 20 as your threshold, and you may use a different axis. You will have to find the threshold that works best for you.

L [2] 20mm/s CNT100 SKIP,LBL[100] // This is your break point. This is the move that approaches the surface of the part, but is on the lookout for your skip condition, which is the point when your torque rises above your set threshold. At that point, it will execute its next action.

You may need to do some testing with this as I haven't gotten around to it yet but the skip condition should jump to the label specified if the torque is seen to be equal to or above whatever you set it at.

I know you can do an AOA backup while the robot is working but IMAGE requires you to cycle power so that's a given haha. As for the rest I've read that Fanuc doesn't like larger capacity memory sticks. I use a 2GB for all of mine and have never had an issue with formatting. One thing I can think of is after you go to the memory file screen did you hit F5 UTIL to set the device? You must set to the correct USB port before you can backup which brings me to another idea, are you using the USB drive on the cabinet or on the TP? It's much quicker when you run through the Cabinet port which is UD1. Hope some of this is useful to you.

It sounds like you've cleared the alarm and it came back and you lost master data again? If that's the case you need to check your encoder cap and cable. If you have a spare cap I would replace it as the manual suggests.

Did you lose mastering when the fault occurred? RES_PCA and cycling power won't lose your mastering unless the encoder cable is removed or damaged in some way or the encoder itself is damaged or removed. If you did lose mastering you will have to establish a pulse (you will likely see SRVO-075 come up) and then remaster. Do you have a good backup? Do you have the original master counts? There are quite a few posts regarding mastering on the forums with some detailed steps on the easiest way to do it. You should only need to remaster the axis that is faulted out.

MENU>SYSTEM>MASTER_CAL once you have the master cal screen open hit F3 for the option RES_PCA and then F4 for yes. This will clear the Pulse coder alarms. You may need to cycle power afterwards in which case please make sure your batteries are good and you have a good AOA/IMAGE backup. If it comes back there is likely an issue.

This is all the manual says about SRVO-073:

SRVO-073 CMAL alarm(Group:%d Axis:%d)
Cause:  The Pulsecoder may be faulty, or noise may be causing the Pulsecoder to malfunction.
Remedy:
1.  Improve the shielding.
2.  Do PULSE RESET Operation.
3.  Replace the Pulsecoder, then perform mastering.
Refer to the Controller Maintenance Manual for more information.

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.

Eu recomendaria que você definisse 100%, que é a configuração padrão. executá-lo a 25% pode correr um risco maior de danificar o robô caso ocorra uma colisão. Estou curioso para saber por que alguém a reduziu para 25%.

Quote from daniel.piton

A melhor configuração de colisão do Call Guard é 100%. meu robô está em 25%: Oi tchau :: bem:

por que seu robô está definido em 25%? Não sei ao certo qual é a sua pergunta.

Quote from Nation

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.

Quote from Skooter

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!

Quote from alive15

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.

Quote from kluk-kluk

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?

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.