G30Auto-Tilt creates hidden Z-offset-Duet 3-3.0RC2, DSF1.2

gtj0

@Luke-sLaboratory said in G30Auto-Tilt creates hidden Z-offset-Duet 3-3.0RC2, DSF1.2:

@gtj0 @Phaedrux

I've updated my config with a higher M566 value (60) and I've done the simpler Z-levelling procedure proposed by gtj0.

If I don't do any sort of bed adjustment/mesh, I don't have any issues. His procedure works exactly as expected, Z0 is actually Z0. I then did the exact same thing, just with using bed compensation (auto-tilt), got rid of the scripted G28 Z and did a manual rehome, with the same G1 X322 Y322 and G28 Z from console, and got the same offset.

I firmly believe this is some kind of bug somewhere.

This is going to be way overkill, but try adding an M400 after every command in bed.g, homez.g and any other .g file involved except config.g. I'm trying to see if there is a code buffering problem where codes are not executed fully or executed out of order. Both have been issues in the past.

Luke'sLaboratory

@gtj0
Ok will report back once my print is finished.

Luke'sLaboratory

@gtj0
Tried it - Same result. Put a M400 in erry macro, command, etc I could think of. My print executed perfectly.

gtj0

@Luke-sLaboratory said in G30Auto-Tilt creates hidden Z-offset-Duet 3-3.0RC2, DSF1.2:

@gtj0
Tried it - Same result. Put a M400 in erry macro, command, etc I could think of. My print executed perfectly.

Hmmm. I may have lost track somewhere.... Under exactly what conditions did it work perfectly?
With the addition of the M400s in your original macros/process that did cause the offset, did you get the 5mm offset?

The purpose of the M400 is to cause the firmware to wait before the previous moves are done before proceeding to the next command. I was hoping that adding the M400s would fix any issues with the buffered commands not being executed correctly.

Luke'sLaboratory

@gtj0

Sorry for lack of clarity.

There was zero change in the behavior I was describing. I still experience the hidden offset when I use the bed levelling features, even with M400 after every line in any positioning macro, custom or default.

If I do not use the bed-levelling features, My printer performs flawlessly and creates excellent prints, and my homing procedure (both homeZ & Homeall) functions correctly.

gtj0

Weird. The only difference between your process and mine is that your bed levelling starts at the middle rear and runs counter-clockwise. Just for the fun of it, what happens if you start at the front left and go clockwise?

Luke'sLaboratory

@gtj0
I'll give it a shot. As a comment, this also happens when I use g29 for mesh levelling as well, it's not confined to just g30.

Hopefully something works soon!

Luke'sLaboratory

@gtj0

Alright - Just tried out the switch - still no dice. The reported Z0 even after i do a full G28 rehome still floats wayyyy above the real 0. However, I reset the board (not a power cycle, just the reset button) rehomed, and the offset went away and its currently printing a perfectly adhered print.

This is honestly pretty frustrating

Luke'sLaboratory

@gtj0 More Shenanigans, still really stuck where to go with this.

I am now using 3.01 beta, and have copied over a 4-point conditional levelling loop from @kraegar to take my hands out of it.

; bed.g
; called to perform automatic bed compensation via G32

M561                         ; clear any existing bed transform
; If the printer hasn't been homed, home it
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  G28
  
M558 P9 C"io7.in" H15 F240 T6000 S.05 A1 ; Ensure that Dive Height is safe for Bed Tramming

;Run initial 4 point leveling routine
G30 P0 X30 Y30 Z-99999
G30 P1 X30 Y540 Z-99999
G30 P2 X480 Y540 Z-99999
G30 P3 X480 Y30 Z-99999 S3



while true
  if iterations = 5
    abort "Too many auto calibration attempts"
  if move.initialDeviation.deviation < 0.01 
    if move.calibrationDeviation.deviation < move.initialDeviation.deviation + 0.005
      if move.calibrationDeviation.deviation > move.initialDeviation.deviation - 0.005
        break
  echo "Repeating calibration because initial deviation (" ^ move.initialDeviation.deviation ^ "mm) must be < 0.01"
  echo "and (" ^ move.calibrationDeviation.deviation ^ "mm) must be within 0.005 of initialDeviation"

  M558 P9 C"io7.in" H5 F180 T6000 S.05 A2
  G30 P0 X30 Y30 Z-99999
  G30 P1 X30 Y540 Z-99999
  G30 P2 X480 Y540 Z-99999
  G30 P3 X480 Y30 Z-99999 S3

echo "Auto calibration successful, deviation", move.calibrationDeviation.deviation ^ "mm"
echo "Auto calibration successful, initialDeviation", move.initialDeviation.deviation ^ "mm"  
    
G28

However - it completely ignores the loop, does the two iterations, doesn't echo anything, and then re-homes.
I'll ignore that part of it for now.

Here's the readout from the two iterations:

1/18/2020, 10:45:28 AM	Leadscrew adjustments made: -0.060 -0.043 -0.002, points used 4, (mean, deviation) before (-0.033, 0.171) after (0.000, 0.170)
1/18/2020, 10:44:30 AM	Leadscrew adjustments made: 2.184 2.030 1.998, points used 4, (mean, deviation) before (2.051, 0.174) after (-0.000, 0.152)

The key takeway i think here, however, that while the first iteration shows that its level, the bed thinks that its ~2mm off on ALL axes, then corrects for it. The second iteration has the same deviation from the mean, but is VERY close to this new mean.

When then G28 completely rehome (using the same damn probe), it floats this ~2mm above the middle, which i proved out by manually disabling limits and moving the bed up in .05mm increments till it touched the nozzle. I think this has to be something derpy in the firmware somewhere as part of the self-calibration routine. This is AFTER I nuked the pi and re-did the image, so Now i'm going to use the erase feature on the duet 3 and try with 100000000% fresh firmware there as well.

anything else anyone can think of, let me know. I'm stumped.

Phaedrux

@Luke-sLaboratory said in G30Auto-Tilt creates hidden Z-offset-Duet 3-3.0RC2, DSF1.2:

anything else anyone can think of, let me know. I'm stumped.

I think you're on the right track. Nuke it from orbit and have a fresh run at it.

Luke'sLaboratory

Alright - I nuked the firmware from the heavens and re-flashed it with Bossa - No change in behavior.

I also tried a suggestion from kraegar to delete the m574 line for the z-axis since its probed out anyways in homeall and homez, but this also failed. Similar results.

New clue - on the 3rd probe point after the first set, it gave me an "error - G30 insufficient axes homed for bed probing" on the 7th probe (so while it is supposed to be within the second calibration iteration) from which it completed its probing, but instead of spitting out a deviation, it gave up (i assume errored out of the loop) ran g28, and then sat ready.

Luke'sLaboratory

Alright -

I RTFM, and conditional gcode has nothing to do with this. I'm using a Duet3 w/ a pi, so I guess it just ignores the conditional part until DSF adds support again. My bad.

The original issue still stands - using G30 to probe points and store them adds a nice 2mm offset that appears to be found in the first round of probing, then it "adjusts" for it, then the second round its not found, so it just works.

anyone have any logs I could get that would help them with this bug?

gtj0

Two things you should do...
In /opt/dsf/conf/config.json, add a "LogLevel" line (or modify the existing one) and set it to "debug".

{
  "LogLevel": "debug",
  "SocketPath": "/var/run/duet.sock",
  "Backlog": 4,
  ...

Restart duetcontrolserver.
Then run journalctl -fu duetcontrolserver
That will give you an idea of what the DCS thinks the Duet3 is doing.

Next step...
Connect the Duet3's USB port to the Pi (or any other computer). That will give you access to the Duet3's serial console. You can use Putty, minicom, whatever, to access it.
When you do, issue M111 P3 S1. That turns GCode logging on on the Duet3 and you can see what it's actually doing.

Now run your sequence.

Luke'sLaboratory

Alright -

I'm Back -

Looks like if I take the BL-Touch out of the equation (switched to an inductive sensor now, but once I assemble my jubilee head (soon) this will change to a simple physical switch) - This works exactly as intended without any additional complications with identical gcode.

I greatly appreciate you all taking the time to help me with my issue. I regretfully close this issue out for now on my machine.

It definitely seems to be related to the bltouch implementation.

So thank you all again very much.

Luke

gtj0

No worries! Don't hesitate to yell if you get into trouble again.