BL Touch Mesh bed correction not working since minor rebuild
-
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.
-
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.
I've just had to power down, up early for work in the morning.
I'll run it slow first chance I get tomorrow and let you know what it does.
Many thanks again!
-
No problem. While I am thinking about it though, if you still don't see any looseness and since the last thing you did was replace a lead screw…take that one back out and flip it over and test again. Maybe, it is rougher on one side versus the other. Rough coming down, no biggy because you have gravity helping.
-
No problem. While I am thinking about it though, if you still don't see any looseness and since the last thing you did was replace a lead screw…take that one back out and flip it over and test again. Maybe, it is rougher on one side versus the other. Rough coming down, no biggy because you have gravity helping.
There's still some wiggle room in the amps being given to the Z motor so I'll play with that a little bit. Thinking about it, because of the CoreXY design, whenever I measure bed movement to check steps/mm; I measure it lowering and it always seems to move correctly unless the downward motion follows an upward motion as we discovered last night
Is there any significance there? Perhaps acceleration or jerk could be moving it too quickly in the opposite direction?
-
Your M566 Z is already pretty low, as well as your M201 and M203, but I would adjust them lower just for testing purposes. Could always put the G4 between each move so that it has time to settle to see if that makes a difference. Are you running 1.8° or .9° motors? Commenting out the M350 might be something to try too.
I would think if you were to adjust your steps/mm for your up movement, you'd end up with a larger drop. Need to get both directions moving the same amount first, then adjust the steps to make it correct. You should be able to determine your steps needed by the degree of motor using, pitch of your lead screws, pitch of belt and pulley tooth count and your gearing.
-
Escaping the office in 2 hours, will try those things first.
All motors are 1.8°. In theory my steps/mm are correct based on calculations using those variables. Just using that as an example of a time when the bed moves in the downwards direction without dropping.
