Mesh levelling ignored
-
I have an inductive probe which is being used to detect a cast aluminium tooling plate. I am using a Duet WiFi with the following probe configuration
M558 P5 X0 Y0 Z1 I1 H5 F120 T6000
G31 X0 Y-32 Z0.05I have a MeshLevel macro defined as follows
M557 X0:115 Y0:93 S18 ; Define mesh grid
G28 Y ; Home Y axis
G28 X ; Home X, always before Z
G28 Z ; Home ZG29 S0 ; Run probing sequence
M374 ; Save calibration data
G1 X10 Y10 F3000
Which when run generates the following height map.csv
RepRapFirmware height map file v2 generated at 2017-09-25 12:20, mean error 0.027, deviation 0.022
xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
0.00,115.00,0.00,93.00,-1.00,18.00,18.00,7,6
-0.006, 0.011, 0.038, 0.051, 0.064, 0.051, 0.055
-0.002, 0.016, 0.029, 0.059, 0.064, 0.046, 0.051
0.011, 0.016, 0.033, 0.055, 0.059, 0.042, 0.033
-0.002, 0.007, 0.029, 0.051, 0.055, 0.033, 0.024
0.003, -0.002, 0.016, 0.029, 0.038, 0.024, 0.011
0.003, -0.002, 0.003, 0.029, 0.024, 0.003, -0.011But when I print a simple bed calibration test I get the following
-
You don't need to use M374 because G29 S0 saves the height map automatically. But it shouldn't do any harm.
Just before you try printing that again and after doing the G29, send M122 to get a diagnostic print, and look in the Move section to see what it says under "Bed compensation in use".
-
As requested the output of M122 is as follows
M122
=== Diagnostics ===
Used output buffers: 3 of 32 (13 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4S4-6JTD8-3SJ6J-TMVZY
Static ram used: 21176
Dynamic ram used: 95912
Recycled dynamic ram: 1696
Stack ram used: 1304 current, 4912 maximum
Never used ram: 7376
Last reset 00:09:15 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 7440 bytes (slot 2)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, 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 41.4, current 41.8, max 42.1
Supply voltage: min 11.5, current 11.9, max 12.2, under voltage events: 0, over voltage events: 0
Driver 0: stalled standstill
Driver 1: stalled standstill
Driver 2: stalled standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-10-26 09:42:43
Slowest main loop (seconds): 0.014099; fastest: 0.000061
=== Move ===
MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 146, completed moves: 146
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Stack records: 2 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
WiFi firmware version 1.19
WiFi MAC address 2c:3a:e8:0b:11:8b
WiFi Vcc 3.15, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 39168
WiFi IP address 192.168.1.15
WiFi signal strength -27dBm
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)It appears as though the probe heights are not being recorded despite this output from the MeshLevel macro
M98 P0:/macros/MeshLevel
42 points probed, mean error 0.029, deviation 0.022
Height map saved to file heightmap.csv
Height map saved to file heightmap.csv -
The same is valid for my Setup. Here Mesh compensation is always 0.00, ….
Anyhow, my bed is leveld to 0.05mm Corner for Corner therefore there is no real need to compensate. But i assume that there seems to be a problem in the mesh. I use a carthesian with a 300x300mm Bed.
Here an Output of M122 in between a running print:
1:24:50M122 === Diagnostics === Used output buffers: 3 of 32 (30 max) === Platform === RepRapFirmware for Duet WiFi version 1.20beta2 running on Duet WiFi 1.0 + DueX5 Board ID: 08DDM-9FAM2-LW4SD-6JKFD-3SD6R-93W7X Static ram used: 15136 Dynamic ram used: 96928 Recycled dynamic ram: 2624 Stack ram used: 1368 current, 9032 maximum Never used ram: 7352 Last reset 01:27:08 ago, cause: software Last software reset reason: User, spinning module GCodes, available RAM 7280 bytes (slot 0) Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 Free file entries: 9 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 8.7ms MCU temperature: min 21.0, current 23.8, max 24.5 Supply voltage: min 11.6, current 11.9, max 12.1, under voltage events: 0, over voltage events: 0 Expansion motor(s) stall indication: yes Driver 0: stalled Driver 1: stalled Driver 2: standstill Driver 3: stalled Driver 4: standstill Driver 5: stalled standstill Driver 6: stalled standstill Driver 7: standstill Driver 8: standstill Driver 9: standstill Date/time: 2017-10-26 11:24:48 Slowest main loop (seconds): 0.096625; fastest: 0.000104 === Move === MaxReps: 4, StepErrors: 0, FreeDm: 204, MinFreeDm 142, MaxWait: 0ms, Underruns: 0, 2 Scheduled moves: 32400, completed moves: 32389 Bed compensation in use: mesh Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heater = 0, chamber heater = -1 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 1 Stack records: 2 allocated, 0 in use Movement lock held by file http is idle in state(s) 0 telnet is idle in state(s) 0 file is doing "G1 X132.284 Y137.940 E55.4126" 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.20beta2 WiFi MAC address 5c:cf:7f:ee:66:c9 WiFi Vcc 3.11, reset reason Turned on by main processor WiFi flash size 4194304, free heap 38744 WiFi IP address 192.168.178.144 WiFi signal strength -30dBm, 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) -
Ignore the bed probe heights, they are the values from G32 bed probing, not mesh probing.
My guess is that mesh compensation is being applied correctly, but your inductive probe is not giving you accurate heights. If your inductive sensor is mounted a long way from the nozzle, that may be part of the reason.
To check that compensation is being applied, command some long movements and watch for the leadscrews turning. To make it more visible, as a test you could put an aluminium plate over part of the bed before you run G29 S0, in order to create a large height error that will have a more visible effect.
-
Ignore the bed probe heights, they are the values from G32 bed probing, not mesh probing.
Right, i've switched over and use G32 for a test and indeed the Values are printed with M122.
Thanks for Clarification David
-
The next RRF 1.20beta will report "G32 bed probe heights" instead.
-
Okay, I placed a 3mm aluminium plate on the front of the build plate during the mesh probing and then ran the calibration print. As expected the nozzle attempted to print 3mm off the original build plate at the front and then dropped down to the correct height at the rear of the plate.
So it appears that the probed mesh is being taken into account.
The sensor is mounted 32mm in front of the nozzle hence - G31 X0 Y-32 Z0.05
Is this too far ?
The probe returns the same map every time, unless I adjust the levelling screws in which case I see a change to the relevant area of the map.
I am currently using an LJ12A3-4-Z/BX 4mm Inductive Proximity Sensor Switch Detector DC6-36V (NPN - NO), this is being powered from E1 Heater VIN. I have a LJ12A3-4-Z/BY 4mm Inductive Proximity Sensor Switch Detector DC6-36V (PNP - NO) on order for a separate project which I will test once it arrives. -
Inductive proximity sensors like those were never designed to give a precise and reproducible trigger height. You can expect the sensor trigger height to change if the supply voltage or temperature changes, or if there are other metal parts (especially ferrous metal parts) in the vicinity of the sensor where you are probing, or if you probe too close to the edge of the bed plate or in the vicinity of screws that fix the bed plate in place. I suggest you measure the trigger height at various places (lower the nozzle until it just touches the bed, send G92 Z0 to define that as Z=0, raise the nozzle 5mm, and execute G30 S-1 to probe report the trigger height).
Having the sensor offset from the nozzle by such a large amount introduces two possible sources of error:
1. If the print head tilts as it moves in X or Y, this tilt will change the relative heights of the nozzle and the sensor.
2. Bed compensation may be needed if either the bed is not flat and level, or the head sags as it moves along the X gantry (and Y gantry if you have one), or both. If the probe and the nozzle are at the same location, it doesn't matter which of those you want to correct for. But the firmware has to choose whether to put the probe at the coordinates to be probed, or the nozzle at the coordinates to be probed. It puts the probe at those coordinates. This gives good compensation for bed errors, but less good compensation for gantry sag, because it will be compensating for the error 32mm away from where you are printing. So if the bed is flat and level but gantry sag is significant, you are better off specifying zero offset.
-
Okay, I suppose I have to ask the question. What do you recommend to use as a bed levelling probe ?
Thanks for the advice, I will spend some time checking the trigger distance across the bed. The bed is a 6mm cast aluminium tooling plate with no fixings within the print area so I would expect it to give similar results across the whole surface.
-
I've used BLTouch (the newer one where you can cut the trace for 3.3v usage) and DC42's IR-Probe. Both give me reproducable values.
Anyhow currently the IR-Probe only acts as an Endstop at my setup cause the Bed is leveled inside 0.05mm. Therefore no need for any kind of compensation.
Sometimes Bed-Leveling make things more worse. Additional if you claim that your surface should be flat, try a mesh only at 4 points (the Corners). This will help if the Probe is working. Cause it looks in your print as there is too much compensation in the middle.
Try it with 4 points and print it again.
