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.05

    I 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 Z

    G29 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.011

    But when I print a simple bed calibration test I get the following


  • administrators

    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)
    
    

  • administrators

    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


  • administrators

    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.


  • administrators

    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.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.