Hi
This is just a thought from general computer knowledge
Maybe there is some background logic or some program that is running (looping) continuously. Because the robot does not change the status fro few days, maybe that program runs millions of times and clogs the cpu
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.
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.
When you guys mention the TP being "non responsive" is it not opening menus or anything? We have one robot (out of about 20 on this line) that will start acting up if don't touch it for a while. It will be running the whole time but the second we have an issue and I need to open up Master/Cal to re zero the G2:A1 servo it will open a completely different menu or just freeze for a while. Cycling power on the TP does nothing but cycling the controller power will fix the issue. Is this similar to your issue? If so I may try to change that variable and see if we notice a change. Only problem is I don't know how long it takes for the issue to happen since we don't have to do much with it for weeks or months at a time as far as actually recalibrating and what not. Driving through jobs and similar don't seem to be affected.
Usually, the robot continues operating normally and we only run into an issue when we need to use the pendant. Buttons do nothing, screen will not change, and if we do not disconnect the ethernet before or during the restart, the teach pendant even freezes during the start up with a blank white screen.
It has happened with days between or months between. Now that we changed that variable, it has not occurred for 4+ months. It is a preventative thing we are even rolling out to other robots that have not shown that issue
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.
I can't find it in system variable list
Sent from my ONEPLUS A3003 using Tapatalk
Contact Fanuc on that one. TP firmware update (or even system software update) might be necessary.
Ours are R-30iB with A Cabinet. We are on software version V8.30P/11 to V8.30P/39. It may be a variable that is only available if you have installed certain Ethernet/IP options, i am not sure. Our robots are all somewhat homogeneous, so it is hard to detect what is specific to just our situation and what is generalized.
We had this happening twice:
- Faulty cable from controller to TP, but usually gets really random errors.
- Faulty optic fibre cable inside of robot controller. Can't really say which PN off the top of my head, but it was for a R30iA controller. Issue disappeared after changing said cable.
Usually, the robot continues operating normally and we only run into an issue when we need to use the pendant. Buttons do nothing, screen will not change, and if we do not disconnect the ethernet before or during the restart, the teach pendant even freezes during the start up with a blank white screen.
It has happened with days between or months between. Now that we changed that variable, it has not occurred for 4+ months. It is a preventative thing we are even rolling out to other robots that have not shown that issue
Our issues are somewhat similar. The robot is never affected during it's normal production but the second I try to start opening menus or anything it'll open the wrong one or sometimes just freeze for a minute. I haven't had to disconnect the Ethernet at all during a controller reboot so maybe i'm not having same initial problem.
We had this happening twice:
- Faulty cable from controller to TP, but usually gets really random errors.
- Faulty optic fibre cable inside of robot controller. Can't really say which PN off the top of my head, but it was for a R30iA controller. Issue disappeared after changing said cable.
Was there noticeable damage to the optic cable? I'm curious as to how you came about this solution to see if there is anything I can check prior to this step. If I were to try a different cable I have to run it through about 30+ feet of cable tray and that will take time, time that I don't currently have with them running full production haha. The optic cable would be a much easier "test" for me right now provided we have one. I may just swap one from another working cabinet and see it the issue follows.
Sorry to say, but no.
We swapped out the cable as a last resort after we rebuilt an R30iA cabinet almost completely - someone thought it would be a good idea to send 220 V through a 24 V line into the safety board...smoke ensued.
By this point we had swapped out the safety board, the main board and the cpu. This optical cable was the last resort before calling in FANUC to deal with it. Worked in the end. The company that bought the robot went bankrupt soon after, so I don't have any follow up on how things were afterwards.
I have random issues with TP hanging up on new R30ib as well. Usually dcs 4d display will drag a bunch of panes with delays. But, menu enter, retry it will pop up with the intended display.
Had the same issue, robot had the EthernetIP communication option installed. It turned out that there was an IP address conflict with an other robot.
