Closed universam1 closed 8 years ago
How are you seeing this manifested? What are your settings for:
#define Z_PROBE_DEPLOY_HEIGHT 15 // Z position for the probe to deploy/stow
#define Z_PROBE_TRAVEL_HEIGHT 5 // Z position for travel between points
…and what is your probe Z offset from M851
and Z_PROBE_OFFSET_FROM_EXTRUDER
?
Because the above settings must be larger than your probe offset. For example, if your probe Z offset is -10 then your Z_PROBE_DEPLOY_HEIGHT
and Z_PROBE_TRAVEL_HEIGHT
should be
10 + the_amount_to_raise
If you compile with DEBUG_LEVELING_FEATURE
and use M111 S255
to turn on maximum logging, you will be able to see in the log how the homing/leveling procedures are handled.
We used to have these raise values automatically apply above the probe offset, which was my preference, but some of the regular contributors suggested that this was confusing so it was changed. Unfortunately we cannot check this at compile-time. And if we added logic to override a too-small value that might also be confusing.
For ease of configuration and additional clarity, you might set these like so:
#define Z_PROBE_OFFSET_FROM_EXTRUDER -11.3
. . .
#define Z_PROBE_DEPLOY_HEIGHT (-(Z_PROBE_OFFSET_FROM_EXTRUDER) + 6) // Z position for the probe to deploy/stow
#define Z_PROBE_TRAVEL_HEIGHT (-(Z_PROBE_OFFSET_FROM_EXTRUDER) + 3) // Z position for travel between points
@epatel
I have a side question on this topic. Does anybody know the history of why Mesh Bed Leveling added its own z_offset variable for the Mesh?
In the initial devel_ubl implementation, I tried to preserve the lowest levels of the Mesh Bed Leveling as much as possible. But it seems like it would be cleaner to eliminate it and just make use of the zprobe_zoffset (that defaults to Z_PROBE_OFFSET_FROM_EXTRUDER).
@thinkyhead When you have a few moments, this is a related Z-Offset issue that would be good for us to all think about: https://github.com/thinkyhead/Marlin/commit/b24fb2834d044266bb15f95a8c7d79be9fa1bc27#commitcomment-18782273
Maybe because mesh doesn't require a probe so it would have been confusing.
Sent from my iPhone
On 26 Aug 2016, at 21:39, Roxy-3D notifications@github.com<mailto:notifications@github.com> wrote:
I have a side question on this topic. Does anybody know the history of why Mesh Bed Leveling added its own z_offset variable for the Mesh?
In the initial devel_ubl implementation, I tried to preserve the lowest levels of the Mesh Bed Leveling as much as possible. But it seems like it would be cleaner to eliminate it and just make use of the zprobe_zoffset (that defaults to Z_PROBE_OFFSET_FROM_EXTRUDER).
You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/4708#issuecomment-242845572, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACHemJcsCkJKD3wJK3poXtWAoJJsXkKrks5qj08QgaJpZM4JuUG0.
That what happens when you get too close to the forest. You can't see the trees!
Thanks!
When you have a few moments
I replied to that comment, but it ended up at https://github.com/MarlinFirmware/Marlin/pull/4670#issuecomment-242618312
@Roxy-3D I added the z_offset
because MBL was manual in the beginning, and when doing the measuring some times one maybe was probing too close and other times too loose, i.e. how one was "feeling" the paper during the measuring. Sure one could use some else Z offset, but it felt best to add an offset for MBL close to what one was doing, so to speak. I think an overall offset still can be good to have, as probing will give a good sampling of the shape, but the getting a "real" good overall level might be easier to tune with a configurable offset.
That's why it was also added to the "Tune" menu so one could change it while printing.
Thanks! With the extra information, I'm leaning towards leaving both z_offset and zprobe_zoffset in place.
@Roxy-3D I see it a little like this. The most important thing is that probing should be consistent while probing, meaning it is important that the points are sampled relative to each other. The the probe offset can be different from probing the whole bed, i.e. the probe could be manually attached etc. In my own auto version of MBL (minimalistic probe setup) http://www.thingiverse.com/thing:1120142 I added a menu option to manually probe this offset after the bed had been probed with the auto probe sequence (and I had detached the probe). As long as the probe was firmly attached it wasn't actually important how far I pushed it onto the hotend (cold), just that it didn't move while probing.
Yes. Prior to me asking the question, I was confused because it seemed like we had duplicate functionality. But I agree. There are separate issue here. And at the root of the confusion was what BrainScan said: I was forgetting that Mesh Bed Leveling was setup to work without a probe (even though I was being careful to preserve that capability).
Thanks @thinkyhead very much for the detailed description and the backgrounds!
I went ahead and set up my settings according your proposal, you can have a look at them altogether at https://github.com/universam1/Marlin/tree/RCBugFix Anyway, it is definitely broken! M851 has actually no impact on the offset anymore!
After a lot of tryings I though realize that the eeprom settings for "Z-home offset" are used instead of the "Z-probe offset". With this I can at least get my printer up and running again, although this is not a solution.
I understand that there is consistancy of code a goal, but I assume this logic at least hast to be mentioned somewhere or even moved to configuration_adv.
Thanks for fixing!
the eeprom settings for "Z-home offset" are used instead of
EEPROM settings are always reloaded at boot. M851 is one setting that is saved and restored. If you don't issue M500 after M851 then it isn't saved to EEPROM.
Try this. Do M851 Z-11.3
to set your offset. Then do M503 S0
to see what value is set. Then do M500
to save it. Then reboot. Then do M503 S0
and it should be the value that you saved.
Absolutely, I made sure that it is saved and reloaded. For sake of test I even restarted Marlin.
The M851 I've pointed out to make clear that I'm talking about the z probe offset that I can reach also via the settings in display conveniently. This one is broken now. The one that is now used is the z home offset which is not reachable via display. Does this make sense?
Edit: hypothetical, can't test it right now, does M851 value react only to negative values??
M851 value react only to negative values??
No, one can set positive values for M851. This applies usually when the nozzle is the probe and needs to press down a little to engage a switch.
M851 has actually no impact
@universam Did I already request a log? Enable DEBUG_LEVELING_FEATURE
then do M111 S255
before G28
and G29
. Post the log output here so we can see what's happening.
@thinkyhead thanks for heads up on this issue! BTW. I've tried with negative values, no change. I'm on very latest commit 2cb63f0bf7ca7b8d1af2070a8c127c7a9663824c
OK here is the output with debug enabled. For info, M851 is set to -0.9:
@universam1 Your log doesn't show the homing of the Z axis. That's kind of important! Can you please log it again, this time with a full G28
?
I note from the G29
log that your probe is being triggered when your nozzle is between 5.99mm and 6.32mm above the bed. So your Z_PROBE_OFFSET_FROM_EXTRUDER
should be set somewhere in-between, maybe -6.16 or so. (Assuming your Z is homed correctly).
@thinkyhead sure, octoprint's buffer is kind of short... Alright see below.
Z_PROBE_OFFSET_FROM_EXTRUDER cant be set to -6.16 because the define expects integer - so set to -6
I've tried with z-probe set to -4 and 0 and it has no impact on the eventually height of Z. So wouldn't you agree finally that this is a bug, not a support problem? :)
@thinkyhead Looks like I found the root cause of this issue! :smile:
In https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Marlin_main.cpp#L1588
this && Z_HOME_DIR < 0
is negative, thus the current_position[Z_AXIS] -= zprobe_zoffset;
is never executed!
I have no idea why this condition was defined, but in my case it is wrong. Maybe it is related to #4716 as well.
Do you like a MR?
Why do you have Z_HOME_DIR
set to 1 if you are homing to the bed and not to a max Z endstop? Unless you are homing away from the bed, it should be set to -1.
So the root cause of this issue is in your configuration at https://github.com/universam1/Marlin/blob/RCBugFix/Marlin/Configuration.h#L606
One thing I can possibly do is to throw a sanity check for the combination of options that led to this oversight.
#if HAS_BED_PROBE && ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) \
&& (!HAS_Z_MAX || Z_MAX_PIN == Z_MIN_PROBE_PIN) && Z_HOME_DIR > 0
#error "If you're homing with a probe then Z_HOME_DIR must be -1."
#endif
@thinkyhead No, I'm not homing to bed, I'm homing to max Z endstop!
So my Z_HOME_DIR
is set to 1.
Where is my fault? Please explain!
Edit: I've done some tests now, and it works nicely like RC6 before.
How come, twice you have posted logs of G28
in which the Z homing never occurs?
If you are homing to Z max, the position of Z=0 is entirely determined by your Z_HOME_POS
(or Z_MANUAL_HOME_POS
) and has nothing to do with the probe offset whatsoever.
Honestly, I have only this single printer and did not change anything here...
I dont understand your question, lets use this slice from output, thats homing to Z max, doesnt it?
Recv: >>> homeaxis(Z)
Recv: current_position=(0.00, 0.00, 0.00) : sync_plan_position
Recv: > 1st Home280.50
Recv: current_position=(0.00, 0.00, 0.00) : sync_plan_position
Recv: current_position=(0.00, 0.00, 0.00) : sync_plan_position
Recv: > 2nd Home4.00
Recv: >>> set_axis_is_at_home(Z)
Recv: For Z axis:
Recv: home_offset = 0.00
Recv: position_shift = 0.00
Recv: soft_endstop_min = 0.00
Recv: soft_endstop_max = 187.00
Recv: > home_offset[Z] = 0.00
Recv: current_position=(0.00, 0.00, 187.00) :
Recv: <<< set_axis_is_at_home(Z)
Recv: current_position=(0.00, 0.00, 187.00) : sync_plan_position
Recv: current_position=(0.00, 0.00, 187.00) : > AFTER set_axis_is_at_home
Recv: <<< homeaxis(Z)
Recv: >>> homeaxis(Z)
My error there. ⬆️ I was looking for it to occur after XY.
NP, thanks for help!
I made a PR, if you like.
It's not over yet!
Now then, set_axis_is_at_home
should set Z to the Z_HOME_POS
after homing to max. Which it does. Why should it subtract the probe offset?
Good question, I was asking myself the same. But I realized that Z homing_offset is added also at that point, which works (surprisingly)! So since I'm not the inventor of that logic I understand that this offsets the current position. Later in G29 you can see that this is taken into account ....
edit: Basically here the current position is getting offseted:
Recv: current_position=(-9.00, 11.00, 5.92) : <<< run_z_probe Recv: > do_probe_raise Recv: do_probe_raise(11.00)
Let me ask, if you simply do a G28
without this change in the code, and then lower the nozzle down to zero, does the nozzle touch –or nearly touch– the bed?
Later in G29 you can see that this is taken into account
Then the error is (or, would be) in G29
, which is not supposed to molest the Z position, only correct it based on the bed tilt.
sorry cant tell now, not at home. Does it play a role?
If the Z_HOME_POS
is set correctly, then the nozzle will be right up to the bed when you lower it to zero. If the nozzle is too high, then you would need to reduce the value of Z_MAX_POS
(or Z_MANUAL_HOME_POS
) to fix that.
So why then there is the M851 if not to adjust the diff from probe to nozzle?
It's there for the case where you home Z using the probe. When the probe is triggered by proximity or touching the bed, then you know that the nozzle is -zprobe_zoffset
distance from the bed.
It also used to be added to the Z raise before/between probing values, before someone insisted that z height values would be easier to understand.
So the reprap docu says:
Example: M851 Z-4 The example above will set the z-probe offset EEPROM setting to -4mm below the nozzle and enables the nozzle travel 4mm lower than the probe triggered position.
But really, why should you want to limit this nice and great functionality to someone who only does homing via probe? I dont get it really.
Lets explain: I have several different bed plates, like carbon, glas, glas with tape, glas with capton. I change these plates and I loved Marlin with G29 since it was always so clever to detect via probe the tilt but especially the real height. What a blessing! It worked long time nicely, without issues. So I wonder, why should this be removed now?
In fact, homing to the bed with the Z probe is the only place that the M851
(zprobe_zoffset
/ Z_PROBE_OFFSET_FROM_EXTRUDER
) is used any more.
The example above will set the z-probe offset EEPROM setting to -4mm below the nozzle and enables the nozzle travel 4mm lower than the probe triggered position.
Whoever wrote that was tripping. It's wrong. Nothing is "enabled" by the M851
offset.
Please dont get me wrong, but why are you changing this? Marlin was so great ...
Okay I dont have a problem to use home_offset from now on, but then this should be exposed to display and not the M851!!
It's not a change. This is how it's always been. And you don't need to use home_offset
for anything.
Come on, I was printing months with this, and it worked till RC6.
Do as I asked. Home to max. Lower to zero. If the nozzle isn't touching the bed, simply fix your Z_MAX_POS
.
What is it you specifically want to do, other than have the correct Z position upon G28
?
I specifically want to fine tune the bed touch via eeprom since its complicated to flash my printer (octoprint connected in garage) At least via eeprom, but best via Display setting (which is the M851 currently)
I fully respect your great work and decisions! Would it be okay to make a feature request for that then?
fine tune the bed touch via eeprom
I don't know what this means.
I go to display settings --> "Z probe offset" and add or remove a little, press safe EPROM and load EPROM - if I'm not 100% happy with distance of the nozzle to the bed. This might be for instance when I remove the nozzle for maintenance etc.
As far as I have known, the probe offset has never been used in G29
to correct the z distance to the bed. G29
has only ever adjusted the final Z position based on the bed tilt. It may be that I'm missing the fact entirely that it was doing a correction, but truly that section of the code was never documented, and if it was fine-tuning the Z position then that fact was lost on me.
I go to display settings --> "Z probe offset" and add or remove a little, press safe EPROM and load EPROM - if I'm not 100% happy with distance of the nozzle to the bed.
That feature already exists, but it has only (again, as far as I know) applied to homing with the probe, and not to a fine-tuning applied in G29
.
I was coming to it by reading the wiki:
https://github.com/MarlinFirmware/Marlin/wiki/DNE-Bed-Auto-Leveling
n) Fill in the values below. If the endstop mark is in front of the line running left-to-right, use positive values. If it is behind, use negative values. For the Z axis use the value from (k) and subtract 0.1mm. (Note: you can adjust z probe offset via M851) Use M851 to adjust the length Z probe (M851 Z-6.80 if it was -7). Store in EEPROM with M500 and repeat the sequence G28, G29, M114 again. Is the gap bigger then you adjusted the Z probe offset in the opposite direction. So redo M851 Z-something, M500 and repeat G28, G29, M114 and measure (read Z from M114) z at 0.
See, I was going to go to bed early tonight, and now I have to dig through the old code and probably end up slapping my forehead a lot. Because, truly, if G29
was re-writing Z based on the probe distance, I have been missing it for … years now.
ewwww… that wiki is so out of date with 1.1.0. You can't even use G92
that way any more.
I really dont want to blame. Thanks for heads up on this! I can tell, that with this little change everything works like before and ( I ) expected to be.
Really, consider it as one of the best features of Marlin! Basically, forget about Z max pos and any related head crashs, be free and independent to change between bed plates and varying heigts - G29 takes care of it! Just set your nozzle / probe distance correct with M851. I really love it!
Thanks
Well, please understand, in rewriting and trying to unify the bed leveling I made it a maxim not to alter the Z position after G28, and to trust in the home positions set in configuration. Lately I've been feeling like a lot more things should be adjustable. But right now, my priority is in fixing bugs and getting this release out the door.
I don't mind re-examining G29
, as I'm in the middle of this, looking for ways to improve the Z position result once G29
is done. It seems almost obvious that every individual probe in G29
affords an opportunity to determine a more accurate Z position (assuming the probe z offset is good). But then, realize that no point on the bed is definitive. Or, they all are. Which height is the "true" height, and which is just lower or higher than some reference point? Was the home position set correctly? What about the min endstop situation? Is that the "real" zero? And at the end, you have to decide whether the Z position is off, or whether the bed is just high or low at the final XY. It's not cut-and-dried how best to use the probe results to determine Z.
However, we do know that right now in RCBugFix
the Z correction is wrong, and there are various reasons for that, including the addition of Z_SAFE_HOMING
and other factors. That is why I put out this branch and have been asking for testing…
https://github.com/thinkyhead/Marlin/tree/rc_fix_leveling_maths
Marlin now ignores M851 Z-probe offset completely with the latest RCBugFix! Actually, all EEPROM offset settings are ignored by auto bed leveling, that means X and Y are ignored as well. I could help myself by hardcoding these values, but Z is impossible for me.
I tried RCBugFix since I had the same problem with RC7. On RC6 and before it worked.
I've cleared EEPROM so this is not the reason. No matter what I save in EEPROM for M851 or over display, it just will be ignored. Restarted several times.
Please fix since this renders my printer unusable!
Thank you