[FR] Please slow the homing step of the Set Z Offset function to reduce Z Offset variability

[Thinkersbluff]

As discussed in the Discord #general channel, some users are noticing that the value of Z Offset required to get a good first layer can vary from less than 0.1mm to more than 0.5mm, from one print to the next, and yet others just leave it at 0.20mm time after time with seemingly no problem.

One possibility, it seems, is that those of us who do start chasing that perfect first layer gap are having problems getting the Set Z Offset function to give consistent results.

In the same way that v4 alpha has reduced the home Z speed in auto bed leveling to increase mesh quality, please consider lowering the speed with which the Set Z Offset function performs its Homing step.

Thanks.

[Sebazzz]

All right, I made three builds:

*Reference build with default settings - `#define HOMING_FEEDRATE_Z (460)`** firmware-default-20201207-173242.zip

*Build B - `#define HOMING_FEEDRATE_Z (260)`** firmware-feedrate2-20201207-173333.zip

*Build A - `#define HOMING_FEEDRATE_Z (160)`** firmware-feedrate1-20201207-173531.zip

I suggest the following test procedure to remove any possible source of error:

1. Ensure that the Z-axis is above the point the optical sensor on the gantry is triggered (but not too high, because that would consume too much time).
2. Flash the firmware.
3. Home and do the validation routine. I'm not sure what you have in mind, but I imagine running the bed leveling test pattern from Teaching Tech.
4. After validation, raise the Z-axis to repeat for the next firmware build.

I want to stress that the Z-axis must be above the optical sensor position before homing to prevent any source of error in that regard.

[Thinkersbluff]

You are awesome. Thank you for this quick response. I am sketching-out a test plan now, so I am using the above guidance as my framework.

I plan to use a metric set of steel gauge feelers to measure the gap at the end of each Z Offset homing routine, and my wrist watch timer to measure approximate time consumed from "button pressed" to "head stops moving", at least 3 times for each build.

Do I also need to evaluate the bed leveling performance? (I had not planned to.) Have you implemented any special logging that will help you evaluate the comparative performance of these builds?

[NOTE: Wife Unit#1 sounds like she is going to issue a priority interupt on me before the current print comes to an end, so my results may be delayed, but definitely at the top of my list from now until the results are in.]

[Sebazzz]

Do I also need to evaluate the bed leveling performance? (I had not planned to.)

No, I don't think that is necessary. 👍 It is primarily about the difference between the homing positions.

Have you implemented any special logging that will help you evaluate the comparative performance of these builds?

No, I assumed that the first level test would be sufficient. 😀

[Thinkersbluff]

Have you implemented any special logging that will help you evaluate the comparative performance of these builds?

No, I assumed that the first level test would be sufficient. 😀

Is there any useful parameter you could log that would enable a comparison of the strain gauge sensitivity setting on my printer with that of other users' machines? It seems that the actual position of RP1 and its impact on that comparator function determining "bed probe activated" is otherwise an uncontrolled variable with important implications for the validity of this printer as a representative machine for test purposes...

[Sebazzz]

Is there any useful parameter you could log that would enable a comparison of the strain gauge sensitivity setting on my printer with that of other users' machines?

No, there is unfortunately no advanced communication whatsoever with the daughter board in the hotend.

[Thinkersbluff]

Here is the Test Procedure I propose to use. Comments and suggestions welcome. CommunityFirmwareTestData_FR#63.xlsx

[Sebazzz]

Seems solid, except for two questions/remarks:

1. Raise Z to above optical sensor port before flashing the firmware and after homing the printer to prevent any error happening there.
2. Are your feeler gauges thin enough for testing the Z offset?

[Thinkersbluff]

• Raise Z to above optical sensor port before flashing the firmware and after homing the printer to prevent any error happening there. So I am missing something here. Is there an M command I can use to flash the firmware? (I was assuming I would have to power off/on.)

• Are your feeler gauges thin enough for testing the Z offset? The thinnest gauge I have is 0.04mm, so if the nozzle starts below that value I will only be able to say that it was below 0.04mm. That was why I set the initial offset to 0.25 instead of 0.20. If the test just does't work due to my limitations, I will revise the procedure to something that does...

[Sebazzz]

* So I am missing something here.  Is there an M command I can use to flash the firmware? (I was assuming I would have to power off/on.)

Yes, power off and on. But raise Z before powering off 😉

[Thinkersbluff]

Red LED seems repeatably: OFF at 7.3mm, ON at 7.5mm. Will try running test procedure with these values.

[Sebazzz]

I wouldn't assume any accuracy from the red LED :)

[Thinkersbluff]

Frankly, I had hoped for less ambiguous results.

I was counting on being able to use the blue LED to arbitrate when I was measuring a bed-to-nozzle gap accurately with a feeler gauge. Instead, I could not get that to work for me & the subjectivity of measuring "tightness" left me unsure what gap size to report, in some tests.

The data may support our premise that lowering the probe more slowly during Z Offset could improve the accuracy and repeatability of that function, but it may also just reflect confirmation bias on the part of the tester. Sorry.

TestReport_CommunityFirmware_FR#63_7Dec2020.xlsx

[Sebazzz]

Thank you for testing @Thinkersbluff - I haven't looked in your Excel sheet yet - but did you run a first layer test as well?

[Thinkersbluff]

No “porn” for me, today. :(

I tried three bed level test prints after one bed-leveling sequence using the v4-4.0.7.2 baseline. (120/50) The screen is in each photo for reference. The photo showing bed temp at 35C was printed at 230/60. The other two were printed at 230 unheated.

What strikes me most is that the right side of the bed is lower than the left, according to the visualizer, but the nozzle is too close when printing the squares on the right and too far away from the higher left and center spots, so maybe I have problems with my ABL to resolve first.

The center square lines did not fuse when printed at 0.25mm offset and 60 degC, even though the Set Z Offset function seemed to say 0.29mm was the right value at 60 degC.

I also noticed that offset seems to vary a little with bed temp (from 0.29mm at 60 degC to 0.25mm at 30 degC.). A bit counter-intuitive, but may warrant more rigorous testing.

[Sebazzz]

What strikes me most is that the right side of the bed is lower than the left, according to the visualizer

I noticed that the axis might need to be swapped in the visualizer.

I have the reverse: I need it lower at the right side.

[Thinkersbluff]

What strikes me most is that the right side of the bed is lower than the left, according to the visualizer

I noticed that the axis might need to be swapped in the visualizer.

I hope the mesh is stored right way around in Marlin. Seems odd that the ABL is not compensating for the small issues I see in my bed profile.

[Sebazzz]

I don't think it isn't compensating: it isn't accurate.

Possible resolutions:

• fiddling with the RP1 potmeter in the hotend (very tiny amounts)
• Leveling without bowden tube

Things you can try without touching the hardware and confirm my hypothesis:

• Use M420 V to request the current mesh. Note the mesh has columns denoted by I in the gcodes below and rows denoted by J.
• Use G42 to confirm which column and row you are going to modify.
• Use G29 W to manually set the value of the mesh coordinate. Remember that a lower Z means the nozzle needs to be closer to the bed - more squish.
• Save mesh using M500

Met vriendelijke groet, Sebastiaan Dammann

---

Van: Thinkersbluff notifications@github.com Verzonden: Tuesday, December 8, 2020 6:57:04 PM Aan: CR6Community/Marlin Marlin@noreply.github.com CC: Sebastiaan Dammann sebastiaandammann@outlook.com; Comment comment@noreply.github.com Onderwerp: Re: [CR6Community/Marlin] [FR] Please slow the homing step of the Set Z Offset function to reduce Z Offset variability (#63)

What strikes me most is that the right side of the bed is lower than the left, according to the visualizer

I noticed that the axis might need to be swapped in the visualizer.

I hope the mesh is stored right way around in Marlin. Seems odd that the ABL is not compensating for the small issues I see in my bed profile.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCR6Community%2FMarlin%2Fissues%2F63%23issuecomment-740801317&data=04%7C01%7C%7Cc5b04873ff1a4824f8cd08d89ba2acb6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637430470261624064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kGWocO5ocvUb6cw8H9kOCt73d%2FDMVf%2FMYR%2FU1HEa%2Fyo%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAK4FMI4LZD2TEZWF3YMWXDSTZSHBANCNFSM4UQUYNGA&data=04%7C01%7C%7Cc5b04873ff1a4824f8cd08d89ba2acb6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637430470261634047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XrKwoQgK91BlmSgSNgo8Jc9kmR6a67Mmtjz3Niu4lfg%3D&reserved=0.

[Thinkersbluff]

Thank you for helping me explore this hypothesis. I used the builds to support a few dozen m48 tests but I really have no meaningful results to share. If anything, the tests seem to show that the probe is quite repeatable at the current base speed, and slowing it down makes the system perform painfully slowly but does not make it perform significantly better. The root cause() of our problem with randomly changing Z Offsets probably lies elsewhere. Thanks for the gcode tips. I may still want to experiment with manual mesh editing if I need to solve a problem.

I am content to withdraw and close this particular FR, now. Cheers.

[Sebazzz]

Thanks for testing! To be continued!

Met vriendelijke groet, Sebastiaan Dammann

---

Van: Thinkersbluff notifications@github.com Verzonden: Friday, December 11, 2020 7:44:51 AM Aan: CR6Community/Marlin Marlin@noreply.github.com CC: Sebastiaan Dammann sebastiaandammann@outlook.com; Comment comment@noreply.github.com Onderwerp: Re: [CR6Community/Marlin] [FR] Please slow the homing step of the Set Z Offset function to reduce Z Offset variability (#63)

Closed #63https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCR6Community%2FMarlin%2Fissues%2F63&data=04%7C01%7C%7Cd645b3d9af0d468ebe1d08d89da04338%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637432658927136982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iJiWrPI8ESNTGUir8XuzQWiwJYy7JxZmphn7YV2rHrQ%3D&reserved=0.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCR6Community%2FMarlin%2Fissues%2F63%23event-4098744270&data=04%7C01%7C%7Cd645b3d9af0d468ebe1d08d89da04338%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637432658927136982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JxdPXla70fW%2BsjdmQB7oqax4YyBp6ouJguxEollmx0I%3D&reserved=0, or unsubscribehttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAK4FMO5UT4WJIXY6HW67R3SUG5WHANCNFSM4UQUYNGA&data=04%7C01%7C%7Cd645b3d9af0d468ebe1d08d89da04338%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637432658927146977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6l9tPLxhnH1iKFzEpiHDua94CLiQ4h4klveCsdvGci4%3D&reserved=0.