-
-
Notifications
You must be signed in to change notification settings - Fork 19.1k
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] G28 causes incorrect Z-axis 0-point when using KlackEnder #27038
Comments
Please download |
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. Hmm.. seems for some reason the firmware.elf it's building is not having correct vaddr?
I think it should be at 0x08007000? |
Entry point 0x80090f1 Much more likely you haven't checked what chip you have 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.. |
you cannot build with STM32F103Rx_creality on real marlin, its an internal name. 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 |
Correction: I looked at the photo and it's actually RE, so that should more than likely not be an issue.
I was copying from the config and what I meant to say is RC. |
I printed some logs..
For some reason those
are not executed on z-axis, but the printer thought they are done. |
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.
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
Configuration.h
andConfiguration_adv.h
.Additional information & file uploads
config.zip
The text was updated successfully, but these errors were encountered: