Very! strange height map results

[rjenkinsgb]

Running 3.4b6 on a 6HC.

I re-ran G29 heightmap after updating from V3.3. Since then I noticed that the first layer is rather uneven across the Y axis, and there is visible movement of the Z leadscrews.

The last print I tried had a very bad first layer, so I thought I better double check everything.
The hightmap looked like a plot of ocean waves!

This is on a glass bed, by the way, which has no visible error using a straightedge along Y and a minuscule centre dip long X as there is no centre support in that axis.

Re-running it at different grid spacings, the waves are every so many samples regardless of the grid - no relation to the axis travel or position.

It looks almost like alternate probe measurements are off - except the probe follows a zig-zag pattern and not a raster scan, with sequences having both even and odd numbers of probe points per Y line - but the patterns always form matched ridges and valleys along X.

I'm using the exact same sequence to produce each heightmap, and with a genuine BLTouch probe:

Reference the machine, heat the bed to 70'C, run G32 to zero and level across the leadscrews then G29 to produce a heightmap.

I initially used a 20mm grid, I tried 40 and 80 and the waves grew in proportion.

I screengrabbed the 80mm one and have now gone back through 40 and 20mm to do more screengrabs. Nothing else has been changed in the config, other than the grid size.

80mm grid:

40mm grid:

20mm grid:

Config attached.
config.g

M122 output:

03/12/2021, 13:15:44	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0beta6 (2021-11-06 11:38:57) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J1F6-3SN6K-TBAAU
Used output buffers: 6 of 40 (40 max)
=== RTOS ===
Static ram: 151136
Dynamic ram: 68056 of which 24 recycled
Never used RAM 131384, free system stack 130 words
Tasks: SBC(resourceWait:,0.7%,502) HEAT(notifyWait,0.0%,320) Move(notifyWait,0.0%,247) CanReceiv(notifyWait,0.1%,771) CanSender(notifyWait,0.0%,373) CanClock(delaying,0.0%,340) TMC(notifyWait,7.4%,58) MAIN(running,91.0%,921) IDLE(ready,0.9%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:36:23 ago, cause: software
Last software reset at 2021-12-03 12:39, reason: User, GCodes spinning, available RAM 131628, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
Step timer max interval 135
MCU temperature: min 31.1, current 37.0, max 37.3
Supply voltage: min 23.7, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: pos -416, standstill, SG min 0, mspos 232, reads 49214, writes 25 timeouts 0
Driver 1: pos 64, standstill, SG min 0, mspos 296, reads 49214, writes 25 timeouts 0
Driver 2: pos 91, standstill, SG min 0, mspos 488, reads 49214, writes 25 timeouts 0
Driver 3: pos 12500, standstill, SG min 0, mspos 872, reads 49214, writes 25 timeouts 0
Driver 4: pos 0, standstill, SG min 0, mspos 528, reads 49198, writes 41 timeouts 0
Driver 5: pos 0, standstill, SG min 0, mspos 8, reads 49228, writes 11 timeouts 0
Date/time: 2021-12-03 13:15:43
Slowest loop: 451.79ms; fastest: 0.03ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 3, maxWait 964545ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 535, completed 535, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 20375, received 131582, lost 0, longest wait 3ms for reply type 6049, peak Tx sync delay 134, free buffers 49 (min 48), ts 10920/10919/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 20629/20629
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x2b6b8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.4-b6
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.48, max wait times: 39.2ms/11.0ms
Codes per second: 0.23
Maximum length of RX/TX data transfers: 3980/772

Any ideas??
The original G29 heightmap on V3.3 was reasonable and showed just the slight X curve in the bed.

[T3P3Tony]

@rjenkinsgb Thanks for this report and the investigation you did to get to this point.

Normally when I see this sort of issue its ends up being due to a mechanical mechanism of tilting that varies depending on direction of either X or Y travel or both. in this case the waves are progressing in Y (height is pretty even in each lines of X points). AFAIR the mesh will be probed progressively in X. then Y will increment, then another line of X will be probed. That fits with the way the "waves" are shown in your screen caps.

Could it be possible that there is a mechanism that is causing the probe to tilt enough to raise/lower it by~ 0.3mm depending on the direction of travel?

A simple test would be to define a "mesh" that is just one line of X points wide down the middle of bed and see if the waves are reproduced.

Its interesting that you note you did not see this on 3.3 so if you can try downgrading to 3.3 and rerunning the test that will help tie down the issue if its not mechanical.

[rjenkinsgb]

I was looking at it sideways.
The wave effect is along Y, as you say.

I will re-investigate.

[rjenkinsgb]

I am puzzled; the machine is a CoreXY with the X rail supported on all-metal guides and roller bearings, with the Y axis carriages having lateral rails and wheels.

The rails seem perfect, when checking with a straight edge, and if one carriage had eg. a skewed roller, that should how up far stronger at the close end and much less near the good etc.

Plus the "wavelength" would not alter with the probe grid.

[I was expecting any mechanical problem to be in X, as that has a completely new carriage and the rail for that aligns the rollers vertically - but again I could not find any variation & everything is solid].

It's taken me a long time to get the setup something like right with this and I don't want to mess it up; it's running in SBC config with toolboards etc.

I'll try to find a spare SD and put the V3.3 setup on that.

[DIY-O-Sphere]

@rjenkinsgb said in Very! strange height map results:

Y axis carriages having lateral rails and wheels

Maybe the wheel axles are out of center?

[T3P3Tony]

@rjenkinsgb said in Very! strange height map results:

Plus the "wavelength" would not alter with the probe grid.

if it was a deformation in the rails I agree, however a rocking type issue where the probe (and what its mounted on) rotated round a point could do this.

[rjenkinsgb]

I've checked the track rollers on the X carriage, they are tight as both ends, and the probe mount seems to be rock solid.

I've just done a test by approaching the same point from 10mm plus or minus on X and getting the G30 result from both:

03/12/2021, 17:25:40	G30S-1
Stopped at height 3.050 mm
03/12/2021, 17:25:17	G1X150Y150F50
03/12/2021, 17:23:09	G01X160Y150Z10
03/12/2021, 17:22:45	G30S-1
Stopped at height 3.025 mm
03/12/2021, 17:22:18	G1X150Y150F50
03/12/2021, 17:21:43	G0X140Y150Z10
03/12/2021, 17:21:14	G32
03/12/2021, 17:21:14	Leadscrew adjustments made: -0.050 -0.455, points used 2, (mean, deviation) before (-0.204, 0.086) after (-0.000, 0.000)
03/12/2021, 17:20:53	Connected to 192.168.0.30

It's only .025mm different, which could partly be the probe warming up as I'd only just switched the machine on and let the bed get to temperature.

Repeating, it's still drifting slightly, but nowhere near the magnitude in the heightmap and consistently the same direction, so most likely a thermal effect.

03/12/2021, 17:30:54	G30S-1
Stopped at height 3.122 mm
.....
03/12/2021, 17:29:46	G30S-1
Stopped at height 3.112 mm

The next thing must be try it back with V3.3

[T3P3Tony]

@rjenkinsgb before trying back tracking to 3.3 can you try the single row "mesh" (across the "waves")

[rjenkinsgb]

@t3p3tony said in Very! strange height map results:

before trying back tracking to 3.3 can you try the single row "mesh" (across the "waves")

It won't accept a single row:

M557 X0:240 Y150:150 S20   

Error: M557: bad grid definition: X range too small

[T3P3Tony]

@rjenkinsgb ahhh, dammit. yes in that case 3.3 would be the next logical thing to do to eliminate or point to a firmware issue.

[rjenkinsgb]

@t3p3tony
OK, having set up an SD card with V3.30 and put the same config in that:

No change; it's not due to the beta firmware.

I'm trying to remember all the changes I made about the same time; there were several in a short time.

The original heightmap was from before I fitted the glass bed over the slightly curved aluminium one; I was trying to get it as flat as possible, as the heightmap showed an obvious dip between the front & back support bars.

Another change was adding G32 to level across the leadscrews, rather than using a single point G30 in the centre of the bed.

At the moment, I still have the wave effect.

However, trying the single point zero rather than dual point, it appears dual point makes things worse:
(I have adjusted the bed levelling screws slightly to try and get as near level as I can with an all zeros heightmap)

This is now the result using G32. I have verified the leadscrew spacing etc.

But with a single G30 in the middle of the bed - still the waves, but without the right side being wrongly high:

I'll be trying to set up some measuring equipment later today to detect any head tilt; our gear for machine tool setup has magnetic bases and this machine is virtually all aluminium and plastic, I need to work out some suitable attachment points or brackets yet..

[Phaedrux]

Tell tail pattern of backlash causing the probe to tilt.

[rjenkinsgb]

@phaedrux

Just done a test with a dial indicator under the head "cap":

https://www.youtube.com/watch?v=Gr6-FIdfnhA

There is no more than about +/- 10 microns spring when trying to squeeze or lift it relative to the rail, and jogging either way and back to the middle position of the three gives a similar range.

The gauge tip is on the underside of the printed cap and that is not dead flat, so the gauge reads differently either end - but returning to the centre position from either direction shows only a tiny error, which could be the gauge tip dragging on the rough surface.

I also tried the gauge at the other end, directly under one of the BLTouch mounting screws, and that gave a similar +/- ~10um movement spring when prying or squeezing against the rail. There is no flat surface at that end to try with X movement.

This is a photo of the new axis saddle plate against the original head, while I was working on the new toolhead; it uses steel track rollers with eccentric adjusters, identical parts to the original Tronxy linear track guides.

The large printed cap that anchors the belts and cables is held by two long M5 screws through the top corners and the whole thing is an extremely tight (interference) fit over the metalwork and through the screw positions, bracing it downwards.

So far, the only movements I can find are around an order of magnitude less that what is indicated in the height maps, and that's with force applied?

[Phaedrux]

It is very strange. Is there anything else that could be affecting the BLTouch? Have you watched it closely while probing?

[JoergS5]

@rjenkinsgb in your two Dec 4th images, the first had a bed temperature of 30 degrees, in the second 70 degrees, may thermal expansion be a cause? How is the bed fixed, by screws (so it can bend) and which type is the bed?

[o_lampe]

@phaedrux @rjenkinsgb
Same idea: I'd check the drag-chain if it causes the BLTouch mount bending/tilting.

[rjenkinsgb]

@o_lampe said in Very! strange height map results:

I'd check the drag-chain if it causes the BLTouch mount bending/tilting.

It uses the E3D spring trip arrangements to hold the cables as upright loops, so any "pull " is consistently towards the front centre.

Nothing was moving much or retaining any offset when I was deliberately trying to create head<>rail movements & the BLTouch is attached directly and rigidly to the underside of the printed cap I had the dial gauge on.

I'll do more measurements and gauge tests when I get chance.

I'll also try running heightmap with a tool on the head - the Hemera Direct tools are quite heavy and should produce a change if anything is loose anywhere.