Heightmap to the moon...

For the first time I wanted to try the height-mapping feature of the DC42 firmware, because I updated to the 1.17e DC42 firmware with the 1.14a GUI and the "show heightmap" button got me curious. I repeatedly get these kind of crazy maps though:



Really not fun and I guess that makes my printer unusable if turned on. The routine just runs like I would expect it to. I am using a bit coarse grid of 20mm and a radius of 120 because I have the 0.6 version Duet and that one does not allow for enough probe points needed for a finer grid. What could cause this ENORMOUS deviation figures that are not really there of course?

Here is the map in figures:

RepRapFirmware height map file v1 generated at 2017-02-27 21:12, mean error 184466663519813632.00, deviation 3026897512028962816.00
xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum
-100.00,100.10,-100.00,100.10,120.00,20.00,11,11
      0,      0,  0.067,  0.035, -0.003, -0.039, -0.088, -0.075, -0.077,      0,      0
      0,  0.139,  0.115,  0.097,  0.070,  0.009, -0.028, -0.073, -0.084, -0.015,      0
  0.023,  0.003,  0.021,  0.014,  0.041,  0.029, -0.021, -0.003,  0.017,  0.035,  0.109
  0.028,  0.023,  0.046,  0.060,  0.061,  0.015, -0.027, -0.038, -0.022,  0.025,  0.099
 -0.053, -0.022,  0.002,  0.026,  0.035,  0.002,  0.009,  0.015,  0.048,  0.090,  0.165
 -0.027,  0.054,  0.060,  0.039,  0.014, -0.018, -0.015, -0.011, -0.011,  0.028,  0.125
 -0.059, -0.027,  0.012,  0.028, -0.003,  0.020,  0.025,  0.015,  0.026,  0.046,  0.118
 -0.087,  0.004,  0.040,  0.038,  0.009,  0.052,  0.024, -0.025, -0.034, -0.022,  0.077
 -0.082, -0.035,  0.043,  0.038,  0.021,  0.013,  0.010,  0.000,  0.002, -0.001, -0.018
      0,  0.011,  0.009,-8224483864962138112.000,16451619751970471936.000,-136651341824.000,1035104029769728.000,  0.138, -0.235, -0.049,      0
  0.000,  0.000,5490524672.000,-753258.250,12635438092820414464.000,-16456320164179214336.000,16443865995971395584.000,-6421816847368192.000,367459303424.000,  0.000,  0.000

As far as I can tell nothing odd is happening at the probing points that go bezirk, but some of the values (mainly in proximity of the Z tower) are HUGE...
What strikes me is that the decimal values of the "questionable" triggers are all exactly .000 behind the dot...
Is that familiar for anyone here?

I've never seen anything like that before! Please run M122 to check that there is still some free memory. Also please try with firmware 1.18RC1.

Edited 1 time(s). Last edit at 03/28/2017 03:00PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for your reply dc42.
I just ran 2 bed height compensation routines. Still on 1.17e but this time without any heating to exclude the possibility of EMI. I thought to have found it, because it actually gave me a believable map. But the second (also cold) routine introduced the previous error again. map and figures are attached. Again all impossible values are ending with .000. I will update to the last RC and get back.

Here is the diagnostics right after the last attempt:

M122
=== Diagnostics ===
Used output buffers: 1 of 32 (9 max)
=== Platform ===
Memory usage:
Program static ram used: 45812
Dynamic ram used: 41876
Recycled dynamic ram: 2424
Current stack ram used: 3264
Maximum stack ram used: 5408
Never used ram: 2784
Last reset 00:24:01 ago, cause: power up
Last software reset code not available
Error status: 0
Max PWM loop count 0
Free file entries: 10
SD card 0 detected, interface speed: 10.5MBytes/sec
SD card longest block write time: 74.3ms
MCU temperature: min 26.7, current 44.0, max 46.8
Current date and time: 2017-03-28 22:42:53
Slowest main loop (seconds): 0.109131; fastest: 0.000000
=== Move ===
MaxReps: 17, StepErrors: 0, MaxWait: 590134ms, Underruns: 0, 0
Bed compensation in use: mesh
Bed probe heights: -0.006 -0.114 0.097 0.042 0.012 -0.011 -0.064 -0.086 -0.113 -0.024 0.029 0.067 0.102 0.112 0.073 0.060 -0.001 -0.048 -0.092 -0.100 -0.062 0.000 -0.017 -0.025 -0.014 -0.002 0.025 -0.000 -0.017 -0.008 -0.000 -0.005
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 3 allocated, 0 in use
Movement lock held by null
http is ready with "M122"
telnet is idle
file is idle
serial is idle
aux is idle
daemon is idle
=== Network ===
Free connections: 16 of 16
Free transactions: 24 of 24
=== Webserver ===
HTTP sessions: 1 of 8
FTP connections: 0, state 0
Telnet connections: 0, state 0

Edited 1 time(s). Last edit at 03/28/2017 04:53PM by DeltaCon.

Okay I did the update to 1.18RC1 as suggested. I ran 2 bed height compensation routines (both cold) and it appears as if it is okay now. Don't now what changed exactly. Will try again tomorrow while heating to see if that makes a difference.
One remark though, there is a nice new dropdown at the auto calibrate button, specifically for bed compensation. But if I run the mesh grid compensation from there it does not do anything. I f I run my own macro it works, and through the dropdown I can see the graphic too. But even then, the second attempt to do mesh grid compensation doesn't do anything. Should I change anything in the config.g?

Quote
DeltaCon
Okay Will try again tomorrow while heating to see if that makes a difference.

Happy to report that my issue seems to be solved. Makes me wonder DC, there must be something different in this RC1 compared to the 1.17e regarding the calculations of mesh heights, why else advising me an unstable version ;-)

Quote
DeltaCon
...attempt to do mesh grid compensation doesn't do anything. Should I change anything in the config.g?

Just thought of it, there must be generated a new mesh.g or something like that, just can't find details or an example.

The default filename is heightmap.csv.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
The default filename is heightmap.csv.

Yes, thanks, I found that. But I meant a .g file for invoking the mesh grid compensation, like bed.g is used for invoking auto calibration.

Mesh bed compensation is sufficiently automatic that it doesn't need a macro file to define it.

Some delta printer owners put G29 at the end of bed.g so that mesh bed compensation is run immediately after auto calibration.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

OK thanks dc. But my Rostock V2 does not do anything when I chose the "Run Mesh Grid Compensation", that's why I thought-up the mesh.g file ;-)

Edit:
I think there is a use for a fixed macro:
I have put a M558 H1 in it before the mesh grid probing, and restore it to H3 afterwards.
That makes the mesh probing a lot quicker, and since there has always been an auto calibration before, there is noo need for a bigger safe-margin while mesh-probing.

Edited 1 time(s). Last edit at 03/29/2017 03:24PM by DeltaCon.

Quote
dc42
Mesh bed compensation is sufficiently automatic that it doesn't need a macro file to define it.

Some delta printer owners put G29 at the end of bed.g so that mesh bed compensation is run immediately after auto calibration.

Is the mesh bed compensation automated enough to know to deploy a probe before running? Right now, I run the macro to deploy the probe then issue G29. Do I need to do the probe deploy?

Edit: The run mesh option on the control page doesn't do anything on my printer either.

Edited 1 time(s). Last edit at 03/29/2017 10:42PM by ElmoC.

Quote
ElmoC
Is the mesh bed compensation automated enough to know to deploy a probe before running? Right now, I run the macro to deploy the probe then issue G29. Do I need to do the probe deploy?

Good point, I'd forgotten that some types of probe need to be deployed.

Chrishamm will fix the non-functioning run mesh and related options in DWC 1.15a.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

This digital elevation model (DEM) is based on data from the Lunar Orbiter Laser Altimeter

[astrogeology.usgs.gov]

Perhaps you can subtract this from your bed map to get flat?

Hate to bring this up again... But I just upgraded my FW from 1.18someRC to the 1.19 stable and the problem I started asking about in this topic fully returned. Did something change back to a previous state concerning the bed compensation feature?
My heightmap.csv:

RepRapFirmware height map file v2 generated at 2017-07-21 20:53, mean error 55143424915650900113760737820672.000, deviation inf
xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
-100.00,100.10,-100.00,100.10,120.00,20.00,20.00,11,11
      0,      0,  0.050, -0.011, -0.051, -0.088, -0.113, -0.103, -0.124,      0,      0
      0,  0.104,  0.087,  0.062,  0.016, -0.035, -0.068, -0.095, -0.080, -0.036,      0
 -0.021,  0.007,  0.012,  0.036,  0.002, -0.025, -0.028, -0.033, -0.006,  0.039,  0.072
 -0.054,  0.020,  0.051,  0.063,  0.040,  0.012, -0.016, -0.025, -0.014,  0.012,  0.086
 -0.081, -0.011,  0.023,  0.026,  0.002, -0.001, -0.009, -0.002,  0.016,  0.058,  0.134
 -0.045,  0.033,  0.035,  0.028,  0.040, -0.011,  0.001,  0.015,  0.028,  0.063,  0.122
 -0.054, -0.017,  0.036,  0.048,  0.029, -0.013,  0.000,  0.013,  0.037,  0.089,  0.139
 -0.064, -0.030,  0.023,  0.054,  0.023,  0.011,  0.012, -0.008, -0.003,  0.025,  0.088
 -0.090, -0.022,  0.049,  0.061,  0.064,  0.024,  0.004,  0.013, -0.012, -0.011,  0.014
      0,  0.027,  0.064,  0.102,  0.072,  0.040,  0.022, -0.037, -0.061, -0.070,-4204160128060379514300903981056.000
      0,6180849544116030548220229831360512.000,  0.167,  0.138,  0.109,  0.036, -0.016, -0.038, -0.120,-581766347575210224441345703936.000,      0

Notice that (exactly as when I OP'd this thread the unbelievable probevalues end at .000. I do not really believe in this kind of coincidence ;-)

And the visual:


Edited 1 time(s). Last edit at 08/21/2017 03:23PM by DeltaCon.

Your heightmap shows 112 probe points.
Snippet from the 1.19 What's New page,
"If you have more than 32 probe points in your bed.g file, you will have to reduce the number to 32."

The limit of 32 points refers to points entered manually in the bed .g file. The limit on points for mesh bed levelling is 441 for the generation 2 Duets and 121 for the older Duets.

Please try the 1.19+1 bugfix release, see the Duet3d.com forum for details. If problem persists, post your config.g file.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

@ayudtee: the 32 points limit is for the auto Delta calibration routine. Here we are talking about mesh bed levelling.

Thanks for your quick reply DC42. I downloaded the bugfix but cannot see any improvement:


Below as requested my config.g
It would make sense to compare what changed between the versions 1.18RC1 and 1.17e. Since the probed off-values then ended with *.000 and they do that now exactly alike again, the puzzle simply has to be the same. Something changed, and got changed back. I am very curious as to why it seems to be only me suffering from it... I have a fairly generic setup. FSR with JohnSLboard, E3D V6 hotend. Rostock Max V2 with ball-cup arms. Curious...

; Configuration file for Delta printer from Think3DPrint3D V0.1 Date 20150708 with revisions for Duet V0.8.5 and Duex4 for testing

For help see [reprap.org] and 
[reprap.org]

; Prologue and communications section

M111 S0                             	; Debug off
M550 PSimply3D Rostock Max V2         	; Machine name and Netbios name (can be anything you like)
M551 Preprap                        	; Machine password (not currently used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED 	; MAC Address
;*** Adjust the IP address and gateway in the following 2 lines to suit your network
M552 P192.168.11.243                  	; IP address. (0.0.0.0 = use DHCP)
M554 P192.168.11.1                   	; Gateway (not used yet)
M553 P255.255.255.0                 	; Netmask
M555 P2                             	; Set output to look like Marlin
M575 P1 B57600 S1			; Set auxiliary serial port baud rate and require checksum (for PanelDue)


; Fan setup : Not required for DC42 firmware V1.09r and above
; M106 I1 ; fans are inverting
; M106 S0 ; Turn off Fan 0 (backward compatible with older firmware)
M106 P1 S0 ; Turn off Fan 1

; Movement section

M569 P0 S0				; X Drive 0 goes forwards
M569 P1 S1				; Y Drive 1 goes backwards
M569 P2 S0				; Z Drive 2 goes forwards
M569 P3 S0				; E0 Drive 3 goes forwards
M569 P4 S1				; E1 Drive 4 goes forwards
M569 P5 S1				; E2 Drive 5 goes forwards
M569 P6 S1				; E3 Drive 6 goes forwards
M569 P7 S1				; E4 Drive 7 goes forwards
M569 P8 S1				; E5 Drive 8 goes forwards
M574 X2 Y2 Z2 S1			; set endstop configuration (all endstops at high end, active high)
M906 X1500 Y1500 Z1500 E1600 I60	; Set motor currents (mA); set each extruder explicitly
;*** The homed height is deliberately set too high in the following - you will adjust it during calibration
;*** The calibration parameters are loaded from config.override.g
M201 X1000 Y1000 Z1000 E1000		; Printing Accelerations (mm/s^2) Set all E-motors the same
M202 X3500 Y3500 Z3500 E1000		; Moving Accelerations (mm/s^2) Set all E-motors the same (Not sure it's used in DC42 Duet firmware!)
M203 X30000 Y30000 Z30000 E3600		; Maximum speeds (mm/min) Set all E-motors the same
M566 X1000 Y1000 Z1000 E1500		; Maximum instant speed changes mm/minute. Set all E-motors the same
M92 X80 Y80 Z80				; Set axis steps/mm
M92 E90.769:90.769:90.769:90.769:90.769	; Set extruder steps per mm explicitly for all the extruders - 5 for Duet085+Dt4 test
G21                                 	; Work in millimetres
G90                                 	; Send absolute coordinates...
M83                                 	; ...but relative extruder moves
M220 S100				; set speed factor to 100%
M221 S93				; set extrusion factor (flow rate) to S percent (93 volgens dimensional accuracy calibration)

;*** backup of above section concerning current and accelerations ***
;M906 X1200 Y1200 Z1200 E1400 I60	; Set motor currents (mA); set each extruder explicitly
;M201 X1000 Y1000 Z1000 E1000		; Printing Accelerations (mm/s^2) Set all E-motors the same
;M202 X2000 Y2000 Z2000 E1000		; Moving Accelerations (mm/s^2) Set all E-motors the same (Not sure it's used in DC42 Duet firmware!)
;M203 X20000 Y20000 Z20000 E3600	; Maximum speeds (mm/min) Set all E-motors the same
;M566 X1200 Y1200 Z1200 E1800		; Maximum instant speed changes mm/minute. Set all E-motors the same


; Z probe and compensation definition

; *** If you have a switch instead of an IR zprobe, change P1 to P4 in the following M558 command
M558 P4 X0 Y0 Z0 H3			; Z probe is a switch and is not used for homing any axes
G31 X0 Y0 Z-0.15 P500			; Set the zprobe height and threshold (put your own values here)
M557 R120 S20				; Define a grid for mesh grid compensation, with the specified radius and spacing
G29 S1					; Load previous heightmap


; Heater and thermistor section

; Duet0.8.5 uses 4.7K resistors but Duex4 V0.2a uses 1K
M305 P0 T100000 B4385 R1000 H3 L0		; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 B5250 C7.06e-8 R1000 H10 L0	; Put your own H and/or L values here to set the 1st nozzle thermistor ADC correction (Duet)
;M305 P2 T100000 B4388 R4700 H30 L0		; Put your own H and/or L values here to set the 2nd nozzle thermistor ADC correction (Duet)
;M305 P3 T100000 B4388 R1000 H30 L0		; Put your own H and/or L values here to set the 3rd nozzle thermistor ADC correction (Duex4)
;M305 P4 T100000 B4388 R1000 H30 L0		; Put your own H and/or L values here to set the 4th nozzle thermistor ADC correction (Duex4)
;M305 P5 T100000 B4388 R1000 H30 L0		; Put your own H and/or L values here to set the 5th nozzle thermistor ADC correction (Duex4)
; M305 P6 T100000 B4388 R4700 H30 L0		; Put your own H and/or L values here to set the 6th nozzle thermistor ADC correction (Duex4)
M570 S180					; Hot end may be a little slow to heat up so allow it 180 seconds

; Temperature Tuning

; Hotend heater = 1
;*** The calibration parameters are loaded from config.override.g

; Bed heater = 0			
;*** The calibration parameters are loaded from config.override.g

;*** Controller temp correction
M912 P0 S-13.8


; Tool definition section

M563 P0 D0 H1                       	; tool 0 uses extruder drive 0 and heater 1
G10 P0 S0 R0 X0 Y0			; set tool 0 temperatures and offsets
; Second extruder on Duet 0.8.5 
;M563 P1 D1 H2                      	; Define tool 1
;G10 P1 S0 R0 X0 Y0                     ; Set tool 1 temperatures and offsets
;*** With a Duex 4 add 3 more tools (and 1 more fan)
;M563 P2 D2 H3                       	; Define tool 2
;G10 P2 S0 R0 X0 Y0                     ; Set tool 2 temperatures and offsets
;M563 P3 D3 H4                       	; Define tool 3
;G10 P3 S0 R0 X0 Y0                     ; Set tool 3 temperatures and offsets
;M563 P4 D4 H5                       	; Define tool 4
;G10 P4 S0 R0 X0 Y0                     ; Set tool 4 temperatures and offsets
;M563 P5 D5 H6                       	; Define tool 5 
;G10 P5 S0 R0 X0 Y0                    	; Set tool 5 temperatures and offsets

; Epilogue

;*** If you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0         	        ; Axis compensation here
T0

;*** GET EEPROM PARAMETERS FROM config.override.g ***
M501

You have a M557 command followed by G29 S1 in config.g. The G29 S1 command will change the grid to the one found in the file. Try sending the M557 command and then using G29 S0 to generate a new height map, without loading a height map file in between.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks, I will try that tonight (CET+1).
But isn't it common practice to load the map at system-start?
My previous heightmaps all differ slightly, so I am quite confident I am not looking at the same map each time.

It's not usual to load a height map in config.g, but some users load one in their slicer start script.

I'll consider changing the firmware to stash the original M557 grid when you load a height map from file, and restore the stashed grid when you run G29 to generate a new one.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
It's not usual to load a height map in config.g, but some users load one in their slicer start script.

If people do that from their slicer start script, why is it unusual to load the most recent heightmap from firmware? Maybe I am misunderstanding the whole concept, but my intention to load a heightmap from config.g is that I seldom take off the printbed and therefore have no need to rerun the mesh grid compensation each time I power on. Instead I load a heightmap that is known good from yesterday or last week. Is that a misconception?

Ik know the problem does not lie in the probing itself. It is certainly not that at the probepoints where these odd figures appear the HE is pushing harder or anything. I know that because while auto-calibrating (13 points) I carefully watch the lights on the JohnSL board. I always make sure that in-between-points trigger the two closest sensors, and the centerpoint triggers all three. If I had one defective sensor, or a sticky sensor mount, I would see one LED not lighting while probing.

I ran 4 consecutive mesh grid compensations, downloaded the heightmaps, and compared the output. I attached all 4 of them for you to see.This is what strikes me:

- I can see all probe values differ slightly (well, too much to my taste, but you tell me... )
- I can see that all ODD values always happen at the same grid locations
- We already concluded that the decimal value of each ODD probe point is *.000 (which to me indicates it is not the result of a real probe, because the odd of that being an integer is too small to reproduce)
- I see also that the values of each ODD grid location is different from each other, BUT
- I just now noticed that the ODD values are always exactly equal for each ODD grid location, AND
- These ODD grid locations seem to lie OUTSIDE of my round bed (no, no probing takes place there, but somehow a value shows up...)

I hope DC42, that you can work with this input.
I am aware of MHackneys "tilting bed" problem. I am not using a FSR plate like he designed, but I never felt the need for that. Also from visually checking the LED's on the JohnSL board I know that I do not have that effect on my printer. Also the fact that in the previous firmware all worked perfectly. But I will try, for science sake, to make my probing radius smaller to see what happens, but that somewhat defies the purpose of mesh grid compensation, since that is supposed to be extra helpfull for big prints.

EDIT:
I changed the radius from 120mm to 110 first. There were still false probepoints with large values. After setting the radius back to 100mm the mesh grid compensation looks to work okay

Two other strange things probably worth mentioning but not likely related:
- Yesterday I was not able to delete the deploy and retract macros. No error, the delete function is clickable in the context menu. Just nothing happens. I was able to rename them. Today I discovered I actually CAN delete them (had multiple reboots yesterday, always the same)
- Also today, while checking the date stamps, I found that files do not get a datestamp anymore. I use that often to make sure the last calibration, or mesh grid, has been saved. Check the picture. After editing and saving a file the firmware does create a timestamp for the file.


Edited 3 time(s). Last edit at 08/22/2017 02:37PM by DeltaCon.

I'll take a look at those height maps tomorrow or later this week. The explanation for the odd values ending in .000 is probably that the heights are stored as 32-bit floating point numbers and there are insufficient significant digits to represent fractional parts when the numbers get that large.

Which Duet are you using?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

It is a Duet 0.6 I bought early this year. Sorry ;-) It was cheap, and besides this issue I am really happy with it. It beats most modern day controllers!
Bear in mind the different probes that fail always get the same value (it gets calculated despite the fact that it does NOT get probed at all) and are outside my round bed. I already talked to MHackney on his slack channel to ask about Hinge Effect and FSR Ringing. He mentioned he always got his false probes whithin the points that got physically probed. I think when you look at my heightmaps you will conclude that it is about the points that make a square, but are outside the round bed (they usually get a value of 0.000)

I had this very same effect the other day when I was trying to increase my probe points for example probeing at 150 radius S15 works fine S14 gives the odd 2 spikes one negative and one positive and when trying s13 get an error msg suggesting they were to close and to try S15.

S14 was accepted but gave the errors and s15 worked as expected.

Doug

I've traced it to a firmware bug. On a Duet 06/085 it will occur when the rectangular mesh uses more than 96 probe points. So the problem won't occur if your grid is 9x9 or less instead of the intended maximum of 11x11.

On a Duet WiFi/Ethernet the same bug will occur if you use more than 416 probe points (maximum is supposed to be 441).

Release 1.19.1 will include the fix. Thank you for reporting this, and for your patience.

Edited 1 time(s). Last edit at 08/23/2017 04:38AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Yes, I could try varying the distance between probepoints too of course.
I am counting on David to get an "Aha moment" that solves this. But I am happy I am not alone on this issue ;-)

I am thinking about something like this: A square grid is defined for mesh-levelling. For a round bed certain points on this square grid "fall off" the bed. These points are skipped while probing. At this point, under certain circumstances (maybe those points are exactly on the edge of the bed, or within a certain margin?) values are given to the skipped points due to a firmware bug (sorry David!). The given values are not random, because they are always equal for the same grid. Maybe it is a calculation based on movement to the next point or something. But that's just what Dutch people call "luchtfietserij" (shot in the dark and unbiased by lack of knowledge on the issue )

Quote
dc42
I've traced it to a firmware bug. On a Duet 06/085 it will occur when the rectangular mesh uses more than 96 probe points. So the problem won't occur if your grid is 9x9 or less instead of the intended maximum of 11x11.

On a Duet WiFi/Ethernet the same bug will occur if you use more than 416 probe points (maximum is supposed to be 441).

Release 1.19.1 will include the fix. Thank you for reporting this, and for your patience.

Davids' Aha-moment occured just before I completed my previous message ;-) Thank YOU David, for YOUR patience!
I am just happy to contribute. Seems my analysis not completely off ;-) Am I right to assume that the mesh grid compensation is not used that much? I imagine that if one decides to go use it, one would always strive to use as many points as possible. So I am a bit surprised that there were not many (any?) questions about this.

Still David I am unsure as to why I would not load the heightmap on systemstart. Until now that always seemed to work pretty well for me.
I wil be checking for the 1.19.1 version. Thanks!

Mesh compensation is used a lot! But most users don't go near the limit of the maximum number of probe points, and on the Duet WiFi/Ethernet that limit is almost 4 times higher than on the legacy Duets (21x21 grid instead of 11x11).

I'm still surprised that I didn't see this issue when I tested the feature after implementing it originally. Probably its appearance depends on the configuration in subtle ways.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

There is a test version of the new firmware available, see [www.duet3d.com].

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Sorry guys for hijacking the thread but i didn't want to open a new one.

Ok at this time my heightmap isn't at the moon but i think there is something wrong i am doing and i could use some help.



No matter what i do this corner is always more than .25mm according to the bed levelling.

I am running either g32 or g29 both following a homeall command.

i do have some led stripes on me tringles on the mendel but i also tried with them covered up .

before i start playing with the bed levelling ( 2d ago apllied a dc sensor on black printbite) i was able to print for about 7 months so i know that the bed is not that bended as i haven't ever used bed leveling during prints.

---

Delta Printer
Duet 0.8.5 firmware 1.19

It's not that easy to tell from that angle, but I think you have Y axis twist. I am not familiar with the Mendel. Does the bed move along the Y axis on two parallel smooth rods? If so, then twist can be caused by the smooth rods not being quite parallel, for example at one end of the Y axis the rods might be at the same height but at the other ends they are at slightly different heights.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].