NOZZLE_TO_PROBE -> Code change -> Z probe out bed

[Gruala]

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

Yes, and the problem still exists.

Bug Description

No error is generated. But I humbly believe that it requires some change or improvement in the code.

When you shift the probe to the left and/or right of the nozzle, the code works perfectly. Example: //#define NOZZLE_TO_PROBE_OFFSET { -4.00, 0.00, -1.75 } //Works, Probe 4mm to the left of the extruder. //#define NOZZLE_TO_PROBE_OFFSET { 0.00, -50.00, -1.75 } //Works, probe 50mm in front of the extruder. //#define NOZZLE_TO_PROBE_OFFSET { 0.00, -50.00, -1.75 } //Works. -The code is uploaded to the board, and when you take the nozzle to the origin through the LCD screen, it correctly does the function. Also works well the leveling of the bed with the LCD screen.

When the probe is to the right and/or back of the nozzle the code does not work properly. //#define NOZZLE_TO_PROBE_OFFSET { 4.00, 0.00, -1.75 } //Z probe outside bed //Probe 4mm to the right of the extruder. //#define NOZZLE_TO_PROBE_OFFSET { 0.00, 50.00, -1.75 } //Z probe outside bed //Probe 50mm behind the extruder //#define NOZZLE_TO_PROBE_OFFSET { 4.00, 50.00, -1.75 } //Z probe outside bed . -In any of these cases, when you upload the code to the board, and through the LCD you try to take the nozzle to the origin or home, it tells you that you are out of bed. -Not being able to start the nozzle at 0.0.0 or go home, leveling cannot be done.

Internally the code when the probe is on the left and in front of the nozzle, the program gives the advance to be able to start the dimensions. And when leveling the bed, the displacement is contemplated to be able to level the bed with the LCD screen.

It should be noted that when those two values are positive: -It could start at the origin. 0,0,0. -When the automatic leveling of the bed is done, discount those displacements for the probe, or the points taken do not leave the work area.

I know that command lines can be used for leveling or for other purposes. But as a programmer, I know you can change the code somewhat to improve it. This would have a better and perfect code. Thank you to the work of all of you for contributing for so many years in this.

My workaround is:

define NOZZLE_TO_PROBE_OFFSET { 0.00, 0.00, -1.75 }

define PROBING_MARGIN_BACK 50.00

-That way I can use the function of starting the origin and performing the leveling of the bed. But it's not quite right. It is best to use the actual points and locations in the code.

Bug Timeline

No response

Expected behavior

define NOZZLE_TO_PROBE_OFFSET { 4.00, 50.00, -1.75 }

-Compile. -Upload the code to the board. -Using the LCD screen you could take home the nozzle. "Start in X,Y,Z" -Using the LCD screen you could level the bed.

Actual behavior

define NOZZLE_TO_PROBE_OFFSET { 4.00, 50.00, -1.75 }

-Compile. -Upload the code to the board. -Using the LCD screen you try to take home on the x,y,z axes. But he says the sensor is out of bed. -Not being able to take home the nozzle with LCD, you can not call the function with the LCD "Level the bed"

Steps to Reproduce

define NOZZLE_TO_PROBE_OFFSET { 4.00, 50.00, -1.75 }

-Compile. -Upload the code to the board. -Using the LCD screen you try to take home on the x,y,z axes. But he says the sensor is out of bed. -Not being able to take home the nozzle with LCD, you can not call the function with the LCD "Level the bed"

Version of Marlin Firmware

Marlin-bugfix-2.1.x

Printer model

Custom..Prussia3D / HEPHESTOS. It is a hand-mounted printer. for 8 years I have been riding them completely. Custom.

Electronics

Mega 2560 / Ramps 1.6 Plus / Ramps DRV8825

Add-ons

BLTouch

Bed Leveling

UBL Bilinear mesh

Your Slicer

Cura

Host Software

Cura

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

These tests or reports are with the original code and the last update of the code.

Files: Configuration.zip Configuration_adv.zip

[thisiskeithb]

Did you reset / initialize EEPROM after each upload with M502 followed by M500?

[Gruala]

When the values are neative there is no need to start the EEProm

define NOZZLE_TO_PROBE_OFFSET { -4.00, 0.00, -1.75 } //Works, Probe 4mm to the left of the extruder.

define NOZZLE_TO_PROBE_OFFSET { 0.00, -50.00, -1.75 } //Works, probe 50mm in front of the extruder.

I use the EEProm, I have it activated in the code. But you don't need to use the console for negative values.

[thisiskeithb]

Please try again and reset / initialize EEPROM after each upload with M502 followed by M500

[Gruala]

I will, but if calling the command by console should work. Uploading the code is automatically recorded in the EEProm, but I will try it.

define EEPROM_SETTINGS // Persistent storage with M500 and M501

//#define DISABLE_M503 // Saves ~2700 bytes of flash. Disable for release!

define EEPROM_CHITCHAT // Give feedback on EEPROM commands. Disable to save PROGMEM.

define EEPROM_BOOT_SILENT // Keep M503 quiet and only give errors during first load

if ENABLED(EEPROM_SETTINGS)

//#define EEPROM_AUTO_INIT // Init EEPROM automatically on any errors.

define EEPROM_INIT_NOW // Init EEPROM on first boot after a new build.

endif

[Gruala]

I've done the test. I initialize the EEProm with the command: M502 followed by M500

He keeps saying that the probe is out of bed.. It initializes on the X, Y axes, but on the Z axis it does not start height. As I said, in the same code I have activated the overwriting of the eeprom when I upload the code. And it should work as soon as you upload the code.

start Marlin bugfix-2.1.x echo: Last Updated: 2022-07-04 | Author: (Prussia3D, Marcos Menendez) echo: Compiled: Jul 4 2022 echo: Free Memory: 2678 PlannerBufferBytes: 1472 echo:V86 stored settings retrieved (767 bytes; crc 29931) echo:SD card ok echo:Hardcoded Default Settings Loaded ok echo:Settings Stored (767 bytes; crc 29931) ok Active Extruder: 0 echo:busy: processing echo:busy: processing echo:Z Probe Past Bed Active Extruder: 0 X:0.00 Y:0.00 Z:10.00 E:0.00 Count X:0 Y:0 Z:80000 ok

[Ahmed-Mohiuddin-Shah]

I am also having the same exact problem. ( Z Probe Past Bed )

When I add a positive XY offset for the Z probe, then the Z axis does not home after homing X and Y axis.

But when I add a negative XY offset for the Z probe, then the Z axis does home after homing X and Y axis.

I also adjusted probing margin but it did not work.

Configuration.zip

[Gruala]

With a call that works well with positive values for example:

define NOZZLE_TO_PROBE_OFFSET { -4.00, -50.00, -1.75 }

You are right that when you call the HOMING on the LCD the position of the printer is: X:4.00mm Y:50.00mm and Z:16.75 / or Z:xx.xx

It would take a function to say after calling the homing function... where you want x/y/z or each of the positions separately or all together.

Because the nozzle is not supported in z on the bed... when it starts to heat up... thread escapes when melting. It's something else that would be needed. I know that with Gcode calls it can be done. But in direct code we should have more power to be able to do those things or determine the position with the homing.

I just want to give improvements to make the perfect printer. But in these last 5 years the code has improved a lot. Thank you all. from the heart.

[Ahmed-Mohiuddin-Shah]

I solved my issue by doing the following (btw using Marlin-bugfix-2.1.x):

My z probe offset:

define NOZZLE_TO_PROBE_OFFSET { 27, 5, -1 }

Commented out the following line: // The center of the bed is at (X=0, Y=0) //#define BED_CENTER_AT_0_0

In Z safe homing I added my X and Y offsets:

define Z_SAFE_HOMING

if ENABLED(Z_SAFE_HOMING)

define Z_SAFE_HOMING_X_POINT 27 // X point for Z homing (My X axis Z probe offset)

define Z_SAFE_HOMING_Y_POINT 5 // Y point for Z homing (My Y axis Z probe offset)

endif

I ran a quick test print and it printed successfully without any hiccups with bed leveling.

The Z probe past bed error also went away.

Config file: Configuration.zip

[Gruala]

Hi, Position of the probe to the right and back of the nozzle. The displacement of my printer for the probe is this: No work. #define NOZZLE_TO_PROBE_OFFSET { -4.00, -50.00, -1.75 }

If you define this... you have no problems or error. That's right. And you have no problem. The problem is when you go negative values and try to declare a probe back and right of the nozzle. Code is OK. **#define NOZZLE_TO_PROBE_OFFSET { 27, 5, -1 } ...

define Z_SAFE_HOMING

if ENABLED(Z_SAFE_HOMING)

define Z_SAFE_HOMING_X_POINT (0) // X point for Z homing

define Z_SAFE_HOMING_Y_POINT (0) // Y point for Z homing

endif**

But in either case... in addition to not working the function of Homing, when you do a homing.... the nozzle is not positioned in the 0,0,0 position and you would need a function. This is a separate issue from the programming error. You can fix that when you're printing with Gcode commands. But it would be better if you could define where the mouthpiece stays when doing a homing.

With your configuration if you do a homing.... and you give it value X=0 and Y=0.... it's not going to... **#define Z_SAFE_HOMING_X_POINT (0) // X point for Z homing

define Z_SAFE_HOMING_Y_POINT (0) // Y point for Z homing**

you also stay at X=27 and Y=5

[Ahmed-Mohiuddin-Shah]

Oh Ok! I understand.

I agree it should be able to home the Z axis without doing the following:

define Z_SAFE_HOMING

if ENABLED(Z_SAFE_HOMING)

define Z_SAFE_HOMING_X_POINT 27 // X point for Z homing (My X axis Z probe offset)

define Z_SAFE_HOMING_Y_POINT 5 // Y point for Z homing (My Y axis Z probe offset)

endif

But in this configuration the z axis does seem to home at (0,0,0).

The X axis moves to 0 position, then the Y axis moves to 0 position, then both XY axis do not move when Z axis is homing, so it means that the nozzle is at (0,0,0).

It might be that this safe homing point is the point where the probe should be and not where the nozzle should be.

Have you tried this config?

Also after homing the values for the axis X, Y and Z are 0, so they are at origin.

[Gruala]

After the homing as you say the values are where the nozzle is located. As you say... They may be safe securities. -1° But you should have the possibility to say where the mouthpiece is placed after the homing. As an improvement. -2° It should be possible to place negative values on the probe, do the homing correctly and be able to level.

But as a programmer it's just my opinion. And I hope someone can lend a hand. If I knew how to change or improve it, I would propose it directly. Hopefully someone can help us. I'm just trying to help make the code fence better. So I appreciate all that people have contributed for so many years.

[oliver-eifler]

The positions are always related to the nozzle tip, not to the probe. nozzle-position = position-to-probe - nozzle_to_probe_offset the positions the nozzle could reach are restricted by x_min/y_min and x_max/y_max positions therefore the max. probing area, including z_safe_homing_point, are x_min_pos - NOZZLE_TO_PROBE_OFFSET{X} ; y_min_pos - NOZZLE_TO_PROBE_OFFSET{Y}; x_max_pos - NOZZLE_TO_PROBE_OFFSET{X} ; y_max_pos - NOZZLE_TO_PROBE_OFFSET{Y};

for your example and according to your configuration (x_min_pos:0, y_min_pos:0) with

define NOZZLE_TO_PROBE_OFFSET { 4.00, 50.00, -1.75 }

nozzle have to reach position (-4,-50) to probe position (0,0) which is restricted by x_min_pos, y_min_pos

[thisiskeithb]

The positions are always related to the nozzle tip, not to the probe.

Bingo.

Marlin will sanity check your reachable area at build time, so there is likely an issue with your bed size and/or min/max position settings.

[Ahmed-Mohiuddin-Shah]

But in marlin 1.1.9, I set the same Z probe offset and it worked without doing anything else but in marlin 2.1.x bugfix I have to edit the Z safe homing points to not get the error Z probe past bed.

[Gruala]

nozzle-position

Thanks for the explanation. Give me a few days to be able to replicate. Although I accept the explanation and I appreciate it. I only have a few questions in case I'm wrong.

[Gruala]

The positions are always related to the nozzle tip, not to the probe. nozzle-position = position-to-probe - nozzle_to_probe_offset the positions the nozzle could reach are restricted by x_min/y_min and x_max/y_max positions therefore the max. probing area, including z_safe_homing_point, are x_min_pos - NOZZLE_TO_PROBE_OFFSET{X} ; y_min_pos - NOZZLE_TO_PROBE_OFFSET{Y}; x_max_pos - NOZZLE_TO_PROBE_OFFSET{X} ; y_max_pos - NOZZLE_TO_PROBE_OFFSET{Y};

for your example and according to your configuration (x_min_pos:0, y_min_pos:0) with #define NOZZLE_TO_PROBE_OFFSET { 4.00, 50.00, -1.75 } nozzle have to reach position (-4,-50) to probe position (0,0) which is restricted by x_min_pos, y_min_pos

Hi. Forgive for the delay in responding Despite the explanation. And despite explaining what variables affect the NOZZLE_TO_PROBE_OFFSET to work properly, in reality. It only works with positive values in NOZZLE_TO_PROBE_OFFSET. I present an image with variables that work correctly.

This background would be my configuration with negative values. But despite placing them correctly, I don't see that it's bad variable placement. Cataloging the question as misconfiguration of variables I do not see it correct.

This second diagram does not work. He tells you out of bed. But that's because the addition or subtraction of those values from my point of view is not correct. But I apologize but it's just my point of view.

For me the solution would be that if the values are positive they are taken into account in calculations for the minimum of the nozzle. x_min_pos, y_min_pos

For negative values they would be taken into account for nozzle calculations that would affect the maximum variables. x_max_pos, y_max_pos

It all depends on whether the values add up or subtract... some affect maximums and others minimum variables.

**If with the variables that are there now I can configure it... please tell me how to place them. Because I don't see that it matches the actual position.

Thank you for responding and your time.**

I have also tried to locate where the variables are added or subtracted:

NOZZLE_TO_PROBE_OFFSET and I have not located the operations you described. I have used a text search engine within the entire code.

x_min_pos

Thz.

[Gruala]

The positions are always related to the nozzle tip, not to the probe.

Bingo.

Marlin will sanity check your reachable area at build time, so there is likely an issue with your bed size and/or min/max position settings.

It is not solved with configuration. The explanation of where the result is obtained to calculate the displacement is not accurate. I've already looked for the use of those variables in all the code and it doesn't work like that... Nor does it have that function. And even less to say that with configuration the problem is solved. The code does not work when entering negative values. He says out of bed. But it is a mistake. That same message could have been said with positives. The problem that the calculation only works with positive values.

And it doesn't function as they say. With positive values it is discounted only for the minimums of the bed. Maximums are left unadded or subtracted. That's why when you level... The nozzle reaches the end of the bed. This is how the code works.

But if you don't want to solve or improve it... I don't say anything else.

Thz.

[github-actions[bot]]

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.