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