Duet Reset when homing

Marco_76

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?

bot

@Marco_76

I have no idea what is causing this, but it seems to be related to this problem: https://forum.duet3d.com/topic/14531/network-loss-then-fw-crash-when-re-enabling-networking/3

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

T3P3Tony

@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.

Marco_76

@T3P3Tony
ok thanks no problem

Phaedrux

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?

Marco_76

@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?

PDBeal

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.

Marco_76

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!