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
16.28k stars 19.24k forks source link

[BUG] Z babysteps are added to Probe Z Offset, but not taken into account for subsequent prints #19899

Closed Itox001 closed 3 years ago

Itox001 commented 4 years ago

I have enabled the option to add the Z babysteps to the Probe Z Offset, in the hopes that I could do the live babystepping to get the z offset right and that it would be saved for subsequent prints. I found that this doesn't work, and that the z babystep needs to be done for each print even though it gets correctly added to the Probe Z Offset.

Expected behavior:

Actual behavior:

I believe that this is a bug, the probe z offset is being changed, but the value is ignored for subsequent prints. or perhaps there is something that I am missing and this is how it is supposed to work? if so, how do I modify the z offset so that it's not ignored at the start of every print?

My Configurations

Using 2.0.x bugfix from some days of days ago, and didn't find any closed issue or pull request related to this so I don't think this has changed in the last days. configs.zip

qwewer0 commented 4 years ago

Could you share one of the .gcode file that you printed?

Itox001 commented 4 years ago

@qwewer0 actually the complete gcodes that I've been printing this last weeks contain logos that I can't publish, but I think that you want to see if the start/end gcodes are not messing with the z offset, so I have cut the gcode in between and left the start/end, along with some lines of the actual print so that I'm not missing any start/end config: gcode.zip

Let me know if there is something else you need and I will see how I can provide it to you :)

qwewer0 commented 4 years ago

Could be related to https://github.com/MarlinFirmware/Marlin/issues/19819?

Itox001 commented 4 years ago

@qwewer0 I saw that issue, but it is not the same problem. For me the babystepping always works fine, it moves the amount commanded and it has never mysteriously crashed the nozzle on the bed or otherwise behaved strangely. My problem is that the babystepped z offset is not taken into account for the next print, even though it is accumulated on the Probe Z Offset.

sjasonsmith commented 4 years ago

That other issue involves an Ender 3 V2, so it is probably unique to the DWIN display code used for that printer.

qystan commented 4 years ago

I've encountered the same but thought it was something I wasn't doing right.

Running 2.0.6 bugfix on BTT 1.4Turbo.

boelle commented 4 years ago

@qystan so when doing things correct you do not see the same problem?

what did you do wrong?

qystan commented 4 years ago

@qystan so when doing things correct you do not see the same problem?

what did you do wrong?

I meant that I was getting the same results as Itox001 but thought is was due to my usage/understanding problem.

Reverted to manual mesh leveling as observed behavior using the various ways to adjust Z, like Baby-Steps/Z Probe etc became too confusing.

As an added thought on this, is it possible to add a step to ask the user to "Save Adjustment?" with a Yes/No for the user. The need to do the extra step to save the changes isn't intuitive and not visible to users.

rhapsodyv commented 4 years ago

Do it happens if you power cycle your printer before the next print?

Itox001 commented 4 years ago

@rhapsodyv seems to happen every time. It doesn't matter if I power cycle the printer, with or without saving to EEPROM.

rhapsodyv commented 4 years ago

I just did the following test:

Two days ago I flashed lastest marlin in my printer (after two months). I did the z-offset with babysteping and stored settings. Then I did a print. Turned off my printer. Today I turned it one and just put the same file to print, without doing anything else. It's working well.

I will try one or two more subsequent prints to test.

Can you share your gcode too? Maybe is something related to current start gcode...

rhapsodyv commented 4 years ago

Did one more print, and everything continues ok.

Which material are you printing? Which type of probe do you have? Which bed temperature do you use?

I'm asking it, because I have an inductive probe. And I already know that if it stay exposed to heat for long time, it gives wrong measurements. I could get even 1mm of wrong measurement from it, if it stay too long time exposed to heat. If its cold or not so time exposed to heat, it works fine.

Itox001 commented 4 years ago

@rhapsodyv I am using PLA, with a 3DTouch and have two printers where this happens, one runs the bed at 35 and the other one at 60.

I shared my start and end gcode above in a zip file, you should be able to download it.

The only thing you are doing differently than me is that I do the babystepping after starting the print (since I then know if it's too close or too far). Like this:

  1. Start print with an incorrect z offset.
  2. While the first layer is running, babystep z to the correct position.
  3. After the print is done start another print, or the same one again.
  4. Z offset needs to be babystepped again.

Have you enabled the option to get the babysteps added to the Probe Z Offset automatically? So that when you babystep, you actually see the probe z offset number changing. My bugfix is from a few weeks ago, perhaps I need to update again..

rhapsodyv commented 4 years ago

Have you enabled the option to get the babysteps added to the Probe Z Offset automatically?
Yes, it's enabled.

Ok, let spot the diferences.

Reading your gcode, seems you are using UBL. Right? I'm using ABL.

Can you do a simple test? Enable ABL. And change M420 S ; turn on UBL for a G29 (to do the auto level always).

This is my setup: ABL + G29 in the start gcode.

I just want try to isolate the problem.

Itox001 commented 3 years ago

@rhapsodyv apologies for the delayed response. It is a bit hard for me to run G29 on the start of each print, my 10x10 triple-probing mesh takes quite some time to get built, and the probe doesn't reach all of the bed. Additionally, my 3D touch sometimes redeploys itself messing up a point, which requires re-doing said point after the G29 is complete. Another way that shows the issue for me:

  1. Have a too close/too far Z offset.
  2. BEFORE starting the print, change the Probe Z offset (no babystepping), by whatever amount you think is right.
  3. Store settings to EEPROM.
  4. Turn off and turn on the printer.
  5. Check that probe offset was indeed persisted.
  6. Start print.
  7. Notice that probe Z offset is the same as it was on step 1 (too close/too far).

I did this 3 times, moving it -0.1 each time. My probe Z offset changed from -0.85 to -0.55, yet filament was still too squished at the start of the print. My first layer height is 0.25, so a change of 0.3 should be quite apparent. IMO Marlin is just not applying the probe Z offset, I guess its related to UBL since you don't face the issue with ABL... If you are familiar with the code and can point me to the place where this offset is supposed to be applied, I can give it a look :) thanks!

rhapsodyv commented 3 years ago

So the error only happens on UBL? With ABL it works fine?

Itox001 commented 3 years ago

Hi @rhapsodyv , I did not test yet with ABL, I mentioned it worked since it is working for you, but I did not confirm.

I have some time now to run tests. So far I have tested with UBL off (and no other bed leveling) and the issue remains.

tarsonis123 commented 3 years ago

Any progress. Have the same issue with UBL after getting massive annoyed from testing around I switched back to bilinear. There it seems to be more consistent but I say it seems. Just yesterday everything fine with the layer test and then after that the long print. Some spot got big wiggles so the nozzle was to low on that spot... It was off by around 0.08.
I can set the offset, home and evaluate and the Z is like I set it. But from print to print w/o power off (using M420 S1 Z0.6 in the startcode) some miracle happens and I need to readjust the Z by around 0.05 - 0.3 with a stunning Bltouch deviation of 0.003. Out of nowhere. I'm amazed...After that print next miracle and I have to adjust it back the first value again to have the same offset. Homing is fine. Its something while or after printing (start/endcode) that triggers this behaviour. Before with the bugfix I had Baybstepping probe offset active where I could double click and get in the menu and readjust the offset directly but it wasn't saved after printing. Now I have it disabled and gonna test the behaviour but the first print shows the same issue. Running in circles with ABL/UBL..

github-actions[bot] commented 3 years ago

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

github-actions[bot] commented 3 years ago

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.