MCTL-003

    Hey guys, I am trying to get a new M1000ia set up, and am encountering an issue. When trying to jog the robot, I always get a MCTL-003 system is in error status fault. I can press reset+shift and hold shift to bypass this, but the alarm always comes back. I am not at any limit switch, and DCS is not enabled. Does anyone know how to make sure this fault doesn't arise while running the robot?

  • HawkME November 16, 2023 at 7:28 PM

    Approved the thread.
    Quote from TitusLepic

    That's normal. Set $DMAURST (deadman auto-reset) to true if you want the fault to reset when you pull in the deadman instead of requiring a push of the "reset" button.

    Hey Titus,

    From what I can tell, normal operation requires holding the deadman switch, then pressing reset, then holding shift, then jogging. If you release the shift button while jogging, you can press it in and continue moving as long as the deadman is still pressed. it appears $DMAURST allows you to skip pressing reset.

    The issue that I am having is that if the reset and shift are not pressed at the same time every time, the MCTL-003 fault will appear. When I changed the $DMAURST variable, there was no change clearing the faults.

    I may still be misunderstanding the documentation that I'm reading, but I don't think so.

    Edited 2 times, last by Bigk9 (November 16, 2023 at 9:44 PM).

    Quote from TitusLepic

    That's normal. Set $DMAURST (deadman auto-reset) to true if you want the fault to reset when you pull in the deadman instead of requiring a push of the "reset" button.

    This is only working for controllers with software version older than V9.40. Since software version V9.40 there is a new DCS parameter called "TP Enabling Dev Reset" which secures the $DMAURST variable.

    When changing TP Enabling Dev Reset to ENABLE then $DMAURST automatically also changes to TRUE.

    If the parameter is set to TRUE it is only possible to automatically reset the "Deadman released" alarm. Other alarms reuire to push the reset button.

    Yeah this is my first fanuc, so operator error is definitely possible. The only other active faults are the Deadman released fault, and PRIO 801 ethercat offline error, which is only a yellow fault. We are going to be using ethercat for a future integration, and from what Ive read it shouldn't be pulling up this fault.

    Please see the alarm history.

    Bring up the Alarm page, then hit F3 (HIST).

    Next, press Deadman-switch, then press RESET.

    Now you should be able to see which errors arise and i which order.

    The latest one will be the one in the top of the list.

    By looking at which error is directly after the RESET (indicated with blue background color) entry in the list, you can start the troubleshooting from there.

    Often it's better to focus on the root causes, rather than treat the symptoms....

    Quote from DS186

    This is only working for controllers with software version older than V9.40. Since software version V9.40 there is a new DCS parameter called "TP Enabling Dev Reset" which secures the $DMAURST variable.


    When changing TP Enabling Dev Reset to ENABLE then $DMAURST automatically also changes to TRUE.


    If the parameter is set to TRUE it is only possible to automatically reset the "Deadman released" alarm. Other alarms reuire to push the reset button.

    Thanks, good to know. All of my experience has been on older controllers.

    Thanks for your help everyone!

    It ended up being related to the PRIO-801 fault. We finally recieved the EtherCat manual from Fanuc, which showed that by enabling the "Error one shot" option under Menu > Setup > EtherCAT, would allow us to bypass the EtherCAT issue, and would subsequently stop the MCTL-003 error from appearing when runing in normal operation.

Advertising from our partners