Fanuc 30iB controller locks up

  • Hey all,


    New to the forum. Have found some great answers here. Hoping y'all can help with my issue.


    I have a Fanuc 30iB controller and M-710iC50 robot. I wrote a program for part treatment that uses a register variable to move to joint positions contained in position registers (indexed by the register variable in the TP program). This worked perfectly and repeatedly. I then needed to treat a second part in a different configuration; so, I translated the data in the PRs and ran in a second program. This also worked perfectly except for one movement where J6 was rotated in the opposite direction to reach a particular point, but then ran to completion without error.


    I was working on resolving the J6 issue when the controller froze - no response whatsoever from the controller - no response from the teach pendant.

    I powered down and backup the controller. After doing so, the teach pendant was responsive. However, when I opened the program that had been running previously when the controller froze, the controller froze again.

    I powered down and up again, deleted the program that locked up, created a new program and began entering the same code. When I got to the point of entering the register number I had used previously (again, I am entering a program), the controller froze again. Reboot, delete program, create new program, but this time I used a different register number. It let me complete entering the program using this different register number. I ran that program. It ran to completion until it came to the last movement and froze while moving. Now I'm in the exact same position as described above. Reboot, try to open this new program, and the controller freezes.


    I'm at a lost with what's going on, and was hoping y'all might have some ideas.


    Thanks!

  • /PROG YF_RH_TREAT

    /ATTR

    OWNER = MNEDITOR;

    COMMENT = "RH Panel Treat";

    PROG_SIZE = 408;

    CREATE = DATE 22-12-31 TIME 07:24:52;

    MODIFIED = DATE 23-01-01 TIME 18:27:42;

    FILE_NAME = ;

    VERSION = 0;

    LINE_COUNT = 14;

    MEMORY_SIZE = 856;

    PROTECT = READ_WRITE;

    TCD: STACK_SIZE = 0,

    TASK_PRIORITY = 50,

    TIME_SLICE = 0,

    BUSY_LAMP_OFF = 0,

    ABORT_REQUEST = 0,

    PAUSE_REQUEST = 0;

    DEFAULT_GROUP = 1,*,*,*,*;

    CONTROL_CODE = 00000000 00000000;

    /APPL


    AUTO_SINGULARITY_HEADER;

    ENABLE_SINGULARITY_AVOIDANCE : TRUE;


    LINE_TRACK;

    LINE_TRACK_SCHEDULE_NUMBER : 0;

    LINE_TRACK_BOUNDARY_NUMBER : 0;

    CONTINUE_TRACK_AT_PROG_END : TRUE;


    /MN

    1: UFRAME_NUM=0 ;

    2: UTOOL_NUM=1 ;

    3: IF DO[136:inRHPerchPos]=OFF,JMP LBL[200] ;

    4: R[1:posRegNum]=3 ;

    5: ;

    6: LBL[100] ;

    7:L PR[R[1]] 1000mm/sec CNT25 ;

    8: R[1:posRegNum]=R[1:posRegNum]+1 ;

    9: IF R[1:posRegNum]<=49,JMP LBL[100] ;

    10: ;

    11: IF (R[1:posRegNum]=50) THEN ;

    12:J PR[1:rhPerchPosition] 100% CNT25 ;

    13: ENDIF ;

    14: LBL[200] ;

    /POS

    /END

  • Don't think this is a programming problem. Think the OS is kind of corrupted.

    I would try to restore a older image, after making a image and AOA backup of current state. Hope you have an image of working state!?

  • Hm odd I was having this one time but it was throwing some code at me and I couldn't do anything so I factory reset it and online the only answer was Karel program but I wasn't running any Karel programs. I'm guessing if it's that it would have to be your controller if it isn't letting you do anything or throwing codes but I'm not for sure.

  • This is resolved. Thought I'd follow up with what was done in case anyone runs into the same problem.


    In short, the TP communicates with the controller via Ethernet. When the TP locks as I described, it can be because the adapter is busy processing other traffic, and cannot dedicate cycles to communication with the TP.


    I called tech support, and they told me that some users had experienced issues with Ethernet IP: In some cases, the controller network was connected to a high-traffic LAN, and the robot controller was looking at every packet whether it was directed at it or not - spinning its wheels processing these packets.


    In my case, there is no other traffic on the LAN. However, I had configured and enabled the Ethernet IP port 1 in preparation for the PLC's interface, and I had port 2 configured to allow access from my PC to the controller's web page. When I disabled port 1, the problem corrected itself. Also, the PLC is now up and running, I have renabled Port 2 and am communicating with the PLC without issue, and am pulling up the controller's web page from port 1. In this configuration, I am no longer experiencing TP lock out.


    Unfortunately, I can't give an absolute reason for the lockout. However, if your scenario is similar to mine, then I would suggest first disabling all Ethernet, and see if the issue resolves itself. If so, I would try communicating with the controller only through Port 2.


    I hope that helps, and thanks to all who responded to my posts!

    Edited once, last by kdkoadd: Had my port numbers reversed. ().

Advertising from our partners