[BUG] Rebooting while homing

[AndreySamokhin]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

The board reboots while homing the Z-axis.

The issue occurs inside the do_homing_move() function with the planner.synchronize(); being the last executed line. Further investigation showed that the Planner::busy() function never returns 0 because the Planner::has_blocks_queued() function consistently returns 1.

The minimum required changes of default configuration files:

• Add a fourth axis.
• Use the TB6560 driver for X, Y, or I axis.
• Perform homing at high speed.

configuration.zip

Bug Timeline

New bug.

Expected behavior

When homing with the Z endstop disconnected, the expected behavior is to receive the Printer halted. kill() called! error. This is achievable if the configuration specifies the A4988 driver for the I axis rather than TB6560.

Actual behavior

The board reboots a few seconds after initiating the homing routine along the Z-axis.

Steps to Reproduce

The bug can be reproduced using only motherboard without connecting any sensors, motors, etc.

1. Modify the default configuration files to add a fourth axis, set the TB6560 driver for the I axis and perform homing at high speed.

// Configuration.h
#ifndef MOTHERBOARD
  #define MOTHERBOARD BOARD_MKS_GEN_L
#endif
#define BAUDRATE 115200
#define I_DRIVER_TYPE  TB6560
#define Z_MIN_ENDSTOP_HIT_STATE LOW
#define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 4200, 80, 500 }
#define DEFAULT_MAX_FEEDRATE          { 300, 300, 5, 300, 25 }
#define DEFAULT_MAX_ACCELERATION      { 3000, 3000, 100, 3000, 10000 }
#define I_ENABLE_ON 0
#define INVERT_I_DIR false
#define I_HOME_DIR -1
#define I_MIN_POS 0
#define I_MAX_POS 50
#define HOMING_FEEDRATE_MM_M { (50*60), (50*60), (5*60), (50*60) }


// Configuration_adv.h
#define HOMING_BUMP_MM      { 5, 5, 2, 5 }
#define HOMING_BUMP_DIVISOR { 2, 2, 4, 2 }
#define AXIS_RELATIVE_MODES { false, false, false, false, false }


// pins_MKS_GEN_L.h
#define I_STEP_PIN 49
#define I_DIR_PIN 50
#define I_ENABLE_PIN 51
#define I_MIN_PIN 52

2. Establish communication with the board via UART.
3. Send the M119 command to confirm that the Z-axis endstop is not triggered.
4. Start homing routine using the G28 Z command.
5. After a few seconds observe that the the board reboots.

Version of Marlin Firmware

bugfix-2.1.x (d2bda12); 2.1.2.4

Printer model

DIY

Electronics

Board - MKS GEN L V1.0 (ATmega2560); X, Y and Z drivers - A4988; I driver - TB6560

LCD/Controller

LCD is not used.

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[classicrocker883]

I had an issue with homing because of variables declared like so:

  float parkingposx[2],          
        parkinggrabdistance;

while this snippet doesnt really have to do with homing it is just an example.

for instance:

- uint32_t max_acceleration_mm_per_s2[DISTINCT_AXES],
-          min_segment_time_us;
            
+ uint32_t max_acceleration_mm_per_s2[DISTINCT_AXES],
+ uint32_t min_segment_time_us;

there are a few files which should have this explicitly defined otherwise it can cause issues.

[plampix]

Why do you think this results in different code. Because it doesn't.

[classicrocker883]

@plampix because when I had changed this code, it resulted in erratic behavior when homing.

even if you ask ChatGPT what issues may happen if you group them when declaring:

This difference would cause issues if you tried to compile the first code snippet, 
as you cannot declare the same variable name with different data types in the same scope. 
The compiler would throw an error.

 When you declare them in the same line, 
 they are both allocated memory in the same block of memory. 

well maybe the compiler may not always throw an error, but certainly there was an when flashing the firmware.

my guess it probably has something to do with in settings.cpp

[AndreySamokhin]

@classicrocker883, you could have mentioned the Dangerous behavior when homing issue in your first message.
Your explanation sounds unrealistic. As @plampix pointed out, comma-separated declarations are valid in C/C++. The actual problem with the code you modified is different: you changed the order of variables in the planner_settings_t structure, which really matters.
Next time, please do not refer to ChatGPT as a reliable source without double-checking its answers or at least carefully read it responses, as what it said ("... you cannot declare the same variable name with different data types...") is inconsistent with your explanation.

[classicrocker883]

it wasnt the "order of variables" in the struct that mattered. feedrate_t is literally the same as float. declaring the variable inline as a different type was the cause.

[AndreySamokhin]

@classicrocker883, I'd like to conclude this off-topic and ultimately pointless discussion. Are you aware that settings are typically loaded from EEPROM at startup? Do you understand how this process works under the hood? If not, I recommend examining the MarlinSettings::_load() function. Based on your responses, it seems you haven’t conducted any research of your own, so here is a brief summary for you. For the planner_settings_t structure, structure members are loaded from EEPROM sequentially, in the same order they were originally defined. However, when settings are saved to EEPROM, the entire structure is written. Now, consider what will happen when someone decides to reorder the members in this structure to "organize/simplify some code". Can you guess the consequences of such a change?

[AndreySamokhin]

The bug still persists in the latest version of bugfix-2.1.x (efba06c).

To work around the issue, I switched to another external driver (currently using LV8727).

[ellensp]

I cannot replicate this exactly, but I can get weird results using a ramps 1.4 (complete lockups no reboot from WDT)

I setup test axis on X,Y,Z and A on E1 with endstops plugged into X-MIN,Y-MIN,Z-MIN and A is on Z-MAX
X,Y,Z and E DRIVER_TYPE are all A4988, I_DRIVER_TYPE is TB6560

Power up and Send G28

Under normal conditions this is what happens

1. Z will raise
2. X will home
3. Y will home
4. Z will home
5. Z will home again at slower speed
6. A will home
7. Z will raise

When it fails it stops while doing step 4

Things I found from experimentation

DEFAULT_AXIS_STEPS_PER_UNIT plays a part.
With #define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 2700, 80, 500 } and #define I_DRIVER_TYPE TB6560 It works as expected

but
with #define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 2750, 80, 500 } and #define I_DRIVER_TYPE TB6560 it breaks.
The user provided DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 4200, 80, 500 } is way over the breaking point.

Also
with #define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 2750, 80, 500 } and #define I_DRIVER_TYPE A4988 it works as expected.

To me this looks like some sort of timing issue with stepper pulse generation and steps/mm.

With TB6560 defined the following are defined

#define MINIMUM_STEPPER_POST_DIR_DELAY 15000
#define MINIMUM_STEPPER_PULSE_NS 30000
#define MAXIMUM_STEPPER_RATE 15000

I suspect that MAXIMUM_STEPPER_RATE is so slow that it is impossible to generate the required number of steps pules in the time required with this constraint.

These are my ramps test configs

Ramps test Configuration.zip

[AndreySamokhin]

When it fails it stops while doing step 4

I experienced exactly the same behavior when I used it with a real 3D printer.

I cannot replicate this exactly

To reproduce the provided example, only the board is required. The connection of sensors, endstops, and stepper motors is not necessary, which is why you were unable to reproduce it.

I also varied the third element of DEFAULT_AXIS_STEPS_PER_UNIT and noticed that the TB6560 driver has the highest delay values compared to the others. However, the strange thing is that the issue occurs when homing the Z-axis, not the I-axis. Unfortunately, my understanding of the Marlin firmware is not deep enough to solve this puzzle on my own.

[thinkyhead]

Well, here's what I can tell you differs in Marlin for TB6560 versus other drivers: surprisingly not much! Just these values:

    #define MINIMUM_STEPPER_POST_DIR_DELAY 15000
    #define MINIMUM_STEPPER_PULSE_NS 30000
    #define MAXIMUM_STEPPER_RATE 15000

• The MINIMUM_STEPPER_POST_DIR_DELAY and MINIMUM_STEPPER_PULSE_NS are the highest of all driver types and the MAXIMUM_STEPPER_RATE is the lowest, so it really constrains the speeds you can reach and the number of axes. The DIR delay, in particular, requires a pause to occur inside the Stepper ISR for every direction change, and this can cause a watchdog reset without too much strain. With an extra axis, MAXIMUM_STEPPER_RATE may need to be reduced.

I wouldn't say we have a bug in Marlin so much as a case where we're not able to handle the given parameters within an interrupt context. You can try lowering some of those delays just to the point where DIR changes are still reliable.

Another option would be to try using FT_MOTION which does not use blocking DIR delays.

[thinkyhead]

As a general test condition, you should also try turning off the USE_WATCHDOG setting, to see if it still resets. That will tell us that the reset is indeed caused by the ISR using up all the available cycles.

The solution within our existing planner would be to take account of very long DIR delays and exit the ISR for a while to allow the main loop to proceed, then return to continue further steps later, but this would require some re-architecture of the way it now works.

So until we get that sorted out your best option is to use FT_MOTION, but be aware that it is new and not widely tested and may require additional tuning.