[RRF 3.2.2] Can't figure out the offset between Z0 and mesh
-
I've been trying to figure this out for a while, but I am totally stuck.
Here's my setup.
Printer 1:
Voron Switchwire (pretty much stock), but based on Duet 3 mini 5+ standalone.
Single Z probe NPN NC inductive Omron at 5mm trigger height. Hotbed has a flex plate on it and it's a Prusa MK52 bed.Printer 2:
Voron 2.4 (for the purpose of this discussion also stock) - Duet 3 6HC + 3HC standalone. It has an Omron microswitch to set the initial Z0 and an NPN NC inductive probe (cheap chinese - stock for Voron 2.4) with 8mm trigger height. Hotbed is an 8mm alu plate with a PEI sheet glued directly onto it.Both probes are connected directly into the input pins of the Duets, without diodes as per this guide.
I am not inverting the pin here, since they are both NC and not NO.
Problem:
I keep getting weird offsets between what I set to be Z0 and what comes out during Mesh probing.
It's always between 0.2 and 0.3mm difference and my mesh is floating in the air.Repro steps are the same for both, but since I have the SW next to me, I'll focus on that one to describe (and it's an easier and more common setup I feel).
- I make sure there is no offset set for the probe in config.g.
- Home
- Manually find Z0 (position the carriage over the center of the bed, keep lowering it until I see it is touching the bed).
- Set that as Z0 with G92 Z0
- Raise carriage by 10mm
- G30 S-1 - take the value and enter it into config.g in the G31 probe definition line
- Turn off the printer for sanity check.
- Turn printer on and home
- Verify that Z0 is found properly - it always is
- Run mesh probing via G29
- Discover that mesh is floating anywhere between 0.2-0.3mm above Z0.
I've tried multiple things to get the mesh to be positioned properly - the one thing that always works is if I take the offset from one of the points and add that to my G31 line (step 6), then probe again - results will be good. I can then return the G31 to it's previous setting (empirically found value) and then the whole thing will more or less work... until I try to set a second print, where without a power cycle the whole thing goes nuts.
Each time I would load the mesh before starting a print (M561 followed by a G29 S1), I'd get an error message saying:
Warning: the height map was loaded when the current Z=0 datum was not determined probing. This may result in a height offset.
I have tried adding a G30 S-3 between steps 9 and 10 and then before loading the mesh with G29 S1 - it stops the error message, but makes things worse as I progress with printing.
What's really weird is that I see exactly the same behavior on the other printer. And exactly the same steps and same workarounds work
What am I doing wrong - since clearly - I am doing something wrong.
This is how my probe is configured (both are very similar, just pins differ):
M558 P8 C"io3.in" H5 F300 T6000 R0.2 A5 S0.01 ; set Z probe type to unmodulated and the dive height + speeds G31 P995 X0 Y23.5 Z1.05 ; set Z probe trigger value, offset and trigger height
My homez.g looks like this:
; homez.g ; called to home the Z axis ; ; generated by RepRapFirmware Configuration Tool v3.2.2 on Sun Feb 07 2021 23:28:57 GMT+0100 (Central European Standard Time) G91 ; relative positioning G1 H1 Z15 F6000 ; lift Z relative to current position G90 ; absolute positioning G1 X145 Y130 F6000 ; go to first probe point that covers one of the mesh points G30 ; home Z by probing the bed G91 ; relative positioning G1 Z5 F6000 ; lift Z relative to current position G90 ; absolute positioning
And a screenshot of the mesh taken at step 11 above.
-
Hi,
I don't home Z using a my probe so I don't know if the following applies.
Before creating/loading the mesh compensation height map you must set the Z=0 datum.
The XY position must always be the same and the center of the bed is best.
I also make sure that mesh compensation and baby stepping are disabled
G29 S2 ; cancel mesh bed compensation M290 R0 S0 ; cancel baby stepping
Setting the Z=0 datum is done with G30.
So when homing using G30 does that also set the Z=0 datum? I don't know.
In any case it cannot hurt to try using G30 again.
G29 S2 ; cancel mesh bed compensation M290 R0 S0 ; cancel baby stepping G90 G1 Xaaa Ybbb ; move probe to center of bed G30 ; set Z=0 datum G29 ; create height map
-
We're basically both doing the same, but you're doing it all via gcode, I do it via turning the printer on and off, just to be sure. So your gcode is equivalent to my steps 7-10.
-
Your home z is wrong.
Your first move should be G1 H2 Z15 not G1 H1 Z15 -
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
We're basically both doing the same, but you're doing it all via gcode, I do it via turning the printer on and off, just to be sure. So your gcode is equivalent to my steps 7-10.
Well the warning message about the loading of the height map and the Z=0 datum not being set suggests that perhaps homing with the probe is not quite the same as setting Z=0 with a second G30.
You can easily create a macro to try the code I posted to see if it makes a difference.
Frederick
-
@jay_s_uk I can't use H2 on the Switchwire. It's a CoreXZ device - individual motor motion creates havoc
-
@fcwilt Sure, I'll give it a try once the print here is done.
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
@jay_s_uk I can't use H2 on the Switchwire. It's a CoreXZ device - individual motor motion creates havoc
CoreXZ?
I've heard of CoreXY but not CoreXZ.
Is yours laid out like this?
Thanks.
Frederick
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
@fcwilt Sure, I'll give it a try once the print here is done.
If the problem is occurring when loading the height map just change the G29 to G29 S-1
I have two macros that in essence do what I posted - one to create the height map and one to load it.
Frederick
-
@jay_s_uk I double checked the other printer. It has H2 (that one is CoreXY) and the problem is exactly the same on that one. I wouldn't say this particular line is the problem.
-
@fcwilt Pretty much yeah.
-
@fcwilt No, that's not the issue and besides - this would not be a solution either I want to use a mesh
Let's reset.
The problem appears the moment I run bed mesh probing for the very first time.
I could of course skip it and not have an issue, but that's not the point.So again.
I am able to configure both printers perfectly and manually find my Z0.
However, the moment I start to run G29 to get the printer to build a mesh map - the problem appears in that already the first probing produces a result 0.2-0.3mm above Z0.
And since the mesh is built incorrectly - each time I try to load it later with G29 S1 - it's loads that value incorrectly. The intermediary G30s were to check if that is the issue or not. They were definitely not a solution.
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
@fcwilt No, that's not the issue and besides - this would not be a solution either I want to use a mesh
The code snippets I suggested to try are intended to create/load the height map for mesh compensation.
And they address the very issue the warning message talks about - the Z=0 datum not being set.
The Z=0 datum must be set before creating and before loading a height map.
If you create the two macros and try them you have nothing to lose but a bit of time and they might solve the problem.
Frederick
-
@fcwilt - don't me wrong. I am not ignoring your suggestion I am just saying - I'm already doing it and that does not help and doesn't immediately touch on my problem.
Let's completely ignore the loading of the map before printing for now. That totally doesn't matter for what I feel is the core of this problem.
Let's focus on the very first mapping of the mesh for now. As if the printer had a brand new SD card, brand new setup.
If you take a look at my homez.g - you will see I am actually doing what you are doing (except the babysteps being removed with code by you and me by turning the printer on and off - your way is WAY more convenient ; and I use M561 while you use G29 S2, but those do exactly the same).
Then, I move my carriage on top of a particular point - in my case it's X145 Y130 - and run a G30 there.
Then, I immediately hit G29 and upon that - I am already getting a map raised by 0.2-0.3. I specifically highlighted that point on the resulting mesh map.
So while you have it as a single snippet to be called at will, I have the same just spread across a couple files.
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
Then, I move my carriage on top of a particular point - in my case it's X145 Y130 - and run a G30 there.
Then, I immediately hit G29 and upon that - I am already getting a map raised by 0.2-0.3. I specifically highlighted that point on the resulting mesh map.
I don't know if the issue still exists in 3.2.2 but sometimes in the past the height map displayed was not the most recent.
Rename the existing .CSV file something like heightmap_saved.csv and create a new one.
Then in the height map viewer you should see both of them and can force a refresh by loading the old one then the new one.
This may not be needed in 3.2.2 but it will insure you are seeing the most recent.
Also she warning referenced the Z=0 datum not being set so somehow the height map is being loaded without it being set.
Frederick
-
@fcwilt Yep, I remember that problem, and I tried reloading the whole webUI to be sure AND (I forgot to write about it) - I even deleted the previous csv before the probing.
And yes, I do have the warning about Z datum when I load the height map, but that's a second problem. First I want to understand why the very first bed mesh is already raised.
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
And yes, I do have the warning about Z datum when I load the height map, but that's a second problem. First I want to understand why the very first bed mesh is already raised.
If the Z=0 datum is not set when creating the height map you can get that error since creating the height map also loads it.
Frederick
-
OK. Again.
Tell me how my code differs from yours.First your code:
G29 S2 ; cancel mesh bed compensation M290 R0 S0 ; cancel baby stepping G90 G1 Xaaa Ybbb ; move probe to center of bed G30 ; set Z=0 datum G29 ; create height map
Now my code - combined from the files and process I posted:
Turn on the printer (so no need to run G29 S2 or M290, since nothing is set).
Then this:G91 ; relative positioning G1 H1 Z15 F6000 ; lift Z relative to current position G90 ; absolute positioning G1 X145 Y130 F6000 ; go to first probe point that covers one of the mesh points G30 ; home Z by probing the bed G91 ; relative positioning G1 Z5 F6000 ; lift Z relative to current position G90 ; absolute positioning
Then immediately trigger mesh:
G29
Where are we different (I am skipping the extra moves like raising the hotend as that cannot have any impact on the core issue here)?
Please note I wrote in my original post - before starting a print (M561 before G29 S1) - I get the error. But that only appears when I start printing something and run G29 S1. Not after I create the mesh - that wouldn't make sense, since I am running G30 immediately before creating the mesh.
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
Where are we different (I am skipping the extra moves like raising the hotend as that cannot have any impact on the core issue here)?
I cannot imagine that those extra steps are related to the problem.
Please note I wrote in my original post - before starting a print (M561 before G29 S1) - I get the error. But that only appears when I start printing something and run G29 S1.
My bad - you mentioned step 11 and looked at line 11 in your homeZ.g file not the steps above that.
So before loading the height map at the start of printing are you doing a G30 in the same XY location?
Frederick
-
Yep. Exactly the same spot.
And of course, the nozzle is raised by that distance. I have to babystep down to the plate by roughly the 0.2-0.3mm.And I would expect this behavior since the actual mesh has that offset.