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
15.94k stars 19.08k forks source link

[BUG] G28 causes incorrect Z-axis 0-point when using KlackEnder #27038

Open Yangff opened 2 weeks ago

Yangff commented 2 weeks ago

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

Yes, and the problem still exists.

Bug Description

I did some modifications to my Ender3 Pro and then I ran into strange problems. When homing with the G28, the print head would move to the center and then correctly probe z0's position and then lift up a distance. Next, it raises to Z=20 and move to the far right, however, at this point the printer will not correctly move the print head to Z=0 to stow the probe, instead it will try to stow the probe at Z=20 and stop there, as it failed. Even more strangely, this Z=20 showing on the display is not really Z=20, and if I open the motion menu at this point and move the print head to what the printer thinks is Z=0, the print head is a relatively large distance from the build plate.

photo_2024-05-01_03-30-07

As you can see here, at least after the probe ends, it marks the current Z as -1.2 (which is the correct 0+offset). The Z0 is still correct at this time. And then stow fails. The latter is when I use g0 to move Z to 0, but the print head doesn't move to 0.

Eventually I found that if I commented out if (TERN0(HOMING_Z_WITH_PROBE, axis == Z_AXIS && probe.stow())) return; and manually stowed the probe using the M402 at the end of the homing, at least the stow would do it correctly and the Z0 is right. I haven't tested if there will be any other problems when actually printing, but at least the homing is correct.

Bug Timeline

at least 2.1.2.1

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

I think repro this issue might be difficult because I modded more things. Everything worked fine when I started out with the KlackEnder, then I replaced the extruder, the fan, and then it started not working. Even with the same 2.1.2.1 firmware.

I'm not quite sure what exactly is besides the problem, or if it's a combination of them that are causing the problem, I'd like to get some direction on debugging the problem, not that I can tell much from the current log.

My guess is that the firmware may have lost the result of one move for some reason and retreated the subsequent position as Z=0, but I'm not sure when this happened.

Version of Marlin Firmware

2.1.2.2

Printer model

Creality Ender-3 Pro

Electronics

BOARD_CREALITY_V4

LCD/Controller

CR10_STOCKDISPLAY

Other add-ons

No response

Bed Leveling

UBL Bilinear mesh

Your Slicer

None

Host Software

None

Don't forget to include

Additional information & file uploads

config.zip

thisiskeithb commented 2 weeks ago

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

Yangff commented 2 weeks ago

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

I've actually never successfully booted with code under the bugfix branch. There is no output from the display and no output from the serial port. I'm guessing it's a configuration item, because if I turn on MARLIN_DEV_MODE in the release branch it does the same thing.

Hmm.. seems for some reason the firmware.elf it's building is not having correct vaddr?

readelf -l ./firmware.elf

Elf file type is EXEC (Executable file)
Entry point 0x80090f1
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08000000 0x08000000 0x361c4 0x361c4 RWE 0x10000
  LOAD           0x040000 0x20000000 0x080361c4 0x002d0 0x021c8 RW  0x10000
  LOAD           0x0421c8 0x200021c8 0x200021c8 0x00000 0x00600 RW  0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .isr_vector .text .rodata .init_array .fini_array 
   01     .data .bss 
   02     ._user_heap_stack

I think it should be at 0x08007000?

ellensp commented 2 weeks ago

Entry point 0x80090f1
Its an elf, its relocatable to correct address when bin is generated. This is fine

Much more likely you haven't checked what chip you have The build environment you choose is stm32f103re or rc, the rc has a lot less flash and less ram. building for a rc on a re chip works fine, but building for a re on a rc chip will not boot.

And the gd32 chip is just an incompatible nightmare...

So Identify your chip.

Yangff commented 2 weeks ago

Entry point 0x80090f1 Its an elf, its relocatable to correct address. This is fine

Much more likely you haven't checked what chip you have The build environment you choose is stm32f103re or rc, the rc has a lot less flash and less ram. building for a rc on a re chip works fine, but building for a re on a rc chip will not boot.

And the gd32 chip is just an incompatible nightmare...

So Identify your chip.

I‘m pretty sure it's a RC, the env I'm using is STM32F103RC_creality. The bin is 190kb and the largest binary I have used with 2.1.2.1 is ~200kb so I don't think either is a problem.

The elf is not relocatable, as you can see the file type is EXEC..

ellensp commented 2 weeks ago

you cannot build with STM32F103Rx_creality on real marlin, its an internal name. If it does not start with env: at the front you cannot use it as a build environment

ELF files are Executable Linkable Format which consists of a symbol look-ups and relocatable table, that is, it can be loaded at any memory address by the kernel and automatically, all symbols used, are adjusted to the offset from that memory address where it was loaded into. Usually ELF files have a number of sections, such as 'data', 'text', 'bss', to name but a few...it is within those sections where the run-time can calculate where to adjust the symbol's memory references dynamically at run-time.

You don't even use the elf. Its an intermediate file

You use the .bin generated from the elf file

Yangff commented 2 weeks ago

stm32f103re

Correction: I looked at the photo and it's actually RE, so that should more than likely not be an issue.

STM32F103Rx_creality

I was copying from the config and what I meant to say is RC.

Yangff commented 2 weeks ago

I printed some logs..

DEBUG: homeaxis Z
>>> homeaxis(Z)
  current_position= X102.00 Y91.00 Z5.00 : Probe::set_deployed
deploy: 1
  current_position= X102.00 Y91.00 Z5.00 : Debug: Before z raise
Probe::do_z_raise(10.00)
echo:busy: processing
  current_position= X102.00 Y91.00 Z10.00 : Debug: After z raise
  current_position= X102.00 Y91.00 Z10.00 : Debug: old_xy
Home Fast: -375.00mm
Debug: Axis set to zero
echo:busy: processing
echo:busy: processing
Move Away: 5.00mm
Debug: Axis set to zero
echo:busy: processing
Re-bump: -10.00mm
Debug: Axis set to zero
echo:busy: processing
Re-bump done
Debug: Setting...
Debug: Axis Z is at home
  current_position= X102.00 Y91.00 Z-1.20 : sync_plan_position
  current_position= X102.00 Y91.00 Z-1.20 : > AFTER set_axis_is_at_home
  current_position= X102.00 Y91.00 Z-1.20 : Probe::set_deployed
deploy: 0
  current_position= X102.00 Y91.00 Z-1.20 : Debug: Before z raise
Probe::do_z_raise(10.00)
echo:busy: processing
  current_position= X102.00 Y91.00 Z10.00 : Debug: After z raise
  current_position= X102.00 Y91.00 Z10.00 : Debug: old_xy
  current_position= X102.00 Y91.00 Z10.00 : Debug: Before probe_specific_action
  current_position= X102.00 Y91.00 Z10.00 : Debug: Before stow step 1
echo:busy: processing
echo:busy: processing
  current_position= X245.00 Y114.00 Z20.00 : Debug: After stow step 1
  current_position= X245.00 Y114.00 Z20.00 : Debug: Before stow step 2
  current_position= X245.00 Y114.00 Z0.00 : Debug: After stow step 2
  current_position= X245.00 Y114.00 Z0.00 : Debug: Before stow step 3
  current_position= X220.00 Y114.00 Z0.00 : Debug: After stow step 3
  current_position= X220.00 Y114.00 Z0.00 : Debug: Before stow step 4
echo:busy: processing
echo:busy: processing
  current_position= X220.00 Y114.00 Z20.00 : Debug: After stow step 4
  current_position= X220.00 Y114.00 Z20.00 : Debug: After probe_specific_action
Error:Z-Probe failed
Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
  current_position= X220.00 Y114.00 Z20.00 : sync_plan_position
X:220.00 Y:114.00 Z:20.00 E:0.00 Count X:17600 Y:9120 Z:8000
ok

For some reason those

  current_position= X245.00 Y114.00 Z0.00 : Debug: After stow step 2
  current_position= X245.00 Y114.00 Z0.00 : Debug: Before stow step 3

are not executed on z-axis, but the printer thought they are done. Any idea why this could happen? something to do with the planner? or is there a way I can dig into this..?