BL Touch Mesh bed correction not working since minor rebuild
-
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.
-
Okay, I ran the same macro as is with all those settings turned right down and M350 commented out. Unfortunately no fix.
Reset the settings and bumped Z motor amps up to 2.0 from 1.8. No better.
I then ran with a 2 second gap between every command and this did not work.
If I command the Z +10 then -10 via the web control buttons, it moves up 10 and down 10.
No problems. I noticed this uses G91 before the movements would this be making a difference?EDIT: It appears to be struggling on the move ups intermittently using the web controls. This leads me to believe the problem is not with the bed lowering too far, but raising it enough. I'm going to take the screws off and re-assemble
-
Glad to hear you are on the right direction now.
The G91 are just moves, where as the G1 are locations.
-
So it's not perfect but, it's an improvement!
0.533 0.533 0.519 0.501 0.527 results from probing the same point.
Thanks all for your patience and feedback. You've been awesome!
-
G91 sets it to relative positioning which makes sense for the web control as its +/- the value from where ever it is now. It is normal to set back to absolute positioning (G90) for normal operation as gcode files produced by slicers use absolute positioning as a default
-
That does look better. Were your M566 and M102/3 still low when running those tests or did you put them back to where they were?
