search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.14k stars 19.2k forks source link

[BUG] Excessive delay when homing #25112

Closed VanessaE closed 1 month ago

VanessaE commented 1 year ago

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

Yes, and the problem still exists.

Bug Description

When homing any axis, there is a brief pause of approximately 1.3 seconds before any motor starts moving.

I could understand there being a delay if the machine needed to deploy a probe to home Z (as mine does, with a BLTouch clone), but this happens with X or Y homing alone, as well. That is, if I home X, the printer just sits there doing absolutely nothing for a second, then it homes X. It's the same for all axes, in any combination. If I home X, and then separately, immediately home Y, each such action gets a pause.

It used to be that homing would start X and/or Y moving without any delay. Of course, the printer still had to pause to deploy the probe prior to homing Z, but that would only happen if Z homing was actually requested, and only after the toolhead had already moved to its "safe homing" X/Y position.

I considered the possibility that this pause is somehow a servo or BLTouch command delay, but the pause happens when there's simply no obvious reason, and it lasts for over one full second.

Bug Timeline

It's old, but unclear when it started.

Expected behavior

I expected the printer to start moving as soon as it gets a home command.

Actual behavior

It waited before moving.

Steps to Reproduce

I am unsure how to reliably reproduce this other than for someone to use my configs and just putter around with a couple of motors and endstop switches, hoping to see it misbehave.

I can only say for sure that it didn't happen on this printer (my "small" one) until after I updated it to v2.1.2, just today.

There are a couple of notes that may be helpful:

  1. Originally on my BIG printer, homing was snappy on there as on the small printer, without unusual delays. A motherboard failure forced me to upgrade that machine from SKR v1.4 to SKR v2, so obviously I had to update the firmware then too. That was some time back, but it was then that this homing delay first appeared on that machine. That printer still has v2.0.9.3 on it.

  2. The small printer, that is the one that I updated Marlin on today, also had v2.0.9.3 before this update, or at least that's what my previous copy of the source tree shows. Yet then, with the same version of Marlin as the big machine still runs, homing behaved normally, without delays. That machine still runs on an SKR v1.4.

So, the Marlin version alone isn't enough to nail down when this started, and it's not motherboard-related, so it's surely something in my configuration, right?

I don't update very often (if it ain't broke, don't fix it), and Marlin moves so fast or so far at times that my config files simply fall out of compatibility between updates, forcing me to commit my changes, do git format-patch HEAD~1 to back-up my changes, and then re-clone and reconfigure from scratch, using that patch file as a guide.

So I must accept the possibility of a configuration mistake, but this happens on two machines, so that seems like too simple of an answer (and would not be particularly useful since I wouldn't know what to look for).

Could it be something that one wouldn't normally even look at, let alone change? Perhaps some item that's always been commented-out, which had a default (hard-coded) value at one time that worked for my setup, but which has since changed?

Someone might ask about my EEPROM settings: no worries there, those always apply just fine to a new build (before flashing, I'll do M503, copy&paste the output into a text editor, and strip off all the "echo:" prefixes, which gives me a file I can save and "print" to restore the settings).

Version of Marlin Firmware

2.1.2, 2.0.9.3

Printer model

custom Hypercubes

Electronics

SKR v1.4 & SKR v2

Add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Other (explain below)

Host Software

Pronterface

Don't forget to include

Additional information & file uploads

Build configs from the new version on the small machine, where homing has this pausing issue: Marlin-configs-small-machine-2.1.2-20221218.zip

Build configs from the previous version on the small machine, when homing didn't have unusual pauses: Marlin-configs-small-machine-2.0.9.3-20220406.zip

Build configs from the BIG machine, which also has the pausing issue: Marlin-configs-BIG-Machine-2.0.9.3-20220406.zip

Log output from homing X ``` >>> m111 s247 SENDING:M111 S247 echo:DEBUG:ECHO,INFO,ERRORS,COMMUNICATION,DETAIL echo:M105 echo:M105 echo:G28 X0 >>> G28 X100.00 Y100.00 Z5.95 Machine Type: CoreCartesian Probe: BLTOUCH Probe Offset X22.00 Y0.00 Z-0.95 (Right-Center & Below Nozzle) Auto Bed Leveling: BILINEAR (disabled) >>> set_bed_leveling_enabled X100.00 Y100.00 Z5.95 <<< set_bed_leveling_enabled X100.00 Y100.00 Z5.95 Raise Z (before homing) by 4.00 >>> do_blocking_move_to X100.00 Y100.00 Z5.95 > X100.00 Y100.00 Z5.95 <<< do_blocking_move_to X100.00 Y100.00 Z5.95 BLTouch Command :160 BLTouch Command :90 >>> homeaxis(X) Home Fast: -313.50mm >>> do_homing_move X100.00 Y100.00 Z5.95 ...(X, -313.50, [200.00]) <<< do_homing_move X100.00 Y100.00 Z5.95 Move Away: 5.00mm >>> do_homing_move X100.00 Y100.00 Z5.95 ...(X, 5.00, [200.00]) <<< do_homing_move X100.00 Y100.00 Z5.95 Re-bump: -10.00mm >>> do_homing_move X100.00 Y100.00 Z5.95 ...(X, -10.00, 100.00) <<< do_homing_move X100.00 Y100.00 Z5.95 >>> set_axis_is_at_home(X) Axis X home_offset = 0.00 position_shift = 0.00 > home_offset[X] = 0.00 current_position= X-3.00 Y100.00 Z5.95 : <<< set_axis_is_at_home(X) current_position= X-3.00 Y100.00 Z5.95 : sync_plan_position current_position= X-3.00 Y100.00 Z5.95 : > AFTER set_axis_is_at_home <<< homeaxis(X) current_position= X-3.00 Y100.00 Z5.95 : sync_plan_position <<< G28 X-3.00 Y100.00 Z5.95 echo:M114 ```

Video showing the glitch: https://youtu.be/LQZBCnrMEWI

thisiskeithb commented 1 year ago

I'm not sure I'd call a 1.3 second delay "excessive", but I can reproduce the delay on a couple builds with various probes with the latest bugfix-2.1.x:

Prusa MK3S+ Bear

_BTT002 (STM32F4) with a PINDA probe (FIX_MOUNTED_PROBE)_

Ender-3

SKR E3 Turbo (LPC1769) with a genuine BLTouch (BLTOUCH)

Biqu B1 SE Plus

_SKR 2 (STM32F4) with a strain gauge hotend (NOZZLE_AS_PROBE + PROBE_ENABLE_DISABLE)_

Biqu Hurakan

_Manta M4P (STM32G0) with a Biqu MicroProbe (BLTouch-like, not a clone) (FIX_MOUNTED_PROBE + PROBE_ENABLE_DISABLE)_

I'm still updating my machines to the latest bugfix-2.1.x, so I'll have some more data later.

VanessaE commented 1 year ago

Yeah maybe "excessive" is...erm... excessive, but I couldn't think of a better word :smile:

fiveorders commented 1 year ago

I have a pause before Z homing after XY homing. It waits a couple of seconds, and I cannot turn this off, any ideas?

github-actions[bot] commented 1 month ago

Greetings from the Marlin AutoBot! This issue has had no activity for the last 90 days. Do you still see this issue with the latest bugfix-2.1.x code? Please add a reply within 14 days or this issue will be automatically closed. To keep a confirmed issue open we can also add a "Bug: Confirmed" tag.

Disclaimer: This is an open community project with lots of activity and limited resources. The main project contributors will do a bug sweep ahead of the next release, but any skilled member of the community may jump in at any time to fix this issue. That can take a while depending on our busy lives so please be patient, and take advantage of other resources such as the MarlinFirmware Discord to help solve the issue.