Mesh Grid Compensation ignored

Dakine

Hello,

I just completed wiring up my new Duet Wifi to my Maker Select V2. After some effort I was able to get a simple test print to print properly, using the mesh grid compensation. I do not have a Z probe, and so manually ran the mesh using a sheet of paper. This was after several attempts to get it to use MGC, and it not working. I have no real idea what changed, other than "third time's the charm."

I haven't been able to get mesh compensation to work since. Running M122 produces the below, which says mesh compensation is in use. However, it clearly is not, as the hot end grinds into my glass bed immediately after homing. I've tried adding G29 S1 to my start g-code, but no joy. I've included my start gcode (from Cura), as well as my heightmap.csv.

I'm sure I'm missing something simple.

Thanks for any help!

GCode

G21 ;metric values
G90 ;absolute positioning
M83 ;set extruder to absolute mode
G29 S1 ;Load Height Map
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F9000 ;move the extruder up 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F9000
;Put printing message on LCD screen
M117 Printing...

heightmap.csv

RepRapFirmware height map file v2, mean error 5.600, deviation 0.216
xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
25.00,175.00,25.00,175.00,-1.00,75.00,75.00,3,3
  5.600,  5.400,  5.100
  5.700,  5.600,  5.600
  5.800,  5.800,  5.800

M122 Diagnostics

M122
=== Diagnostics ===
Used output buffers: 3 of 32 (14 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
Board ID: 08DGM-95BLL-N65TJ-6J1D6-3S86M-90XVM
Static ram used: 15448
Dynamic ram used: 98920
Recycled dynamic ram: 320
Stack ram used: 1392 current, 4400 maximum
Never used ram: 11984
Last reset 00:02:37 ago, cause: power up
Last software reset at 2018-02-19 23:40, reason: User, spinning module GCodes, available RAM 7944 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 33.8, current 34.2, max 34.4
Supply voltage: min 12.3, current 12.3, max 12.5, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-02-21 15:21:03
Cache data hit count 601693000
Slowest main loop (seconds): 0.156814; fastest: 0.000110
=== Move ===
MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
Network state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20
WiFi MAC address 2c:3a:e8:0b:28:97
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 16552
WiFi IP address 192.168.0.123
WiFi signal strength -40dBm, reconnections 0, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)

dc42

You should not be getting height map errors of 5mm, they should be much smaller than that. Looks like you may not have homed Z before running mesh bed compensation, or else you have the Z speed or acceleration set much too high in config.g.

Dakine

Hi dc42,

Yeah, I agree, they need to be smaller than that. However I'm not able to adjust the Z endstop any higher without being higher than the bed can go, due to some damage to the printer. The first thing I plan to print is an adjustable Z-limit: https://www.thingiverse.com/thing:1008176. But for now, this is what I'm stuck with. Can the mesh compensation not handle a 5mm offset? the maximum difference between heights is only .9mm, admittedly still too much, but seems like it's well within operating capacity.

All three axes are homed. My Z is set to 120, and my acceleration is set to 100. These are actually a bit lower than they were on the Melzi board previously I believe.

Again, I was able to print one test damn near perfectly. But the mesh just isn't loading any more, or is loading inconsistently and I'm getting a string of bad luck.

dc42

What do you have in your Z homing file and in homez.g? If you are using a low end Z endstop switch, you can use a G92 command after the G1 S1 Z command to specify the height at which the endstop triggers. See https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Homing_Z.

Dakine

It looks like I have a G92 Z2.5. If my understanding is correct, this would tell the printer that the current Z position is actually 2.5mm, not 0mm. When adjusting for the mesh it would only lift up by about 2.5mm instead of 5mm, correct? That would seem like it could be part of my issue if that's the case.

I commented the G92out of the homez.g and homeall.g, and re-ran the mesh compensation just to be safe. It's still digging into the bed however.

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool on Sun Feb 18 2018 21:28:00 GMT-1000 (HST)
G91               ; relative positioning
;G1 Z5 F6000       ; lift Z relative to current position
G1 S1 Z-185 F1800 ; move Z down until the switch triggers
G92 Z2.5          ; set Z position to trigger height

; Uncomment the following lines to lift Z after probing
G91              ; relative positioning
G1 Z5 F100       ; lift Z relative to current position
G90              ; absolute positioning

dc42

If the homing switch triggers when the nozzle is 2.5mm above the bed, then the G92 Z2.5 command is correct.

Dakine

Ok, then it sounds like I don't need that command since the homing switch is hit below the bed surface. This happens because the glass surface doesn't extend to the XYZ home corner, plus the nozzle compresses the bed spring a little when homing Z. Not Ideal, but I can't print my Z-Limit adjuster until the printer prints again.

That being the case, if the switch is hit ~5mm below the bed surface, shouldn't the ~5mm mesh grid compensation account for that?

Dakine

Hmm. I think I've somehow worked through this. It looks like my steps/mm micro-stepping commands were off by quite a bit. I've adjusted those and it looks like things are working out now, although I'm sure it's not dialed in just yet.

I think removing the errant G92 commands helped as well. I'm not certain why the configurator put them in.

Fortunately I've discovered several more issues after trying to print again, so at least I won't be bored tonight!

Thanks for the help dc42.

dc42

If the switch is hit 5mm below the bed surface, you should use G92 Z-5 after the G1 S1 Z command. Change Z-5 to the actual value you measure.