G26 Drives nozzle into the bed and ignores the probe

[viper93458]

Hello,

I am running the latest code from a few hours ago and after creating my initial mesh, if I run a G26, the nozzle immediately drives down into the bed and ignores the z probe. This wasn't happening before, so I don't know why its happening now. I do have MIN_SOFTWARE_ENDSTOPS disabled so that I can move the nozzle lower, however I am not sure what is commanding the nozzle to make this action.

I also found that after the estop, re-homeing and then doing a G0 X0 Y0, the nozzle does the same thing and drives the nozzle into the bed. Am I missing something?

Thanks for the hard work.

-William

[Roxy-3D]

I will look at that ASAP! But it maybe late tomorrow morning before I have it resolved.

[Roxy-3D]

I just checked this on the latest RCBugFix and I can't duplicate the issue. Do you have anything out of the ordinary like a large z_offset or something else? Posting the output from G29 W and G29 O will help.

[viper93458]

G29 W: SENT: G29 W READ: ubl.eeprom_start=32 READ: Unified Bed Leveling System Version 1.00 Active. READ: READ: Mesh 0 Loaded. READ: g29_correction_fade_height : 10.00 READ: z_offset: 0.000000 READ: X-Axis Mesh Points at: 10.0 30.6 51.1 71.7 92.2 112.8 133.3 153.9 174.4 195.0
READ: Y-Axis Mesh Points at: 10.0 31.7 53.3 75.0 96.7 118.3 140.0 161.7 183.3 205.0
READ: Kill pin on :41 state:1 READ: READ: ubl_state_at_invocation :0 READ: READ: ubl_state_recursion_chk :0 READ: READ: Free EEPROM space starts at: 0x0020 READ: end of EEPROM : 0x0FFF READ: sizeof(ubl) : 1 READ: READ: z_value[][] size: 400 READ: READ: EEPROM free for UBL: 0x0FDF READ: EEPROM can hold 10 meshes. READ: READ: sizeof(ubl.state) : 64 READ: UBL_MESH_NUM_X_POINTS 10 READ: UBL_MESH_NUM_Y_POINTS 10 READ: UBL_MESH_MIN_X 10 READ: UBL_MESH_MIN_Y 10 READ: UBL_MESH_MAX_X 195 READ: UBL_MESH_MAX_Y 205 READ: MESH_X_DIST 20.555555 READ: MESH_Y_DIST 21.666666 SENT: M105 READ: Unified Bed Leveling sanity checks passed. READ: ok

[viper93458]

I have z offset in the firmware set to 0. If I don't execute any G29 commands first, I can move the nozzle as expected. G28 will home, G1 X100 Y100 Z.25 will set my nozzle to .25 above the bed. If I start executing G29 commands and then either a G26 or other move, the nozzle goes down first at a VERY high rate of speed and actually kind of oscillates down and up until I hit e-stop. Very weird.

William

[viper93458]

Just for fun I did a G28 then a G29 W then a G1 X100 Y100 Z100 (all as expected). Then I entered G26 and the nozzle dropped to just a little above the bed and started to do its thing. Seems that it only tries to drive into the bed when doing G28 followed by an immediate G26. Not sure why it tries to go down first.

[viper93458]

I spoke too soon. It happened again after the pattern started printing. I think since I have areas of my mesh that aren't filled in with values (Outside the probe area), when it hits one of those it drives down into the bed. I may have wasted your time. I apologize. I am testing by filling in the unfilled mesh areas with zeros and testing again.

William

[Roxy-3D]

I spoke too soon. It happened again after the pattern started printing. I think since I have areas of my mesh that aren't filled in with values (Outside the probe area), when it hits one of those it drives down into the bed. I may have wasted your time. I apologize. I am testing by filling in the unfilled mesh areas with zeros and testing again.

Please fill in those areas with 'reasonable' values from what is next to them. But it should not drive your nozzle into the bed just because a value is missing. It is supposed to default to 0.000 mm of correction in that case. I will check that out ASAP. And I would appreciate knowing if filling in those values lets the the G26 do its thing. That would pretty much prove it is a problem in the Z-Height correction when a mesh value is missing.

[viper93458]

Working on it right now.

[viper93458]

Its weird, here is why my mesh looks like after just doing P1 and nothing else: SENT: G29 O READ: ubl.eeprom_start=32 READ: READ: Bed Topography Report: READ: READ: (0,9) (9,9) READ: (10,10) (195,205) READ: . . . -2147483.750 -2147483.750 -2147483.750 -2147483.750 -2147483.750 -2147483.750 -2147483.750
READ:
READ: -0.248 -0.189 -0.140 -0.088 -0.007 0.068 0.134 -2147483.750 -2147483.750 -2147483.750
READ:
READ: -0.189 -0.140 -0.095 -0.067 -0.010 0.010 0.065 -2147483.750 -2147483.750 -2147483.750
READ:
READ: -0.229 -0.180 -0.145 -0.097 -0.045 0.015 0.050 -2147483.750 -2147483.750 -2147483.750
READ:
READ: -0.175 -0.150 -0.110 -0.068 -0.031 0.010 0.050 [-2147483.750] -2147483.750 -2147483.750
READ:
READ: -0.126 -0.096 -0.087 -0.057 -0.013 0.015 0.065 -2147483.750 -2147483.750 -2147483.750
READ:
READ: -0.129 -0.098 -0.086 -0.050 -0.015 0.019 0.025 -2147483.750 -2147483.750 -2147483.750
READ:
READ: -0.134 -0.126 -0.091 -0.086 -0.033 0.004 0.025 -2147483.750 -2147483.750 .
READ:
SENT: M105 READ: -0.125 -0.109 -0.091 -0.071 -0.021 0.007 0.035 . . .
READ:
READ: 0.053 -0.015 -0.010 -0.011 0.011 0.040 0.070 . . .
READ: (10,10) (195,10) READ: (0,0) (9,0) READ: ok

[Roxy-3D]

Argh!!!! I know what is going on. You switched versions of RCBugFix recently!!!! Please get today's version of RCBugFix and do

• G28
• G29 P1
• G29 A
• G29 S1
• G26

At this point... You will still have unprobed areas of your mesh. In those regions you get 0.000mm of Z-Height correction. But the G26 should not go crazy. If it does go crazy... something else is happening.

But anyway... After the G26, you should be able to do the interactive mesh editing and get everything perfect.

[viper93458]

I did grab the latest a handful of hours ago. I did just re-run the commands as mentioned and included G29 P3 0 just to get the unfilled values zeroed out. I saved the mesh and even ran through an e-stop reset to make sure that the values stayed as expected. I am testing the G26 stuff now.

[Roxy-3D]

Yes... A G29 P1 will give you fresh data for the mesh. I believe that is going to fix things for you!

[Roxy-3D]

and included G29 P3 0 just to get the unfilled values zeroed out.

You did a G29 P3 R C0.0 right? The 0 needs a C in front of it. And without the R, you will only get the closest point to the nozzle cleared out.

[viper93458]

I actually just did a G29 P3 0 and it zeroed out the unfilled values. I will use the full syntax next time as you mention.

It seems to be better but then when trying to cancel the mesh I have to hold down the rotary knob a few times in a row until the unit finally picks up on the fact that I want to cancel. Not a huge problem, just something I noticed.

I am completely rebuilding the mesh form the beginning again.

[Roxy-3D]

It seems to be better but then when trying to cancel the mesh I have to hold down the rotary knob a few times in a row until the unit finally picks up on the fact that I want to cancel. Not a huge problem, just something I noticed.

The check for the encoder wheel being held down is only done in one place in the cycle. So... Just press and hold until it stops. It will stop. But that stop is going to happen immediately after any connecting lines from one circle to the surrounding circles happens. Or in other words... Immediately before it starts drawing the next circle. If you miss that window of time... You will have to wait for the next circle to be drawn.

It probably would be easy to have it check the encoder wheel status between each connecting line too. I'll check that out and see if that would make things better.

I am completely rebuilding the mesh form the beginning again.

OK... Good... Please let us know how good or bad it goes for you. And the G29 P4 R after the G26 is where you get to correct any imperfections!

[viper93458]

I am still trying to figure out the P4 stuff because when I was trying it before, I could get the screen to come up with the values to adjust, but I didn't actually see the nozzle move so I just had to pick a number, save and run the pattern again. Is this as designed?

Also, whats the best way to get to the area that needs adjustment? Manual move to the area, clean the bed of the old mesh pattern and then run the G26 with the R(x) value to just print that specific area?

[Roxy-3D]

but I didn't actually see the nozzle move so I just had to pick a number, save and run the pattern again. Is this as designed?

Correct... The nozzle doesn't move. But you know what the layer height is that you typically print with. If you are getting zero adhesion, move it down a full layer height. If the nozzle is pressing against the glass and the filament ideposited is so thin you can almost see through it, go up at least 1/2 of a layer height. You will get the hang of it very quickly. You will see the improvements on the next G26.

Also, whats the best way to get to the area that needs adjustment? Manual move to the area,

Yes. I typically use the target of PronterFace. But G1's are fine... It doesn't really matter. The higher level perspective is the algorytm will keep trying to find the next closest position to the starting position to edit. You could just do a generic G29 P4 R from any where on the bed and click the encoder wheel (with no rotation) until you get to where you want to be. I'm not actually saying to do that. I'm just saying you could do that.

clean the bed of the old mesh pattern and then run the G26 with the R(x) value to just print that specific area?

No... Do the G29 P4 R with the Mesh Validation Pattern still on the bed. That is the value. You can see exactly how good (or bad) the adhesion is at any given point. Then... After editing the areas that need improvement, clean off the old Mesh Validation Pattern and do a new one. Most likely... You will see improvement!

[WheresWaldo]

This is going to be an acceptance issue, Roxy please take off your programmers hat for a bit and understand that you have so much experience with UBL that you probably can create an adjustment grid, validate it and then adjust it in your sleep, but the process is far from intuitive and that will make it hard for people other than tinkerers to adopt. Using a visual method of validation isn't easy for a lot of people. I hope you give this some more thought.

[Roxy-3D]

Yes @WheresWaldo ! I edited out the part where I said "Other people wanted to see the nozzle move too." And remember... Initially, I had it moving because I thought that would be valuable. Give me a week to figure out how to best do this because it does cause other issues to show up. I'm not sure it should happen by default. But for sure I'm of the opinion some amount of the Marlin User Base is going to want that 'Feature'.

I am interested in hearing your ideas on this: If we make the nozzle move... Should the nozzle be a 'layer height' above the glass at the start of the edit for a particular mesh point? That is where movement would have the most value because you could see if you had the nozzle the 'right' height at the end of the edit operation. But the problem is... If you try to position the nozzle that close to the glass when you have errors in the mesh data, you might gouge the nozzles into the bed??? Do you have any suggestions on how to mitigate that scenario?

One idea might be to look at all surrounding mesh points (and especially the ones that have been edited so you know they are legitimate) and use those to figure out how to position the nozzle.

[viper93458]

Seems that completely redoing my mesh has resolved the nozzle crash. It appears to have been from invalid data in the mesh outside the probe area. I am confused about 2 remaining things though.

The nozzle seems to go up and down by amounts larger than the mesh specifies as it travels between parts of my print. I have Z_CLEARANCE_DEPLOY_PROBE set to 0 and Z_CLEARANCE_BETWEEN_PROBES set to 0. Neither of these should impact during a print job though as I am moving up in layers... I don't know why the nozzle is moving up during travels. Thoughts?

I can print a mesh and it looks acceptable using G26. I have to have my Z Offset set to +.4. However when I go to print with my Simplify 3D software, I have to set a Z offset of -1.65! I have no idea why this is happening. In my firmware my Z offset is set to 0. I have the inductive probe a bit low which causes my nozzle to be a little high which is why I have to use a z offset of +4 when doing G26. I expected to set a Z offset of +4 in my S3D software too but this resulted in my nozzle be WAY too high, hence I figured out that -1.65 works. That doesn't compute for me. Any ideas?

-William

[Roxy-3D]

Neither of these should impact during a print job though as I am moving up in layers... I don't know why the nozzle is moving up during travels. Thoughts?

I presume this is with the nozzle close to the bed... If you are below the 'Fade Height' the nozzle will attempt to track the contour of the bed. Both up and down. If you move the nozzle up above the 'Fade Height' (say 15mm) you should stop seeing the up and down movement. Try starting up high... and doing 100mm movements across the bed. You won't see any movement. But as you get close to the bed, the up and down tracking of the nozzle will get more pronounced.

However when I go to print with my Simplify 3D software, I have to set a Z offset of -1.65!

Is you Z-Probe triggering when the nozzle is 1.65 mm above the bed???

[viper93458]

I understand that it tracks the topology, but the amount of movement during a travel is much larger than my mesh values. Its a very noticeable jump in height during travels. Its almost like a Z hop is enabled (which it isn't).

As for the z probe issue, I decided to turn off UBL for now and go back to manual bed level with Z_PROBE_OFFSET_FROM_EXTRUDER set as perfect as I can get it. Then I set my software z offset to 0 and use M851 to make any adjustments needed from there. I have spent so many hours trying to get everything dialed in that I am a bit frustrated with it right now. :(

William

[Roxy-3D]

I have spent so many hours trying to get everything dialed in that I am a bit frustrated with it right now.

Yes. I understand. If you load the current RCBugFix, I'll help you get your mesh fine tuned.

[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.