[BUG] Delta sensorless homing z axis different speed / acceleration #21057
Comments
|
timeburn - do you have sensorless homing working for a delta printer? For some reason I've been unable to get it to work. |
|
Sure, it works. TMC2209s on a SKR 1.4 turbo. Testing with low current and
low sensitivity, it seems to work.
Not sure how much I trust it, haven't printed anything in this physical
build yet. Not while it homes the towers at different speeds.
I'd swear it did not do this with an earlier release I'd tested to make
sure it was viable. 2.0.5 maybe?
What electronics are you trying to use? Do you have backoff enabled? That
was broken until recent dev.
…On Sat, Feb 13, 2021, 12:42 PM BirkBinnard ***@***.***> wrote:
timeburn - do you have sensorless homing working for a delta printer? For
some reason I've been unable to get it to work.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#21057 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCGXUMLHFMLL7Z5VGLNSVTS63I2ZANCNFSM4XPZF5AA>
.
|
|
I've got an Atom2 delta which is quite similar to FLS QQS-Pro. I had SKR 1.4 Turbo with TMC2209's in it but got a strange error (All Low) that I couldn't resolve, so I swapped the board for an SKR GTR 1.0. I had to give up on getting sensorless to work because of this problem: #20986. In essence, when I tried to Home, the printer would move only the Z column stepper up until the end effector crashed into the Z tower. Home should move all steppers at once, right? When I realized I was not going to get sensorless to work I replaced the 2209's with 2208's and now am working on a configuration that uses microswitch endstops. Of course I'd much rather do sensorless. I've been comparing your dev version of Configuration.h with mine and noticed that you have #define NOZZLE_AS_PROBE enabled, which I do not. This is a surprise to me because I started with the Marlin sample config files for the FLSun QQS-Pro delta printer. Note that I am using the BugFix 2.0.7.2 (I think - why don't they put the version number where is can be found?) which I downloaded about 2 weeks ago, and I am compiling using the current version of VSCode on a Win10/64 PC. I checked your COnfiguration_adv.h and it has backoff disabled, but mine has it enabled. I just noticed this: #define HOMING_BUMP_MM { 0, 0, 0 } which is probably wrong. But that's a minor problem compared to Home moving only one stepper at a time. I'm perfectly aware that I may have some parameter setting(s) wrong, but I've been working on this for almost 3 months and not found anything obvious. If you are sufficiently motivated to look at them my configuration files are in the BUG #20986 posting. |
|
If backoff is enabled with sensorless, there is a bug in 2.0.7.2 that will
cause it to skip the initial all-axis home move. That was supposedly fixed
in dev, but I have not tested.
That, coupled with this bug, might make it act like you are describing.
It may fail to move the first two towers, but then z somehow accelerates
differently and crashes.
I turned off backoff, and dropped sensitivity on x and y until they started
moving properly. Keep the motor currents low to get started, so the motor
skips instead of breaking anything as you dial in sensitivity.
I have sensorless working great on other machines with more classic
geometry. Delta is a different beast it seems
…On Sat, Feb 13, 2021, 1:32 PM BirkBinnard ***@***.***> wrote:
I've got an Atom2 delta which is quite similar to FLS QQS-Pro. I had SKR
1.4 Turbo with TMC2209's in it but got a strange error (All Low) that I
couldn't resolve, so I swapped the board for an SKR GTR 1.0. I had to give
up on getting sensorless to work because of this problem: #20986
<#20986>. In essence, when
I tried to Home, the printer would move only the Z column stepper up until
the end effector crashed into the Z tower. Home should move all steppers at
once, right?
When I realized I was not going to get sensorless to work I replaced the
2209's with 2208's and now am working on a configuration that uses
microswitch endstops. Of course I'd much rather do sensorless.
I've been comparing your dev version of Configuration.h with mine and
noticed that you have #define NOZZLE_AS_PROBE enabled, which I do not. This
is a surprise to me because I started with the Marlin sample config files
for the FLSun QQS-Pro delta printer.
Note that I am using the BugFix 2.0.7.2 (I think - why don't they put the
version number where is can be found?) which I downloaded about 2 weeks
ago, and I am compiling using the current version of VSCode on a Win10/64
PC. I checked your COnfiguration_adv.h and it has backoff disabled, but
mine has it enabled. I just noticed this: #define HOMING_BUMP_MM { 0, 0, 0
} which is probably wrong. But that's a minor problem compared to Home
moving only one stepper at a time.
I'm perfectly aware that I may have some parameter setting(s) wrong, but
I've been working on this for almost 3 months and not found anything
obvious. If you are sufficiently motivated to look at them my configuration
files are in the BUG #20986
<#20986> posting.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#21057 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCGXUJMWBWM7VZOX4KD5QTS63OW3ANCNFSM4XPZF5AA>
.
|
|
OK - thanks for the info about backoff. I'll try putting the 2209's back and disabling backoff. I'll also try #define NOZZLE_AS_PROBE and see if that helps. My settings for the 2209 current values are 300, 275, 275 which seems to be about right. I've set sensitivity for all to 75. Here's hoping I can get the single stepper motion fixed so I can proceed with everything else. Thanks for your help with this - it's a shame there isn't some better way for people to find out about issues like this. Edit: #define NOZZLE_AS_PROBE caused errors saying it was incompatible with sensorless probing, so I commented it out and that allowed the compile to complete. Edit #2: No joy - same results as before: individually the X, Y, Z steppers move in both directions just fine. But Home moves Y first, then Z, (they both Home properly), but X never moves. |
|
NOZZLE_AS_PROBE is for the smart effector, nothing to do with sensorless
homing.
Now if you want to do sensorless _probing_, that is a different story. It
can be enabled, but I didn't find it sensitive enough for use in my last
attempt. I got a duet smart effector instead.
Curious to know how your homing turns out, if you have the same variable
speed issue I'm seeing.
…On Sat, Feb 13, 2021, 4:42 PM BirkBinnard ***@***.***> wrote:
OK - thanks for the info about backoff. I'll try putting the 2209's back
and disabling backoff. I'll also try #define NOZZLE_AS_PROBE and see if
that helps. My settings for the 2209 current values are 300, 275, 275 which
seems to be about right. I've set sensitivity for all to 75.
Here's hoping I can get the single stepper motion fixed so I can proceed
with everything else. Thanks for your help with this - it's a shame there
isn't some better way for people to find out about issues like this.
Edit: #define NOZZLE_AS_PROBE caused erros saying it was incompatible with
sensorless probing, so I commented it out and that allowed the compile to
complete.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#21057 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCGXUN7Y6GNPOHD2J6EXEDS64E73ANCNFSM4XPZF5AA>
.
|
|
Well it looks like I'll be giving up on both sensorless homing and sensorless probing. Homing fails because I can't find a way to get all 3 steppers to move at one time. And as I posted in my original Bug, if the hotend is far away from home position the sliders crash into the towers because they move individually instead of all together. And probing can't happen unless the printer can establish it's home position - which it can't. I thought that if I could get sensorless homing to work I might be able to do probing with a BLTouch device. But BTT doesn't label or identify what the BLTouch pins are, so of course I hooked them up backwards and fried the BLTouch. So it looks like I'll have to go back to 2208's and 4 microswitches. |
|
Hello. |
|
Yeah I had just tracked this down to the IMPROVE_HOMING_RELIABLITY setting a couple days ago, but had not yet dug into why. looks like the X & Y steppers were affected by the setting, but not Z. Your patch addresses it. |
|
This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Bug Description
Z axis moves at a faster speed when individual homing.
This is on a Delta with sensorless homing using TMC2209s
The initial move runs with all towers at the same accel and speed.
individual homing moves then run, with Z moving much faster than X and Y before it.
Among other things, it creates the need for a different sensitivity setting for that motor, compared to the others.
Current, Jerk, Accel and Feedrate settings are the same for all axes.
I have not tested this config with sensorless disabled. This build of the printer excluded the sensors.
S-curve Acceleration and Homing Backoff have been disabled.
This has been tested with 2.0.7.2 and today's dev from git. Both behave the same.
Configuration Files
Configurations-2072_and_dev.zip
The text was updated successfully, but these errors were encountered: