ABL issue with probe offset

[lavato]

Am I missing something here?

I have an issues where I cannot configure and then set the Z offset correctly, when auto bed leveling is enabled.

Issue 1:

After issuing G28, M114 reports:
RECV: X:65.00 Y:95.00 Z:0.00 E:0.00 Count X: 4622 Y:6755 Z:0
=>As expected

Then I issue G92Z10 & M114, I get:
RECV: X:65.00 Y:95.00 Z:10.00 E:0.00 Count X: 4622 Y:6755 Z:3984
=>As expected

However Z cannot be moved down after the above (if I move it up then Z is correctly set to 11):

SENT: G91
SENT: G1 Z-0.1 F201
SENT:RECV: ok
G90
SENT: M114
RECV: ok
RECV: ok
RECV: X:65.00 Y:95.00 Z:10.00 E:0.00 Count X: 4622 Y:6755 Z:3984
RECV: ok

Issue 2:

After G28, Z refuses to obey the "Z_PROBE_OFFSET_FROM_EXTRUDER" , essentially I cannot lover the hotend no matter what value I put

I am using:

RC6, Ramps 1.4, MEGA, Full discounted LCD & proximity sensor

[jbrazio]

Let's suppose that the offset from your probe to the bed after a G28 is 1.3mm.
You should set the offset using M851 and not with G92.

; Set the offset
G28
M851 Z-1.30
M500

; Check if the settings are saved
M501
; echo:Z-Probe Offset (mm):
; echo:  M851 Z-1.30

; Test the offset
G28  ; After the G28 your Z should be 1.30
G0Z0 ; Your nozzle should now be touching the bed

[lavato]

Thank you for posting so quickly.

I would like to clarify that I did not want to use G92 to set the offset but merely to allow me to move down to see how much the offset should be, so I can set it in the Config file.

I understand M851 has priority over z probe offset.
But I still think the above issue is still a problem, as setting z probe offset and G92Z10 does not seam to behave as expected.

The intent was to apply the settings in the configuration.h, so G28 will just work without having to do M851Z-0,40 (in my case), M500 at the beginning and then G28+G0Z0 on every print?

=>>Do you know how this offset can be saved in the configuration.h file?

To do that, only the z probe offset should be set, would't you say?:
e.g.
#define Z_PROBE_OFFSET_FROM_EXTRUDER -0.4

• I think that after issuing G92Z10 you should be able to move down
• and that after setting z probe offset in the config, the setting should be reflected in the g28, as also per Toms Proximity sensor guide

=>>Your suggestion did work and I would use it until I find a way to save in the config, Thank you..

[jbrazio]

You're getting it wrong.. G92 has nothing to do with Z-Probe Offset, G92 is Set Position, M851is Set Z-Probe Offset.

Setting the Z-Probe Offset using M851 or #define Z_PROBE_OFFSET_FROM_EXTRUDER is basically the same thing, you just have to keep in the back of your mind that the value in EEPROM (M851) overrides the value on the config file (Z_PROBE_OFFSET_FROM_EXTRUDER).

The G-Code I gave you saves the value of M851 by using M500 Store parameters in EEPROM, you don't have to repeat all the steps.. to apply the offset once it is saved on EEPROM is just a question of doing a G28.

[lavato]

I posted my comment before finishing by mistake....

I wanted to clarify that I did not want to use G92 to set the offset but to allow me to move down Z axes to see how much the offset should be for the #define Z_PROBE_OFFSET_FROM_EXTRUDER

RE: your comment above:
Much clearer now, thank you. I have saved my offset in the config, however I still have to do G28 + G0Z0 so the nozzle touches the heat bed.

Do you know what needs to be done in configuration.h so the G0Z0 does not need to be added to startup after g28?

[Blue-Marlin]

Due to the lott of different probes we support the end position of G28 is currently undefined. There is no possibility to adjust that in the Configs.
However, the solution is not that difficult.

  #if ENABLED(DEBUG_LEVELING_FEATURE)
    if (DEBUGGING(LEVELING)) {
      SERIAL_ECHOLNPGM("<<< gcode_G28");
    }
  #endif

+  destination[X_AXIS] = current_position[X_AXIS];
+  destination[Y_AXIS] = current_position[Y_AXIS];
+  destination[Z_AXIS] = 0;
+  line_to_destination();
+  stepper.synchronize();
+
  report_current_position();
}

at the end of gcode_G28() in Marlin_main.cpp

[Blue-Marlin]

If we want that in general is another question. I don't think so.

[jbrazio]

however I still have to do G28 + G0Z0 so the nozzle touches the heat bed.

It depends.. if you want to really see the nozzle touching the bed then yes, on the other hand on a day to day print situation Marlin with printing fine with nothing more than a G28 and a well set Z_PROBE_OFFSET_FROM_EXTRUDER.

You may follow @Blue-Marlin's suggestion if you want to have the nozzle always touching the bed after a G28, but I can't really see the reason why.

[brainscan]

I really don't understand why this sudden need to have the nozzle touching the bed after homing, mbl has been changed to do the same thing but I cannot think of a situation where this is desirable.

Sent from my iPhone

On 16 May 2016, at 03:00, João Brázio [email protected] wrote:

however I still have to do G28 + G0Z0 so the nozzle touches the heat bed.

It depends.. if you want to really see the nozzle touching the bed then yes, on the other hand on a day to day print situation Marlin with printing fine with nothing more than a G28 and a well set Z_PROBE_OFFSET_FROM_EXTRUDER.

You may follow @Blue-Marlin's suggestion if you want to have the nozzle always touching the bed after a G28, but I can't really see the reason why.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[epatel]

@brainscan I think the original requester said that some host software, Repetier-Host or similar defaulted to 0,0,0 after homing and MBL would then make the printer differ from what was expected.

[brainscan]

Shouldn't they have fixed that in the host rather than breaking it for everyone else? I stopped using repetier after problems like that with ABL. Sorry but I want my printer to recognise my end stops when homing as that's what they are for.

Sent from my iPhone

On 16 May 2016, at 13:40, Edward Patel [email protected] wrote:

@brainscan I think the original requester said that some host software, Repetier-Host or similar defaulted to 0,0,0 after homing and MBL would then make the printer differ from what was expected.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[epatel]

@brainscan Well, technically G28 means travel to a "home position" according to the g-code standard, where any XYZ arguments is considered an intermediate position before going to "home". Well, lets say this is not how it works for 3D printers in general. Some want it one way and some another and there is actually no real standard in use (I think). I hear your pain. Would like to help fix this, if and when I can.

G-Code standard RS274, https://en.wikipedia.org/wiki/G-code
And RepRap 3D Printers has a slight flavor to it http://reprap.org/wiki/G-code (and I guess there can be some room for interpretation)

Original requester https://github.com/MarlinFirmware/MarlinDev/issues/162

[Blue-Marlin]

Repetier-Host or similar defaulted to 0,0,0 after homing and MBL would then make the printer differ from what was expected.

All is needs to keep RH in sync, is to send a report_current_position() at the end of (G29 MBL)

    } // switch(state)
    report_current_position();
  }

#elif ENABLED(AUTO_BED_LEVELING_FEATURE)

[epatel]

@Blue-Marlin Sounds good, if it works. I don't use RH so I can't test.

[brainscan]

I understand what you're saying, I just always though home should be where the end stops are and a park position should be where you want the nozzle afterwards. Like you said having so many different views on things is confusing. I wish I could fix it myself, maybe when I'm finished at college I'll try and learn some code but it's pretty daunting at the moment especially with things changing so often. Sorry if I'm sounding really negative as I love mbl and really appreciate all the work everyone has done, just struggling to set things back up and can't afford to break anything at the moment.

Sent from my iPhone

On 16 May 2016, at 13:58, Edward Patel [email protected] wrote:

@brainscan Well, technically G28 means travel to a "home position" according to the g-code standard, where any XYZ arguments is considered an intermediate position before going to "home". Well, lets say this is not how it works for 3D printers in general. Some want it one way and some another and there is actually no real standard in use (I think). I hear your pain. Would like to help fix this, if and when I can.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[jbrazio]

@epatel @Blue-Marlin should I re-open this and mark it as a bug ?

[epatel]

@jbrazio I see this as a feature request to i.e. have a configurable G28 behavior. @Blue-Marlin suggestion is good too I think, as a safe step host software can utilize.

1. Add the report_current_position()
2. Configurable G28, leave at endstops or travel to 0,0,0

[I think both view have merit so why not facilitate both]

[Blue-Marlin]

For a lot of g-codes we introduced the report recently. Somehow we forgot G29(MBL).

G28 ending at [0,0,0] seem not to be a good idea to me. I already hear them screaming - My nozzle is scratching the bed when i move in x/y.

[jbrazio]

@epatel or @Blue-Marlin do you mind to submit a PR to address this ? Thanks.
I've reopen this as a bug, please reference the ID on the PR.

-edit-
At least for the report_current_position(), I agree with @Blue-Marlin on this:

I already hear them screaming - My nozzle is scratching the bed when i move in x/y.

[lavato]

@Blue-Marlin I will try your code later tonight. Thank you!

Sorry this has caused so much turbulence.

A configurable G28 sounds like a compromise (you ether take offset into account or not)

G28 not homing to Z 0 means that you would have to have a printer plugged into to a computer to be able to check if the distance between a Bed and a Nozzle is correct.
In my case I don't normally connect the printer to a computer but just print from an SD card.

Also do you think Issue 1 is also a Bug?

[jbrazio]

@lavato actually none of your initial issues are really "bugs", the bug we found on this ticket was a condition where we don't keep the host in sync.

[lavato]

@jbrazio

Can you just help me understand below 3 points?:

• Issue 1: if Z is at 0 and and I issue G92Z10, you are saying that I should not be able to move down after issuing G91 & G1 Z-0.1 F201? (this is not the case in 1.0.2)
• Issue 2: For G28, you suggest that normal behaviour should be for it not to take into account the offsets?
• What will " kept the host in sync" actually address?

[Blue-Marlin]

For 1: see #3647
For 3: With a host in sync at least ReperierHost knows about we are not at zero and RHs software endstops do not hinder us go lower.

[jbrazio]

@lavato G28 is taking into account the offsets, if you have a Z_PROBE_OFFSET_FROM_EXTRUDER in place when G28 finishes you actual Z-pos will be |Z_PROBE_OFFSET_FROM_EXTRUDER|.

Let me try to explain why I believe this is the correct behavior:

The most obvious reason: if G28 leaves the nozzle at Z0 if a user tries to move the nozzle using G0 X10Y10 it will drag across the bed.

G28 must not be interpreted as "move the nozzle to home on each axis" but as "find the home position foreach axis" and finding the home position does not mean we have to stop at (0, 0, 0), the correct command for that is G0 X0Y0Z0.

G28 Z0 basically tells the robot to start moving in negative Z until a probe interrupts the movement, when this interrupt is fired it means we have found the ZERO of the bed and the movement is stopped. Now that we know the Z0-bed we can apply the probe-offset thus the current Z-pos will be reported as |Z_PROBE_OFFSET_FROM_EXTRUDER|.

[lavato]

@Blue-Marlin Thank you

@jbrazio
I do see the logic in what you are saying, I guess it depends on the way you work with your printer.

On another note, I think found another problem:
When I specify an offset using M851, all works OK and the new offset can be seen via LCD (Control -> Motion -> Z offset) or when issuing M501.

However when setting Z_PROBE_OFFSET_FROM_EXTRUDER to a new value and uploading the Firmware, the old value saved in EPROM remains.

This can also be checked ether via LCD or by issuing M501,

Can you confirm this is an issue?

[jbrazio]

However when setting Z_PROBE_OFFSET_FROM_EXTRUDER to a new value and uploading the Firmware, the value saved in EPROM remains.

Exactly, in fact I will quote myself:

Setting the Z-Probe Offset using M851 or #define Z_PROBE_OFFSET_FROM_EXTRUDER is basically the same thing, you just have to keep in the back of your mind that the value in EEPROM (M851) overrides the value on the config file (Z_PROBE_OFFSET_FROM_EXTRUDER).

[lavato]

But I flushed the MEGA after setting M851.

I would expect that the previously set value using M851 would be overwritten by flashing the firmware with the value set by Z_PROBE_OFFSET_FROM_EXTRUDER.

Would't you say?

[jbrazio]

Flashing does not erase the EEPROM.
After flashing if you want to revert to the values on the configuration file you must do:

M502 ; factory settings
M500 ; save to EEPROM

[lavato]

Of course - Thank you !!!

[jbrazio]

#3775 closes this.
@lavato if you have any more questions please open a new issue, cheers.

[lavato]

@Blue-Marlin Thank you

[thinkyhead]

Flashing does not erase the EEPROM.

Sometimes it will. If the stored EEPROM has a different layout (EEPROM version number) than the version being flashed, the EEPROM will be reset to defaults on the first boot.

[github-actions]

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.