BL Touch Mesh bed correction not working since minor rebuild
-
Hi guys,
Recently added a BL Touch (official as opposed to third part) to my system, and with the wiki details got it all working both for Z-homing and bed compensation.
Yesterday I noticed one of my rods was was slightly bent so I swapped it out for another one I had. Didn't touch any of the wiring, and double checked it all before putting it back in place and firing it up. Since then, my machine will still Z-Home correctly using the Touch and the probe displays a signal of around 625ish when testing the retraction.
However, now when I run the auto bed compensation, it runs the entuire process, the pin deploys and the bed raises until it touches it, the pin retracts and moves to the next point. On completion though, rather than displaying a heat map, I get the error: "G32 Error: Z probe was not triggered during probing move".
I have tried adjusting the height in my M558 to no effect. Nothing else has changed as far as I can tell. The bed has been levelled by hand and as I said, the probing appears to be successful until the error occurs. There is nothing in the config-override apart from heater controls. The machine is a CoreXY and the code is as follows:
config.g
[[language]] ; Configuration file for Duet WiFi (firmware version 1.18.1) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool on Sun Jul 16 2017 14:59:53 GMT+0100 (GMT Standard Time) ; General preferences M111 S0 ; Debugging off G21 ; Work in millimetres G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves M555 P1 ; Set firmware compatibility to look like RepRapFirmare M106 P1 T45 H1 S0.8 M667 S1 ; Select CoreXY mode M208 X0 Y0 Z0 S1 ; Set axis minima M208 X300 Y269.5 Z315 S0 ; Set axis maxima ; Endstops M574 X1 Y2 Z1 S0 ; Define active low and unused microswitches M558 P5 X0 Y0 Z1 H5 F120 T6000 ; Set Z probe type to unmodulated, the axes for which it is used and the probe + travel speeds G31 P25 X-43 Y0 Z1 ; Set Z probe trigger value, offset and trigger height ; Drives M569 P0 S1 ; Drive 0 goes backwards M569 P1 S0 ; Drive 1 goes forwards M569 P2 S1 ; Drive 2 goes forwards M569 P3 S0 ; Drive 3 goes backwards M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation M92 X80 Y80 Z629.92 E420 ; Set steps per mm M566 X900 Y900 Z12 E120 ; Set maximum instantaneous speed changes (mm/min) M203 X6000 Y6000 Z180 E1200 ; Set maximum speeds (mm/min) M201 X2000 Y2000 Z250 E250 ; Set accelerations (mm/s^2) M906 X1500 Y1500 Z1800 E950 I30 ; Set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Heaters M143 S320 ; Set maximum heater temperature to 320C M307 H0 B0 M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 0 M305 P1 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 1 M307 H7 A-1 C-1 D-1 ; Tools M563 P0 D0 H1 ; Define tool 0 G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C ; Network M550 Pduetwifi ; Set machine name M552 S1 ; Enable network ; Access point is configured manually via M587 by the user M586 P0 S1 ; Enable HTTP M586 P1 S0 ; Disable FTP M586 P2 S0 ; Disable Telnet ; Fans M106 P2 S1 I0 F500 H1 T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on M106 P0 F10 ; Custom settings are not configured ; Miscellaneous M501 T0 ; Select first tool bed.g
[[language]] ; bed.g ; called to perform automatic bed compensation via G32 ; ; generated by RepRapFirmware Configuration Tool on Sun Jul 16 2017 14:59:53 GMT+0100 (GMT Standard Time) ; Clear any bed transform M561 ; Home all axes G28 M557 X10:240 Y10:260 S25 ; Define grid M401 ; Deploy probe G29 ; Start mesh level M402 ; Retract probe G1 X50 Y50 Z20 F3000 ; Dock position -
Usually you need to increase the dive height (H in the M558 command) when that happens.
Which firmware version are you running?
-
Usually you need to increase the dive height (H ni the M558 command) when that happens.
Which firmware version are you running?
Thanks for the response! I increased mine up to 25, the effect this had was the bed moved 25mm away after each probe. Is that correct behaviour?
I'm currently running Firmware Version: 1.18.1 (2017-04-09)
-
Yes with dive height 25mm it will start 25mm above where it think the bed is, and be prepared to probe 25mm into where it think the bed is.
I don't understand the reason for the fault you observe. However, that area of the code has been extensively rewritten in firmware 1.19, so it may have been fixed. So please upgrade to 1.19 which you will find at https://github.com/dc42/RepRapFirmware/releases. Important! Read the upgrade instructions for 1.19 that are linked to first (ignore the bits about 1.19.1, scroll down to 1.19).
-
Thank you, I'll have a go at that tomorrow and see where we end up
-
Yes with dive height 25mm it will start 25mm above where it think the bed is, and be prepared to probe 25mm into where it think the bed is.
I don't understand the reason for the fault you observe. However, that area of the code has been extensively rewritten in firmware 1.19, so it may have been fixed. So please upgrade to 1.19 which you will find at https://github.com/dc42/RepRapFirmware/releases. Important! Read the upgrade instructions for 1.19 that are linked to first (ignore the bits about 1.19.1, scroll down to 1.19).
Okay, upgraded firmware and back online. While I was moving machine to put USB cable in I rechecked all wiring and it's correct.
Machine still uses the probe successfully to home the Z axis, but probing fails with the same error message. Since upgrading to 1.19 I seem to see more AJAX errors/disconnects and take a bit longer after a reboot to reconnect. Not sure if that's related at all.
-
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 probe homeall.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 probe Quick 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.