Robot comes up with a over page that say. Abort or continue after a fault or ES

  • I have a R-30 that everytime the operators break the light curtain with the robot on the safety base switch or open the fence or just stop the robot and step it thru the rest of the program and restarts is any where in the program it pops up a window that says Abort or Continue press enter. And I don't know which variables or what has been turned on. Any help will be great it has caused me several crashes by operators not knowing or just pressing buttons.

  • Our newer fanucs have this on them but it will only come up if someone has stepped it through the program. If you open a gate or something and don't do anything with the robot it shouldn't come up. This alarm probably isn't the reason the robot is crashing though. The problem lies with the operators probably skipping I/O's or waits and then starting the robot up again in a new location without completeing it's task. I.E. if the robot is waiting for IN20 "Ok To Drop" but the jig clamps aren't opened yet and someone skips the Wait and then selects "Continue" it'll come crashing into the jig with the clamps closed. Or collide with another robot that did get its "OK To Pick". Some of our technicians are absolutely terrible about doing this.

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

  • this message comes up when the encoder position at which the robot stopped is different from the one it is trying to start from. it can the result of bad motor break or a very violent stop.it won't be wise to get rid of the message. also when ever the message pops up make sure to manually move the robot to a known position and then continue. as SHIFT_Lock pointed out crashes might be the result of waits being skipped or moving the robot manually and not putting it back into the program.


  • this message comes up when the encoder position at which the robot stopped is different from the one it is trying to start from. it can the result of bad motor break or a very violent stop.it won't be wise to get rid of the message. also when ever the message pops up make sure to manually move the robot to a known position and then continue. as SHIFT_Lock pointed out crashes might be the result of waits being skipped or moving the robot manually and not putting it back into the program.


    I agree, the entire point of this pop up screen is to ensure the operator knows that the robot is starting in a different position than it stopped at to avoid crashes.

    "I could tell that my parents hated me. My bath toys were a toaster and a radio."

  • Thanks guys but the problem is the operator hits abort and the program goes back to the start home position and it might be coming out of the press or the tool turned 180 from home and it crashes I want it to be if it stops or the open the fence it just continues in the program instead of having the option for them to abort the job.


  • Thanks guys but the problem is the operator hits abort and the program goes back to the start home position and it might be coming out of the press or the tool turned 180 from home and it crashes I want it to be if it stops or the open the fence it just continues in the program instead of having the option for them to abort the job.


    i do not think you can change the prompt box options. again i might be wrong. maybe one of the more experienced members of the forum be able to help you. the only thing i can suggest is to increase the tolerance for resume but be cautious about it not to increase it to much. try dm to one of the senior members if nobody replies to your post.

  • Something I've done that doesn't really fix the problem but would prevent the crash is to use a register to keep track of where in the motion program the robot is. In my case, the structure looks something like this:


    R[25] = 1
    motion statements to get robot from perch to over tool changer
    R[25] = 2
    tool change logic and motion
    R[25] = 3
    motion statements to get robot back to perch
    R[25] = 0


    At the beginning of the program, it checks the state of R[25] to see if/where the program was aborted. If R[25] = 0, then it runs the program like normal, 1 or 3 it runs the appropriate motions to safely get to a known location then runs the program like normal, and if it's 2 it requires someone with a password to come put the robot right and reset R[25] before it will run. Like I said, this won't keep them from aborting the program but it should prevent a crash if they do.

  • Does anyone know a good way to troubleshoot and eliminate the possibility of a mechanical issue for this? Such as a failing brake, or a stretched belt (im working with LR MATE 200i D, which are belt driven on some of the joints). I tend to believe this is more of a user/setup issue on my cell. Seems to only happen when the robot is reaching bellow the base, about fully stretched out, which also unfortunately is our pick position. I also wonder if the operators are stopping the equipment improperly and causing a sudden slamming stop in that position. Obviously I wont be able to really know unless I catch them in the act. I would like to verify that mechanically speaking we are sound though.

Advertising from our partners