Disconnected From Controller

    There is one issue occurred in the customer's factory. The iPendants freeze irregularly and become inoperable. The LED light on the mainboard shows ‘.’, which means normal. When TP freeze, the robot is sometimes keeping running in auto mode and sometimes in manual mode, and will pop up a dialog box 'Disconnected From Controller'. After restart, the robot and the iPendant resume normal. Out of 500 R-30iB PLUS robots , more than 80 robots have the same issue.


    The dialog box 'Disconnected From Controller' is known as that the Watch Dog for communication between Controller and Teach Pendant need to be increased. So I changed $TX.$WDOG_TIMER from the defalut 100 to 400, and the defalut 1000 to 4000 for SETVAR $TX.$SLOW_TIMER. But the issue still exsits.


    After that, using the Wireshark tool to test, the network data packet size of Port1 is about 600pps, and the network data packet size of Port2 is about 300pps.


    The current suspicion is that the congestion of the Ethernet/IP network caused the robot to crash.

    1. Are there other factors that caused the TP freeze problem?

    2. If the Ehternet/IP network problem caused the TP to freeze, how to find the reason?

    3. If Ehternet/IP network problems cause the TP to freeze, is there any suggestion for a good solution?


    Thanks for your attention and support!

    Whenever I hear "irregularly" in an industrial setting I think lighting issues. I know, hear me out.

    There was an issue once with PLC's that would irregularly go out of comm. The majority of the times that it did it was at dawn or dusk. Finally traced down to the dawn to dusk lighting. One of them had a faulty transformer that hadn't completely failed. Often when that light cycled it would spike the system and cause the issue. This was almost 30 years ago so details may not be exact but that is the gist of the problem. Not saying that's your issue but.....

    We did have problems with a robot freezing up. It would eventually recover after about 5 minutes. We did not get the "Disconnected From Controller" message.

    Our issue was with network traffic. It required some in-depth IT analysis to find the problem. The robots were connected to the plant network for SCADA and automatic backups. The robots were getting too many discovery requests etc from other devices on the network. The network switch port that the robots were using had to be restricted to only allow certain data through.

    Quote from mortoch

    Whenever I hear "irregularly" in an industrial setting I think lighting issues. I know, hear me out.

    There was an issue once with PLC's that would irregularly go out of comm. The majority of the times that it did it was at dawn or dusk. Finally traced down to the dawn to dusk lighting. One of them had a faulty transformer that hadn't completely failed. Often when that light cycled it would spike the system and cause the issue. This was almost 30 years ago so details may not be exact but that is the gist of the problem. Not saying that's your issue but.....

    I couldn't find the law of its occurrence, so I used the word 'irregularly'.

    I also think our issue is with network traffic. But I don't know how to do some in-depth IT analysis to find the problem. Can you use Wireshark to do more useful analysis?

    Quote from jmd2777

    We did have problems with a robot freezing up. It would eventually recover after about 5 minutes. We did not get the "Disconnected From Controller" message.

    Our issue was with network traffic. It required some in-depth IT analysis to find the problem. The robots were connected to the plant network for SCADA and automatic backups. The robots were getting too many discovery requests etc from other devices on the network. The network switch port that the robots were using had to be restricted to only allow certain data through.

    We had an IT guru look at it.

    I did find an email from Fanuc where they give us this advice when we were troubleshooting:

    “he needs to make sure that the robot is isolated on a subnet, so that it is not exposed to all of the plant network traffic”

    I don't know exactly what they meant by that. We always use 255.255.255.0 for the subnet mask.


    But I think the solution was to configure the port settings on the managed network switch. Since the robot IP address is static, they restricted that port to only forward data that was directed to the robot's ip address. So broadcast messages were not passed through to the robot.


    I'm not familiar with the details, our IT department fixed the problem.

    This is very useful information. I will try it in the next work.

    I don't know what kind of programs you have in use, but in my machines I had this behaviour (Frozen iPendant) when there are too many task's are working.
    So I just increased $maxNumTasks....

    Quote from 1Cliff

    I don't know what kind of programs you have in use, but in my machines I had this behaviour (Frozen iPendant) when there are too many task's are working.
    So I just increased $maxNumTasks....

    Thanks for your information.

Advertising from our partners