SOLVED Duet Reset when homing

  • Hi, I use a duet Wifi + Duex5 (RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05.1 running on Duet WiFi 1.02 or later + DueX5) and I have settled up a COREXYU with the following:

    • 2 stepper to drive Y
    • 2 independents X axis (X and U)
    • 3 stepper to drive Z

    Everything works well and I have successfully configured X homing, U homing, and Y homing (in this case I split the Y axis in Y and V using M584). I'm using the same logic when I home the Z axis, and in this case I split Z in Z, W, A axis, all with optical endstops. Endstops work properly (tested in the Machine specific tab).

    So here the issue: when I perform homeZ, when an axis reach the endstop (I think is the asis A), the board run into a loop and get resetted. Here the event log.

    Last reset 00:12:21 ago, cause: software
    Last software reset at 2020-06-16 16:11, reason: Stuck in spin loop, spinning module GCodes, available RAM 10636 bytes (slot 0)
    Software reset code 0x4043 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f80f BFAR 0xe000ed38 SP 0x20003234 Task 0x454c4449
    Stack: 00445465 00444466 61000000 a5a5a5a5 00445465 a5a5a5a5 20003258 200030f8 00000002 200048d4 00037740 20004ce8 2000177c 20003258 20004ce0 00000004 200030d0 20001790 20003258 200030c8 00000001 200032b0 4e49414d

    here how I run the z homing:

    G91 ; relative positioning
    M584 Z2 W7 A8 P7 ; split Z motor control to Z1, Z2, Z3
    G1 H1 Z-310 W-310 A-310 F900 ; move Z down until the endstop is triggered
    G1 H2 Z7 W7 A7 F360 ; go back a few mm
    G1 H1 Z-310 W-310 A-310 F360 ; move Z down until the endstop is triggered
    G1 H2 Z7 W7 A7 F360 ; go back a few mm
    M584 Z2:7:8 P4 ; back to combined axes
    G90 ; absolute positioning
    G92 Z0 ; Tell the firmware where we are

    Any idea on what could be the issue?

  • @Marco_76

    I have no idea what is causing this, but it seems to be related to this problem:

    And there was also another instance of a user getting the same reset code.

  • administrators

    @Marco_76 thanks for the detailed report. @dc42 will need to have a look at this. He may take a little while to reply this week.

  • @T3P3Tony
    ok thanks no problem

  • Moderator

    From DC42:

    My guess is that the homing switch in question is connected to the DueX and is picking up noise from a nearby stepper motor cable when it is triggered (i.e. open). That can cause an excessive interrupt rate, using up all the CPU time. This is on a list to do something about. Meanwhile, solutions are: use an endstop input on the Duet instead if possible, or use shielded cable to the endstop, or add a pullup resistor (e.g. between 1K and 5K) between the endstop input and +3.3V.

    Hope that helps?

  • @Phaedrux thanks this is an interesting direction. Also becouse the issue is happening very often but not always (let's say 9 times out of 10 tests), so I was assuming this is not software related. Unfortunately I don't have free slots in the duet wifi, so I need to keep it in the duex. But I assume that if I want to test this solution, if I use another cable for the endslot which is very far from all other cables, I should not see the issue anymore, right?

  • It sounds like you could just change the endstop cable to a shielded cable and continue as normal without any major changes. If you don't have a shielded cable, you can always run the existing wire through a Shielding Expandable Sleeving 1/4" ID I do this for my BLTouch sensor wiring to avoid any interference issues.

  • For the benefit of the forum let me share that the issue has been solved. I did as you suggested and I used shieded cables for the endstops. thanks to everybody for the support!

Log in to reply