Dual homing switches for fast homing

[Alcez42]

I would like to have a second homing switch placed let's say 20mm from the first one. Then you can have the gantry move at high speed til it reach that first switch, then it slows down to normal homing speed the last bit. Would this be possible at all?

You could use optic or magnetic sensors for the first one.

[Danal]

Two switches not needed. Deltas do this now. Here's a typical file that "high speeds" F1800 until it hits the one switch (one on each tower), then "backs up", then "low speed" F360 touches again for accuracy:

; homedelta.g
; called to home all towers on a delta printer
;
; generated by RepRapFirmware Configuration Tool on Fri Jan 12 2018 20:07:04 GMT-0600 (Central Standard Time)
G91                        ; relative positioning
G1 S1 X955 Y955 Z955 F1800 ; move all towers to the high end stopping at the endstops (first pass)
G1 X-5 Y-5 Z-5 F1800 S2    ; go down a few mm
G1 S1 X15 Y15 Z15 F360     ; move all towers up once more (second pass)
G1 Z-10 F6000               ; move down a few mm so that the nozzle can be centred
G90                        ; absolute positioning
G1 X0 Y0 F6000             ; move X+Y to the centre

If the carriage or gantry on a Cartesian has too much inertia to stop quickly enough when it hits a mechanical switch, then use optic or inductive for the only one, arranged so that the high-speed first pass can safely "overshoot", perhaps even overshoot into a mechanical "bumper". Then back up and do the low speed pass.

Anyone could do this today, with the appropriate mechanics and a few changes to the homeall.g file. (or homedelta.g).

[bot]

@danal

That would be great, except the firmware commands an immediate halt, without the option to decelerate.

AFAIK, you can’t disable this “feature.”

[Danal]

@bot said in Dual homing switches for fast homing:

@danal

That would be great, except the firmware commands an immediate halt, without the option to decelerate.

AFAIK, you can’t disable this “feature.”

Correct. When the endstop triggers on the first pass, the firmware stops sending step pulses to the motors. On something too massive to be comfortable with this, handle it mechanically. Clutches, overcenters with springs, etc. Allow overshoot that doesn't hurt anything.

Handling it mechanically also helps a machine not damage itself if something else happens, like the controller faulting, a wire breaking, a power fault, etc.

Stated another way, on something with too much inertia to allow a motor to stop, it still must be setup for the potential of a motor to stop, because it will happen someday. Why not exploit this? Turn a necessity into a feature.

[Alcez42]

So... Mechanical dampening seems a bit overkill though. How hard would it be to just have the motor deaccelerate instead of full stop when doing first pass? I guess that would be enough for me at least

[A Former User]

seems to be some sort of support of something of the sort?
https://github.com/dc42/RepRapFirmware/blob/90c6b876d29e8de72da5b044327d2bd8ac073279/src/Movement/DDA.cpp#L1563

[Alcez42]

@bearer

ah, good find. Though it states "As this is only called for homing moves and with very low speeds, we assume that we don't need acceleration or deceleration phases." in the function called. So I believe this will lower the speed for the second pass, but it will still be a hard stop for the first. I might be able to modify it myself from here though. But a proper implementation would be preferable.

[A Former User]

yeah, saw that, but the second pass is normally controlled by g-code so not sure what that is actually meant to do.

[T3P3Tony]

@alcez42 might be worth seeing if you can configure your first endstop as a trigger that dropped the max speed and acceleration. AFAIK that wont effect the currently executing move however you can get around that by splitting the homing move into lots of small moves. The issue is that the trigger will execute every time that switch is crossed - so you will have to ensure that it is not crossed except when homing. Also have a 3rd step in the homing files:

1. fast home, lots of small moves, first endstop triggers change in acceleration and/or max speed. second endstop sets course homing position
2. back off a bit, then slow home for fine homing position. This may not be necessary because you already ended up doing a slow home on 1)
3. move back past the first endstop, then reset the max speed and acceleration to normal.

You will have to try this and see if it works.

Edited

Something else to try is to configure the first endstop as a trigger at the start of the homing file, and remove that trigger it at the end of the homing file. that way it only works when the homing file is running.

P.S. https://duet3d.dozuki.com/Wiki/Gcode#Section_M581_Configure_external_trigger

[A Former User]

Suppose you could M581 S1 ... at the beginning of the homing file and M581 S-1 ... at the end of the homing file to avoid issued during normal use.

But if you start homing between the two switches you'll head full speed to the limit switch, unless you ensure the second switch is triggered and remains triggered for the remainder of the travel on that axis.

[T3P3Tony]

@bearer yes thats a good point - it needs to remain triggered and a "check for trigger" should be at the beginning of the homing file.

[A Former User]

(Or alternatively keep the spacing so that acceleration limit will prevent you from reaching too high a velocity)