Mesh Grid Compensation ignored
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!
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...
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 === 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)
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.
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.
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.
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
If the homing switch triggers when the nozzle is 2.5mm above the bed, then the G92 Z2.5 command is correct.
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?
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.
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.