Speed spiking and dropping rapidly in automatic mode

    Hello all,

    We set up a new Fanuc Robot M-20iD/35 in an attempt to hook it up to one of our CNC machines. The issue is, whenever the robot is switched into automatic mode the override speed on the pendant starts fluctuating wildly. The speed the robot moves at while being run from the CNC control doesn't actually change, but this speed fluctuating so wildly it will intermittently cause a speed over travel limit alarm.

    While in either automatic or manual mode, the pendant will not allow me to set the speed over 25%. I believe the machine control is trying to set the speed to 100% and the pendant is limiting it back down to 25%, and it just goes back and forth. Does anyone know why a new Fanuc pendant would be limiting the override speed like this, and how to resolve the issue?

  • MOM February 16, 2024 at 7:39 PM

    Approved the thread.

    By "override" you are referring to this, correct?:

    Have you checked the setting for the Override Select? (under the Setup menu)

    Quote from RobotSandwich

    I believe the machine control is trying to set the speed to 100%

    How would it be doing this? It's unusual for an external device of any kind to have control over the robot's Override speed. How does this configuration work? How are the machining center and robot communicating?

    Also, why would the machining center have control over the robot's Override? That's very odd. Is the robot doing pick&place style machine tending, or is it kinematically linked with the machining center in some way?

    For that matter, what software is this robot running? Fanuc has a large number of option packages, some of which have some rather unique effects.

    Quote from RobotSandwich

    There are no background programs on the pendant at all.

    Are you sure about that? Checking for BackGround Logic programs is easy enough, but there could be KAREL programs running invisibly in the background. This goes back to the "what option packages and configuration" question I asked above.

    Quote from SkyeFire

    By "override" you are referring to this, correct?

    Yes, that speed in the top right corner is the override I'm speaking about. I saw it called the "General Override" on a few sites.

    Quote from SkyeFire

    Have you checked the setting for the Override Select? (under the Setup menu)

    Yes, However those override speeds are all set to 10% but the pendant is limited to 25%. Line 1 on that page shows "1 Function Enable: DISABLE" so I assume that means its disabled anyway.

    20240219 135912 — Postimages
    postimg.cc
    Quote from SkyeFire

    How would it be doing this? It's unusual for an external device of any kind to have control over the robot's Override speed.

    I was incorrect, the speed fluctuation happens even with the CNC machine powered off and disconnected from the robot, we still see the same issue. The general overrides maximum value in teach mode is 25% and as soon as we switch it to automatic mode it fluctuates quickly between 25% and 100%.

    Software versions:

    20240219 140257 — Postimages
    postimg.cc
    20240219 140324 — Postimages
    postimg.cc
    20240219 140334 — Postimages
    postimg.cc
    Quote from SkyeFire

    Are you sure about that? Checking for BackGround Logic programs is easy enough, but there could be KAREL programs running invisibly in the background.

    Checking the [Setup->Next->BG Logic] shows no background programs. I'm not sure how to check if there are other Karel programs running in the background besides that.

    20240219 140003 — Postimages
    postimg.cc

    The robot comes with an image flashed to the robot that allows it to work with our machines, I don't know why just this robot would have a BG program limiting the speed.

    Quote from RobotSandwich

    Line 1 on that page shows "1 Function Enable: DISABLE" so I assume that means its disabled anyway.

    Correct

    Quote from RobotSandwich

    I'm not sure how to check if there are other Karel programs running in the background besides that.

    The only way I know off would be to use STATUS>PROGRAM, and work through the list. That would tell you what's running, but not offer any clues as to what each of those programs is doing.

    As for options, the SUMARY.DG file when you make an MD backup will list all the Fanuc options installed on the robot.

    Quote from RobotSandwich

    The robot comes with an image flashed to the robot that allows it to work with our machines, I don't know why just this robot would have a BG program limiting the speed.

    Hold on -- do you have more robots with this same setup, that don't have this issue?

    If so, then m first thought is to take an MD backup of this robot, and a "sibling" that doesn't have the problem, and run a comparison of the backups, starting with SUMMARY.DG.

    Quote from SkyeFire

    Hold on -- do you have more robots with this same setup, that don't have this issue?

    If so, then m first thought is to take an MD backup of this robot, and a "sibling" that doesn't have the problem, and run a comparison of the backups, starting with SUMMARY.DG.

    Thank you, after comparing it to the other robot setups I found the issue to be the DCS settings.

    "DCS->Cart Speed check->override Limit"

    was set to 25% but the disabling input was set to "Disabling input: JPC[ 1:]" and it was supposed to be "Disabling input: SIR[ 1:]"

    Changing this setting fixed the issue. Although I am confused as to why "JPC[1:]" was triggering the override since JPC wasn't set up in the "Safe I/O connect" Page at all. More of a curiosity since it shouldn't have been set up like that in the first place.

    Quote from RobotSandwich

    Thank you, after comparing it to the other robot setups I found the issue to be the DCS settings.

    "DCS->Cart Speed check->override Limit"

    was set to 25% but the disabling input was set to "Disabling input: JPC[ 1:]" and it was supposed to be "Disabling input: SIR[ 1:]"

    Changing this setting fixed the issue. Although I am confused as to why "JPC[1:]" was triggering the override since JPC wasn't set up in the "Safe I/O connect" Page at all. More of a curiosity since it shouldn't have been set up like that in the first place.

    Well, the disabling input works just like that, it disables the (in this case) Cartesian Speed Check (CSC).

    The input selected was set to a Joint Position Check-status (JPC[1]) which wasn't even set up, hence, the status of the JPC[1] would never become 1 or TRUE and thus your CSC was never disabled.

    It's always the case of failsafe when it comes to DCS (and machine safety), where for something to be considered safe, it must be active, just like an E-stop circuit. There needs to be an active signal telling the system that that particular equipment or function is indeed working well. If there are no signal, either someone pushed the E-stop button, or the cable broke. In either case, the system should revert to a failsafe state, which usually means to stop.

    For the CSC there are "add-on"-options to also activate a speed control which will force the robot to move slower, either by forcing the override to a set percentage value or to limit the speeds to a set mm/s value (kind of like when in T1 no motions will be faster than 250mm/s regardless of the programmed speed/override).

    Good thing you found it though.

    There is probably some logic already made for setting the Safe Internal Relay (SIR) that was supposed to act as the disabling input for your CSC.

    Good find.

    Usually, when programming DCS for safety reasons or even for machine safety so the robot doesn't collide with things outside of his working area because someone messed up, you can delete the disabling input so it stays active all the time.

    But this may be a problem if robot for some reason has moved or has been jogged outside the DCS allowed zone, if it's configured to stop it will trigger again and again until you move it inside the allowed area again. (The opposite if you used restricted zones)

    You can do that with patience, but it's really annoying.

    In this exceptional case, I usually link the disabling input to the safe I/O signal that indicates the robot is in T1. This disables the dcs zone completelly when robot is in manual mode, but keeps it activated while on AUTO or T2 (I always disable T2 by the way...)

    If your DCS cartesian zones only inform the PLC of their status and PLC cuts the fence or estop channel, this is not a problem and you can keep the dissabling input unnasigned.

    Regarding CSC, if you use them, take care as if used tool is very far away from the robot flange, a very little rotation speed on the 6th axis can provide a big ennough speed on the tcp to trigger. This seems evident but the first time I though about this was when I was moving a 2m long gripper and I almost got hit while moving the 6th axis because of how long it was...

Advertising from our partners