BL Touch Mesh bed correction not working since minor rebuild
-
It seems strange that Z homing works but G29 probing doesn't. Please post your homez.g and homeall.g files.
Does the G29 command probe all the points and then give the error, or does it fail after the first point?
-
homez.g
[[language]] ; homez.g ; called to home the Z axis ; T0 ; select tool G91 ; relative coordinates G1 Z5 F200 ; lower bed G4 P500 ; wait for the bed to lower G90 ; absolute positioning G1 X50 Y50 F3000 ; go to first probe point and home the z axis M401 ; deploy the probe G30 ; calibrate Z-axis M402 ; retract the probehomeall.g
[[language]] G91 ; relative mode G1 S1 X-305 Y274.5 F3000 ; course home X or Y G1 S1 X-305 ; course home X G1 S1 Y274.5 ; course home Y G1 X4 Y-4 F600 ; move away from the endstops G1 S1 X-305 ; fine home X G90 G1 S1 Y50 ; fine home Y T0 ; select tool G91 ; relative coordinates G1 Z5 F200 ; lower bed G4 P500 ; wait for the bed to lower G90 ; absolute positioning G1 X50 Y50 F3000 ; go to first probe point and home the z axis M401 ; deploy the probe G30 ; calibrate Z-axis M402 ; retract the probeQuick video here of Z home, then probe. I cut before the probing fails as it continues on like this, then docks and fails. https://youtu.be/xX1OaR1FHOw
I did notice that before it fails, when the bed goes down the Z level reads 6mm and as it comes up to push the probe it reads -4.57 or so. Then when the probe docks and the bed moves to 20mm, lowing the bed to 0 results in a large gap between the nozzle and bed. Rehoming corrects this, is this cause or affect of the issue?
-
I've checked the code, and the only reason it ever produces the message "Error: Z probe was not triggered during probing move" during a G29 is when the probe didn't trigger at the point just probed. The remaining probe points are not probed. So I think something odd must be happening at the last point that it probes.
From the video, it appears to me that you have the BLTouch mounted very high and the nozzle is almost touching the bed when it triggers. Also you are on the verge of running out of leadscrew movement.
-
BLTouch mounting instructions say :
classic BLTouch : the flat surface of the BLTouch around the pin must be 8,3mm +/-0,2mm above the tip of the nozzle.
smart BLTouch : vertical distance between retracted pin and tip of nozzle should be 3mm +/-0,3mm or 8.5mm +/0,3mm measured from the flat surface.I made this thing once to ease adjustment : https://www.thingiverse.com/thing:2263497
-
Appreciatre all the help so far. I'll print that off and see what I can do to lower the probe a bit if necessary.
By manually probing the bed after re-levelling I think I've come across the issue. The difference between the highest and lowest points is huge.. I think every time I'm levelling the bed ome corner is consistently lower and I'm not noticing as the points I paper test are okay.
Going to make sure the Z carriage is as level as possible and go from there. Perhaps longer rods are the solution. As you pointed out it's very close to the limit of the rods.. it could be popping off slightly on one of the rods and then moving out of alignment every time it homes and comes down again.
Porbing at each corner gave me:
FrontLeft 1.022
BackLeft 1.397
BackRight 1.470
FrontRight 0.799 -
Looks like almost 0,7mm difference between highes and lowest point.
This is the ouput from my printer with BLTouch as a reference:
Number of probe points: 72
Maximum deviations: -0.095 / 0.057 mm
Mean error: -0.032 mm
RMS error: 0.029 mm -
Okay, I'm now running 1.19.2 and AJAX disconnects seem to be less of an issue now. The connection is still nowhere near as stable as 1.18 was though. New rods are in so there's an extra 15cm above the top end of the Z-axis so no chance of accidentally running off of the rods.
On your suggest Walter I printed the calibration tool you made, thank-you! With my nozzle touching the bed, it seems to fit near perfectly into the device. I have the bed roughly levelled since fitting the new rods and printed a quick square brim just to check it was roughly flat across the majority of the bed.
The touch still does not like to do mesh compensation probing though. I can probe in the point where it fails manually and it's successful. I held a ruler against the structure and it seemed that after probing each point it was going 1mm lower each time. For example, dive height is 5mm. First point would dive 5mm, move to second, dives 6mm, third, dives 7mm etc. And it seems to fail around the 4th point now. Maybe I'm going stir crazy though as I can't see anything in the code that would cause that.
Here's an Imgur album of my current setup and the brim that was printed: http://imgur.com/a/3eyCp
EDIT:
Here is a YouTube video of the probing failing now. It definitely looks to me like it's noticably lower by the 5th probe: https://youtu.be/dXOKNOCKlCg
Here is a YouTube video of me successfully probing that same point independently: https://youtu.be/Sby8lnM2F10Apologies for shakey cam
-
I've run the probe single point code from this post: https://www.duet3d.com/forum/thread.php?id=1330
And I can confirm that the bed is moving lower after every probe. I cannot work out what in the code could cause this.. Or am I just seriously misunderstanding what is supposed to be happening?
My results were:
-0.25
-1.27
-2.8
-4.58
-5 (Failure, probe not triggered)
Failure, probe not triggered for the rest of the runs and the bed moves progressively lower after every probe attempt. -
Does M122 show any errors?
To me, it seems like the Z motor just doesn't have the power to push the bed back up. It would have to be missing steps, which I think M122 would show.
I wonder how it would act if you set up probing points for G32 and put a G4 P*** after every move of the bed.
-
G30 P0 X20 Y20 Z-99999
G4 S1
G30 P1 X20 Y50 Z-99999
G4 S1
G30 P2 X20 Y80 Z-99999
G4 S1
G30 P3 X20 Y110 Z-99999
G4 S1
G30 P4 X20 Y140 Z-99999
G4 S1
G30 P5 X20 Y170 Z-99999
G4 S1
G30 P6 X20 Y200 Z-99999
G4 S1
G30 P7 X20 Y230 Z-99999
G4 S1
G30 P8 X20 Y260 Z-99999 S-1Here, if you have nothing better to do. Put this in your Bed.g instead of your M557 and run a G32. See if it can get past these 9 points.
-
Does M122 show any errors?
To me, it seems like the Z motor just doesn't have the power to push the bed back up. It would have to be missing steps, which I think M122 would show.
I wonder how it would act if you set up probing points for G32 and put a G4 P*** after every move of the bed.
Running M122 I see some stalled drives, does that mean it's missing steps? If this is the case any ideas why this would suddenly occur here? Before adding the BL Touch I printed a few parts on my old endstop setup and never noticed the bed not operating correctly or any artifacts in the Z axis on my prints.
[[language]] M122 === Diagnostics === Used output buffers: 3 of 32 (14 max) === Platform === RepRapFirmware for Duet WiFi version 1.19.2 running on Duet WiFi 1.0 Board ID: 08DDM-9FAM2-LW4S8-6JTDG-3SD6T-13YBW Static ram used: 21176 Dynamic ram used: 96040 Recycled dynamic ram: 1568 Stack ram used: 1304 current, 9152 maximum Never used ram: 3136 Last reset 00:04:06 ago, cause: power up Last software reset reason: User, spinning module GCodes, available RAM 3184 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: 0.0ms MCU temperature: min 32.4, current 32.8, max 33.1 Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0 Driver 0: stalled standstill Driver 1: stalled standstill Driver 2: stalled Driver 3: standstill Driver 4: standstill Date/time: 2017-09-06 00:11:24 Slowest main loop (seconds): 0.005646; fastest: 0.000092 === Move === MaxReps: 1, StepErrors: 0, FreeDm: 239, MinFreeDm 239, MaxWait: 6374ms, Underruns: 0, 0 Scheduled moves: 21, completed moves: 20 Bed compensation in use: none Bed probe heights: -0.324 -0.891 -1.685 -2.534 -3.688 === Heat === Bed heater = 0, chamber heater = -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 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 idle in state(s) 31 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.2 WiFi MAC address 5c:cf:7f:ee:68:10 WiFi Vcc 3.12, reset reason Turned on by main processor WiFi flash size 4194304, free heap 37176 WiFi IP address 192.168.1.120 WiFi signal strength -80dBm Reconnections 1 HTTP sessions: 1 of 8 Socket states: 0 2 0 0 0 0 0 0 Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
I think the stalled is just where it is when you ran the test. (Not entirely certain) Just tried it with my printer that is running and it changes every time I run M122. It doesn't show an error, so that is good. As for why it is happening, not sure. Hope to get you to run the G32 test and see how it goes.
-
I think the stalled is just where it is when you ran the test. (Not entirely certain) Just tried it with my printer that is running and it changes every time I run M122. It doesn't show an error, so that is good. As for why it is happening, not sure. Hope to get you to run the G32 test and see how it goes.
Thanks for taking the time to look.
Just ran the G32 with your code and its failing in the same way unfortunately, probes 4 points then fails. I've checked my bed movement, and when I command a 10mm move, it definitely only moves 10mm so it's not running too many steps per mm.
I was wondering if there could be a loose connection somewhere, but the first reading I do seems accurate. It's just all subsequent readings seem to move the bed. Would have thought if the connection was off either all readings would be funky or it wouldn't work full stop.
-
When you probed the same point over and over and had the failure, I think you can rule out a bad connection that is caused by any wire movement on the BL.
Did the G32 pause between probing and lowering the bed? Curious if that worked or not.
-
How about ruling out the BL. Command the Z up and down like the probing would do while measuring for any drop.
You'd have to set up a Macro.
;move bed up and down 25mm
G1 Z30
G1 Z5
G1 Z30
G1 Z5
G1 Z30
G1 Z5
G1 Z30
G1 Z5
G1 Z30
G1 Z5
G1 Z30
G1 Z5
G1 Z30
G1 Z5 -
When you probed the same point over and over and had the failure, I think you can rule out a bad connection that is caused by any wire movement on the BL.
Did the G32 pause between probing and lowering the bed? Curious if that worked or not.
It did indeed! Very nifty, ran it again as I realised it gave me time to measure the drop. It looks like it's losing 2mm every probe.
I'll try that macro over 25mm now
-
If you want to increase the time, just change the S*. That is in seconds or you can change it complete to P**** and run it in milliseconds.
-
G1 Z30
G1 Z5
G1 Z30
G4 S2
G1 Z5
G1 Z30
G4 S2
G1 Z5
G1 Z30
G4 S2
G1 Z5
G1 Z30
G4 S2
G1 Z5
G1 Z30
G4 S2
G1 Z5
G1 Z30
G4 S2
G1 Z5Here will give you 2 seconds on the table test.
-
If you want to increase the time, just change the S*. That is in seconds or you can change it complete to P**** and run it in milliseconds.
Well damn. It's not the probe. Thank-you for coming up with that test because it's very likely I wouldn't have ever considered it. Got hung up on the probe being off.
For some reason my bed is lowering an extra ~2mm when moving down and not when going up. Not enough holding torque?
I'm running a three leadscrew system powered by one hefty NEMA17 with 2:1 gearing.
-
Has to be torque. One more test. Lower your Z speed down to almost nothing. I see it is already low, but go lower. Run the last thing I posted while watching for anything that might not be doing what it is supposed too.
