[RRF 3.2.2] Can't figure out the offset between Z0 and mesh
-
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.
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
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.
This is most curious.
All I can think of at this point is to create two macros with my code snippets then run the one that create creates the height map and then immediately run the one that loads it.
I'm trying to eliminate anything that is somehow happening behind the scenes causing the problem.
Do you have any code somewhere that might be changing the probe Z trigger height setting with one value being used when creating the height map and another when loading?
Grasping at straws there.
I'm running out of ideas.
Frederick
-
Tried your macros - no change. As in - the offset is still there. Even the error appears - which is weird, because I know at some point in my tinkering yesterday I managed to set a series of commands that made the error disappear, but of course - not the offset itself.
I do not have any gcode that could in any way impact the probe Z trigger. That I double checked
I am pretty much stuck as well
It totally baffles me. -
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
I am pretty much stuck as well
It totally baffles me.Here is something to try.
When doing the G30 you are positioning the probe at one of the probe points for the grid? Yes? No?
IF that is the case try a position that is in the middle of 4 grid points.
I will be racking my brain trying to recall anything else that might be causing the problem.
Frederick
-
@fcwilt Correct. I am probing exactly one of those spots. I'll try between the 4 tomorrow assuming the printer will even start. Currently, the board refuses to launch (different, known issue with the minis, waiting for a board replacement). If it were only on this printer, I'd think it's the board at fault and leave it at that
But the other printer has the same problem, so yeah. -
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
@fcwilt Correct. I am probing exactly one of those spots. I'll try between the 4 tomorrow assuming the printer will even start. Currently, the board refuses to launch (different, known issue with the minis, waiting for a board replacement). If it were only on this printer, I'd think it's the board at fault and leave it at that
But the other printer has the same problem, so yeah.Known issue?
I have 4 Minis - what goes wrong?
Frederick
-
There's apparently a batch that can result in loss of connection to the SD card.
It's described here: https://forum.duet3d.com/topic/21004/duet-3-mini-5-unable-to-connect-via-browser/24?_=1615068562632 -
OK. Now I am even more lost...
3.3b1 solves the problem. Height map is scanned and loaded properly.
Same steps as above exactly. Worked first time.Now to try a print!
-
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
OK. Now I am even more lost...
3.3b1 solves the problem. Height map is scanned and loaded properly.
Same steps as above exactly. Worked first time.Glad to hear it is working.
I wonder why.
Was it the update to the new version that did it or was it the update process itself that fixed something?
Curious.
I know I have loaded height maps under 3.2.2 but did I create them under 3.2.2? I don't remember.
I need breakfast.
Frederick
-
It must be the update. I rolled back to 3.2.2 and the issue came back.
Each time, I kinda reset the whole process, so all csv's deleted, etc etc. -
@pkos said in [RRF 3.2.2] Can't figure out the offset between Z0 and mesh:
It must be the update. I rolled back to 3.2.2 and the issue came back.
Each time, I kinda reset the whole process, so all csv's deleted, etc etc.Good to know.
I will have to generate a new height map to see if the problem occurs for me as well.
I hope not as I don't like using beta firmware.
Frederick
-
Happy too fast...
It solves the issue with Switchwire, but does not solve the issue on 2.4.
I am still getting that offset even on 3.3b1. Damn...
-
I went ahead and created a 9 point (to save time) height map under firmware v3.2.2.
No issues.
So I'm still baffled by what is happening on your printers.
Frederick
-
I've been trying to create your problem on my printer and I just cannot.
I tried messing with the probe Z trigger height.
I even edited the CSV file adding 1 to each point.
So far I haven't found out what conditions cause the error.
Frederick
-
Well assuming 3.3 comes out of beta soon, I will close this for now. I have a workaround for 3.2.2 that always works... it's just weird an annoying is all
