[BUG] bugfix-2.0.x - SKR Pro 1.1 - Reboots on G0/G1 commands that don't include extrude after homing

[jatmn]

Bug Description

Control Board reboots unexpectedly when running G0 or G1 command after homing.

Update After some troubleshooting on discord, this was confirmed to go away after turning off IDEX mode in the config.
So this is only reproducible if IDEX is enabled.

Configuration Files

Configs.zip

Custom IDEX machine based on CR10 Frame
SKR Pro 1.1
bugfix-2.0.x (last tested with Dec 28th build, as well as a build 1 week older than that)
Homes X-46 (off the bed)

Steps to Reproduce

1. G28 X0 Y0
2. G0 X10 (or G1 X10)

Expected behavior:

1. Machine would home XY
2. X moves to 10mm

Actual behavior:

1. Machine homes XY
2. Machine freezes for 3-4seconds and reboots

Additional Information

This happens with the heaters active as well as cold (or not powered)

There is an odd workaround for this crash.
If Homing is followed by a G1 command with extrusion, the move will complete without crash
Example:
0. Assuming hotend is already pre-heated above min extrusion temp

1. G28 X0 Y0 ;home xy
2. G1 X1 F140 E30 ;move to X1 while purging, reminder home is actually X-46 so this is a long move.
   This sequence will work fine.

Additional note
To add to this as it appears it might be related.
If i include the workaround in my start gcode to move X to 1 and then starting a print.
The print will usually complete fine via SD or USB Serial, however, once that print completes.
It does not matter if I do this right away or wait 20min after.
If I reprint the same gcode or different gcode (even if the different gcode has the workaround in the start code).
The result is Home xy then before the move to x1 it crashes like the original issue, even if I'm purging like noted in the workaround.
So I can ONLY run prints or use this workaround after a fresh restart.

[sjasonsmith]

This is making sense now. Unfortunately it's in code that I don't understand very well and don't have hardware to test. Hopefully @InsanityAutomation can provide input as well, and perhaps provide a better solution than what I came up with.

This will only happen when you are in DXC_AUTO_PARK_MODE. In this mode, the move is deferred until after the un-park process completes. The code that handles that deferred move ends up in a recursive loop, until the controller runs out of memory and crashes.

This is the call stack when the problem occurs. You can see that the unpark command is being re-issued while waiting for the first run to complete. I stopped this after the second iteration, but it continues like this until the system hangs.

I was able to prevent this infinite recursion by adding a flag to prevent reentrance in the deferred move code. Unfortunately I am testing on a bare board with a single motor attached. This might just get you to the next problem in real usage. In the code below I added the delayed_move_in_progress variable. You can find the original version of this code in MarlinCore.cpp

  #if ENABLED(DUAL_X_CARRIAGE)
    // handle delayed move timeout
    static bool delayed_move_in_progress = false;
    if (!delayed_move_in_progress && delayed_move_time && ELAPSED(ms, delayed_move_time + 1000UL) && IsRunning()) {
      delayed_move_in_progress = true;
      // travel moves have been received so enact them
      delayed_move_time = 0xFFFFFFFFUL; // force moves to be done
      destination = current_position;
      prepare_line_to_destination();
      delayed_move_in_progress = false;
    }
  #endif

[thinkyhead]

In addition to the PR linked above I have also applied the change at ca47dff — and maybe my small change is the only one that is actually needed…?

[jatmn]

Using the latest Bugfix downloaded today which appears to include the changes.
I can say the issues reported above are resolved.

• No longer crash when moving without extruding at startup
• No longer crashing after finishing a print (this was not reported but appears to have been fixed with this patch as well)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.