What is the robot type, controller model, and software version?
Something loose on the panel board. Probably one of the TBOP's or JRS connector coming from the main bd.
Sent from my SM-G900P using Tapatalk
What is the robot type, controller model, and software version?
Robot is M710-iC
Controller is R-30iB
Software version is HandlingTool v8.30
Check the teach pendant cable and connections as well.
Hi,
If you might have a (Profibus) Dp module installed it might be the bustermination. The symptoms you described sound similar to what I once found out to be a wrong set DP terminationswitch.
Succes !
It has happened to me this situation and after I contacted Fanuc they said that before restarting the unit I should write to them the error code displayed in the controller and they will give me an answer of this situation.
Hello ,
Can you upgrade robot firmware?? You can find latest update from fanuc cRc. This might help you. Let us know if this works!!!
Hi all
this problem happened to me 4 times in 3 different robots.
All robot had V.30P version of software (R30iB controller). It happened with arc tool but also with handling tool.
On the teach pendant alarm didn't compare when problem happened.
When the problem happened the situation on the robots wasn't the same.
Have you got opinion?
just now i encountered the same situation, pendant freezes after approx 5 min of restart... 
Are you using Ethernet communication? We have had a similar issue where two robots where getting overwhelmed by too much traffic and froze up. Fanuc gave us two possible fixes, and one of them worked. Have not had an issue in 6+ months.
Copy and paste from previous thread again:
"Is it connected to other devices via Ethernet? Apparently the robots are by default set to look at all Ethernet traffic, even if it is not addressed to that robot. There is a filtering setting that can be changed to correct it so the robot only cares about traffic aimed at it. We had to do this with two of our robots. They would become non-responsive, but disconnecting Ethernet and cycling power usually fixed it.
The change we made was
$ETH_FLTR[4] from 0 to 44818
Must cycle power to take effect. No guarantee this is related, especially if you do not use Ethernet."
What did you find?
Did you find a solution finaly?
Can you elaborate more on how to do this? Also is there a possibility to control what data is being filtered. In the sense, is there a risk of important traffic communicating to the robot that gets filtered with this command?
The change we made was
$ETH_FLTR[4] from 0 to 44818Must cycle power to take effect. No guarantee this is related, especially if you do not use Ethernet."
Can you elaborate more on how to do this? Also is there a possibility to control what data is being filtered. In the sense, is there a risk of important traffic communicating to the robot that gets filtered with this command?
How: Navigate to the system variable and enter the new value.
Details: No clue, Fanuc was very stingy with details, i have no idea what the variable does or what the numbers mean, only that we had a weird problem and Fanuc said "try this".
44818 is the port for Ethernet/IP in TCP. So it seems a port filter only for ethernet/ip.
