Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] HOME_BEFORE_FILAMENT_CHANGE doesn't work after steppers timeout #17663

Closed
thisiskeithb opened this issue Apr 23, 2020 · 3 comments
Closed

Comments

@thisiskeithb
Copy link
Member

thisiskeithb commented Apr 23, 2020

Bug Description

Unless I'm misunderstanding the feature, enabling HOME_BEFORE_FILAMENT_CHANGE is supposed to ensure homing has been completed before each filament change:

#if ENABLED(HOME_BEFORE_FILAMENT_CHANGE)
// Don't allow filament change without homing first
if (axes_need_homing()) home_all_axes();
#endif

This works great if initiated after first boot up, but if you run a test print or simply move the nozzle & bed around after you let your steppers time out, the nozzle & bed will crash trying to move to the park position after sending M600/filament change.

My Configurations

Link to one example config, but this is easily reproducible across all my printer configs.

Note: HOME_AFTER_DEACTIVATE is not enabled in my configs.

So you don't have to dig through my config, I park in the front-right corner which is accessible by the nozzle & bed:

 #define NOZZLE_PARK_POINT { (X_MAX_POS - 10), (Y_MIN_POS + 10), 20 }

Steps to Reproduce

Scenario 1 (working)

  1. Initiate filament change after bootup (XYZ position is unknown)
  2. Nozzle & bed home correctly before park
  3. Printer is ready for filament change

Scenario 2, after 1 above (not working)

  1. Initiate filament change after steppers timeout like when a print is completed and you've moved the nozzle/bed out of the way to remove a print (XYZ position is unknown)
  2. No homing procedure takes place
  3. Nozzle & bed slam into frame because XYZ position is unknown

Expected behavior:
Printer to home if XYZ positions are unknown.

Actual behavior:
Nozzle & bed crash into frame if XYZ positions are unknown since homing is not completed before the park.

Additional Information

I'm not sure if this feature ever worked correctly since I only just now noticed the issue.

@thisiskeithb
Copy link
Member Author

thisiskeithb commented Apr 23, 2020

Digging through the code some more, I am assuming that !all_axes_known() and axes_need_homing() are the same thing when Marlin treats them differently:

// Axis homed and known-position states
extern uint8_t axis_homed, axis_known_position;
constexpr uint8_t xyz_bits = _BV(X_AXIS) | _BV(Y_AXIS) | _BV(Z_AXIS);
FORCE_INLINE bool no_axes_homed() { return !axis_homed; }
FORCE_INLINE bool all_axes_homed() { return (axis_homed & xyz_bits) == xyz_bits; }
FORCE_INLINE bool all_axes_known() { return (axis_known_position & xyz_bits) == xyz_bits; }
FORCE_INLINE void set_all_unhomed() { axis_homed = 0; }
FORCE_INLINE void set_all_unknown() { axis_known_position = 0; }

So what is the original intention of HOME_BEFORE_FILAMENT_CHANGE? Was it to:

  • Only home axes if it hasn't homed after power up or
  • Home if XYZ position is unknown?

Swapping out axes_need_homing() for !all_axes_known() seems like a logical fix:

#if ENABLED(HOME_BEFORE_FILAMENT_CHANGE)
  // Don't allow filament change without homing first
  if (!all_axes_known()) home_all_axes();
#endif

With the fix above, the printer homes if

  1. It hasn't homed yet or
  2. If XYZ position is unknown

Now the hotend and bed no longer crash into the frame 🥳

This also ties into feature request #16307 that I commented on a while ago about this very issue when I thought they were the same thing.

@thisiskeithb thisiskeithb changed the title [BUG] HOME_BEFORE_FILAMENT_CHANGE doesn't work after M18/Disable steppers [BUG] HOME_BEFORE_FILAMENT_CHANGE doesn't work after steppers timeout Apr 23, 2020
@thisiskeithb
Copy link
Member Author

PR #17681 resolves this issue.

@github-actions
Copy link

github-actions bot commented Jul 2, 2020

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.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant