[support or bug] Homing inbetween g33 iterations not consistent

[Hywelmartin]

So... I have the bugfix from today 180317 A delta :Mini Kossel from Anycubic(not so much Anycubic anymore) I'm using sensorless end stops (for the first time) TMC2130(the Chinese ones) During Delta auto calibration, in between iterations, the printer "homes" but the bump settings that I have don't work every time... and it's only z-axis...WTF

Expected behavior In between probing, the zeroing should be consistent. 10 mm bump on all axes

Actual behavior Sometimes the z-axis bump works and sometimes not...and it's after probing that it doesn't work

tmc_no_end_stops.zip

[thinkyhead]

In Marlin_main.cpp find the function named home_delta, and find these lines:

// Re-enable stealthChop if used. Disable diag1 pin on driver.
#if ENABLED(SENSORLESS_HOMING)
  sensorless_homing_per_axis(A_AXIS, false);
  sensorless_homing_per_axis(B_AXIS, false);
  sensorless_homing_per_axis(C_AXIS, false);
#endif

Move them so that they come after these lines:

// At least one carriage has reached the top.
// Now re-home each carriage separately.
HOMEAXIS(A);
HOMEAXIS(B);
HOMEAXIS(C);

Hopefully that fixes the issue.

[Hywelmartin]

@thinkyhead like this:

Code Snippet

```cpp #if ENABLED(DELTA) /** * A delta can only safely home all axes at the same time * This is like quick_home_xy() but for 3 towers. */ inline bool home_delta() { #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) DEBUG_POS(">>> home_delta", current_position); #endif // Init the current position of all carriages to 0,0,0 ZERO(current_position); sync_plan_position(); // Disable stealthChop if used. Enable diag1 pin on driver. #if ENABLED(SENSORLESS_HOMING) sensorless_homing_per_axis(A_AXIS); sensorless_homing_per_axis(B_AXIS); sensorless_homing_per_axis(C_AXIS); #endif // Move all carriages together linearly until an endstop is hit. current_position[X_AXIS] = current_position[Y_AXIS] = current_position[Z_AXIS] = (delta_height + 10); feedrate_mm_s = homing_feedrate(X_AXIS); buffer_line_to_current_position(); stepper.synchronize(); // Re-enable stealthChop if used. Disable diag1 pin on driver. //#if ENABLED(SENSORLESS_HOMING) //sensorless_homing_per_axis(A_AXIS, false); //sensorless_homing_per_axis(B_AXIS, false); //sensorless_homing_per_axis(C_AXIS, false); //#endif MOVED FURTHER DOWN // If an endstop was not hit, then damage can occur if homing is continued. // This can occur if the delta height not set correctly. if (!(Endstops::endstop_hit_bits & (_BV(X_MAX) | _BV(Y_MAX) | _BV(Z_MAX)))) { LCD_MESSAGEPGM(MSG_ERR_HOMING_FAILED); SERIAL_ERROR_START(); SERIAL_ERRORLNPGM(MSG_ERR_HOMING_FAILED); return false; } endstops.hit_on_purpose(); // clear endstop hit flags // At least one carriage has reached the top. // Now re-home each carriage separately. HOMEAXIS(A); HOMEAXIS(B); HOMEAXIS(C); // Re-enable stealthChop if used. Disable diag1 pin on driver. SO.. HERE IT IS NOW #if ENABLED(SENSORLESS_HOMING) sensorless_homing_per_axis(A_AXIS, false); sensorless_homing_per_axis(B_AXIS, false); sensorless_homing_per_axis(C_AXIS, false); #endif // Set all carriages to their home positions // Do this here all at once for Delta, because // XYZ isn't ABC. Applying this per-tower would // give the impression that they are the same. LOOP_XYZ(i) set_axis_is_at_home((AxisEnum)i); SYNC_PLAN_POSITION_KINEMATIC(); #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) DEBUG_POS("<<< home_delta", current_position); #endif return true; } #endif // DELTA ```

[Hywelmartin]

Hmmm...Made the changes suggested...

I'm no master of this but sometimes it triggers the "endstops" a little to early... Is Z min activated during homing??? I have tried bump sensitivity up to 25.... and it doesn't work

M43 E1 gives me... not much ...

SENDING:G28
  Z_MIN:0
  Z_MIN:1
Homed..... not really....
>>> g28
SENDING:G28
  Z_MIN:0
  Z_MIN:1
  Y_MAX:1
  Y_MAX:0
  Z_MIN:0
  Z_MIN:1

Homed..... not really....

>>> g28
SENDING:G28
  Z_MIN:0  Z_MAX:1
  X_MAX:1
  X_MAX:0
  Z_MIN:1
  Z_MAX:0
  Z_MIN:0
  Z_MIN:1

Homed..... not really....

Normally I get something like this

>>> g28
SENDING:G28
  X_MAX:1  Z_MIN:0  Z_MAX:1
  X_MAX:0
  Z_MIN:1
  Y_MAX:1
  Y_MAX:0
  Y_MAX:1
  Z_MAX:0
  Z_MAX:1
  Y_MAX:0
  Z_MAX:0
  Z_MIN:0
  Z_MIN:1
  Z_MIN:0
  Z_MIN:1
  Z_MIN:0
  Z_MIN:1
  Z_MIN:0
  Z_MIN:1
  Y_MAX:1
  Z_MIN:0  Z_MAX:1
  Z_MIN:1
  Z_MAX:0
  Z_MAX:1
  Y_MAX:0
  Z_MAX:0

Z min is inverted and a Piezo monted on the hotend..

[thinkyhead]

If Marlin sees an endstop or probe pin go into its TRIGGERED state while endstops are enabled (as with homing) it will halt the movement. That includes probes, but only if the probe is configured to be used for homing. To troubleshoot, disconnect your piezo probe and test homing to see if the piezo is involved.

[Hywelmartin]

@thinkyhead no difference with piezo unplugged... @teemuatlut is there a way to monitor if Stallguard been triggered(or live)?? Is there a way to "trigger" DIAG1 to see if the drivers work..

my output from M122

        X   Y   Z   E0
Enabled     true    true    true    false
Set current 800 800 800 800
RMS current 795 795 795 795
MAX current 1121    1121    1121    1121
Run current 25/31   25/31   25/31   25/31
Hold current    12/31   12/31   12/31   12/31
CS actual       25/31   25/31   25/31   12/31
PWM scale   83  80  85  0
vsense      1=.18   1=.18   1=.18   1=.18
stealthChop true    true    true    true
msteps      16  16  16  16
tstep       1048575 1048575 1048575 1048575
pwm
threshold       0   0   0   0
[mm/s]      -   -   -   -
OT prewarn  false   false   false   false
OT prewarn has
been triggered  false   false   false   false
off time        5   5   5   5
blank time  24  24  24  24
hysteresis
-end        2   2   2   2
-start      3   3   3   3
Stallguard thrs 12  12  12  0
DRVSTATUS   X   Y   Z   E0
stallguard
sg_result       0   0   0   0
fsactive
stst        X   X   X   X
olb
ola     X
s2gb
s2ga
otpw
ot
Driver registers:   X = 0xA0:19:00:00
    Y = 0x80:19:00:00
    Z = 0x80:19:00:00
    E0 = 0x80:0C:00:00

I sloooowed down the homing speed a lot and got

>>> M43 E1
SENDING:M43 E1
endstop monitor enabled
>>> G28
SENDING:G28
  Z_MAX:1
  X_MAX:1
  X_MAX:0
  X_MAX:1
  X_MAX:0
  Y_MAX:1
  Y_MAX:0
  Y_MAX:1
  Y_MAX:0
  Z_MAX:0
  Z_MAX:1
  Z_MAX:0

So the drivers report something

[teemuatlut]

StallGuard works so that the driver measures motor load and gives it a value. Then you can set an offset to this value and we call this the sensorless homing threshold. If the resulting value is 0 then the driver sets a diag pin to high or low. This change can then be detected by the motherboard and Marlin and interpreted as a triggered endstop.

Because of this behavior the diag signal acts more like a short pulse than a constant voltage level. Although I've also seen the signal to "stick". Thus the suggestion to turn off bump distance.

I believe @tcm0116 will know more about using stallGuard with a delta printer.

[Hywelmartin]

Then my DIAG1 signal is sticky........ I believe that homing speed vs trigger sensitivity is crucial to get accuracy.. Thanks for quick reply @teemuatlut

[mylife4aiurr]

Already a confirmed bug, just adding my experience with bugfix 1.1.x downloaded 4/1/18

I have something similar with my delta. I decided to not use sensorless homing because of it.

For my printer a sensorless homing sensitivity of -5 to 3 works best, to lightly tap max height and then stop. Problem 1. The sensitivity (-5 to 3) needed to just lightly tap the max height of printer is too light for all motors to move in unison to max height. So what happens is stepper 1 will move toward max, stop a short distance and then stepper 2 will begin to move and stop a short distance then finally third stepper moves a short distance. So if the effector happens to be close to bed, the firmware thinks its homed to max, but in reality its maybe in middle of printers build height. Maybe homing needs two speeds/sensitivities as it approaches max. For me something like a value of 5 to 10 until it gets close to max, but then (-5 to 3) as it gets close to max.
If I choose a sensitivity value over 5 all steppers will home to max in unison and trigger at printers max height - (GOOD), but it hits the max height a little harder then I'd like.

Problem 2. Even if I use sensitivity (-5 to 3) G33 auto delta configuration slams into max height hard, as though its not using the correct sensor less homing sensitivity (BAD). For instance, normal movement when I using G33 to probe the bed of my printer, the printer slows down as it approaches the bed, then just lightly taps printer bed with nozzle. Could that same logic be done with homing toward max. As printer approaches max height, wish it would slow down and lightly tap max height using the set sensor less homing sensitivity.

Problem 3. So I tried sensorless homing value of 5. 4 or 5 seems to be the point at which the driver doesn't trigger from the resistance of my rods but from an actual object in its path. G33 - using a value of 5, steppers home to max height harder then I'd like and wouldn't use and then moves toward the bed of printer. The effector gets about 15mm to 20mm from max height and starts to hiccup up and down. This continues until I pull the plug.

Concerns If @Hywelmartin is able to use G33 in the downward movement from max to min towards the bed, then I probably need to use a sensitivity greater then 5. But for me 5 is already too tough on the printer.

My printer uses nozzle as probe. During G33 or G29 the electric contact of nozzle against the printers bed defines the delta parameters and bed leveling mesh points. Will the sudden stop of effector do to electric contact interact negatively with sensorless homing? Wondering how the logic works if tmc drivers are used as endstops but your also using a probe. I didnt get that far to try it. Maybe tmc sensorless homing not active for moves toward min for deltas during g33, g29?

would love @tcm0116 's Input

[boelle]

@Hywelmartin is "issue" still there with latest bugfix 2.0?

[Hywelmartin]

I have no idea... I'm using Klipper nowdayd

On Wed, 20 Feb 2019, 11:40 Bo Herrmannsen, notifications@github.com wrote:

@Hywelmartin https://github.com/Hywelmartin is "issue" still there with latest bugfix 2.0?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/10141#issuecomment-465520880, or mute the thread https://github.com/notifications/unsubscribe-auth/AgJwJqvhjF4sXK0BTXQADkhOmdclVXeyks5vPSYTgaJpZM4Su7C1 .

[boelle]

then maybe hit the close button below?

[Hywelmartin]

Yes for my part it's ok

some thing to implement that is in klipper is the https://github.com/KevinOConnor/klipper/blob/834b9e3d9267332875470dfb3e9fa0a9fb7bc936/config/example-extras.cfg#L410

Den ons 20 feb. 2019 kl 12:07 skrev Bo Herrmannsen <notifications@github.com

:

then maybe hit the close button below?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/10141#issuecomment-465529504, or mute the thread https://github.com/notifications/unsubscribe-auth/AgJwJj5kMhuPbvGiAkhrMXpoCO9_4-Kuks5vPSxWgaJpZM4Su7C1 .

[thinkyhead]

some thing to implement that is in klipper…

(Endstop moves can stop on full steps or a selected "phase.")

[mylife4aiurr]

I sorta felt Delta's never got much love and it was frustrating getting Marlin devs to look at issues I brought up without treating me like I was using GitHub as tech support rather then actually code issues. This lead me to just sorta give up on Marlin with a delta...... I still have the delta printer in question but have shevled it. Since this post I have upgraded it to 32bit Marlin 2.0 and tmc 2208's, with a bltouch for bed probing. Recently I bought some bigtreetech 2209's v1. 2. When I used 2130's it was my dream to have sensor less homing and probeless bed probing all working well on a delta using tmc 2130's or now 2209's. At the time thinkyhead said it would be something for Marlin 2.0. I can dust this printer off and install the 2209 or 2130's if there is commitment for Delta's within Marlin. The wiring is alot simpler now on the skr board to do sensor less homing, then on the 8bit board I was using at the time. Let me know I'm willing to help. I have donated to Marlin devs and I can donate time testing if its something people would like to work on now.

[Allarabie]

YES @mylife4aiurr +1 More Delta Support

Sorry for this rant.. very frustrated. I have been struggling for almost 2 weeks now, trying to just get Marlin 2.0 sensorless features to work on my delta (SKR1.3, TMC2130). It seems like Marlin's Delta support is still very lacking. The bug listed above still exists in the latest Marlin 2.0 release. I've also notice several other "Delta" things that seem to only apply to cartesian printers. Im no programmer, but It looks like some of the probing code for deltas is still set up for cartesian, it only re-enables stealthchop for the X and Y axis but not Z.. So, for example, when I probe, X and Y home nice and smooth, and Z smashes into the end of tower. Then after probing is done, the motors sit there and hum until I send M569 or disable the steppers. I don't mind having to change half a dozen settings to get things to work, thats expected. But whats not expected, and super frustrating, is having to edit core Marlin files to get things to work properly. Really makes me wish more development time was being dedicated to Delta support. Anyway, I finally gave up on both sensorless homing/probing and decided to focus only on probing, which seems much more useful on a delta.
Now the Delta homes on endstop switches (still smashing into the Z tower), and it actually does probe sensorlessly, but the results are incorrect,. LOL.. After both G33 and G29 (and yes M500, then double check they were saved with M503) the print head is almost 1mm off at the Y tower and digs into the bed at the Z tower (ruined 2 beds this week, thanks). I have double/triple checked all my measurements (radius, rod length, etc...) and nothing changes the results.
BTW, this is a great article on the effects of having Rod/Radius measurements incorrect: http://boim.com/DeltaUtil/CalDoc/Calibration.html

Anyway, sorry to rant, I would love to see more Delta support, specifically Sensorless Features. Thanks.

[Hywelmartin]

@mylife4aiurr if you have a spare computer (rpi3) test Klipper..... 😁

[github-actions[bot]]

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.