Dual homing switches for fast homing
-
That would be great, except the firmware commands an immediate halt, without the option to decelerate.
AFAIK, you can’t disable this “feature.”
-
@bot said in Dual homing switches for fast homing:
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.
-
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
-
seems to be some sort of support of something of the sort?
https://github.com/dc42/RepRapFirmware/blob/90c6b876d29e8de72da5b044327d2bd8ac073279/src/Movement/DDA.cpp#L1563 -
@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.
-
yeah, saw that, but the second pass is normally controlled by g-code so not sure what that is actually meant to do.
-
@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:
- fast home, lots of small moves, first endstop triggers change in acceleration and/or max speed. second endstop sets course homing position
- 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)
- 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
-
Suppose you could
M581 S1 ...at the beginning of the homing file andM581 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.
-
@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.
-
(Or alternatively keep the spacing so that acceleration limit will prevent you from reaching too high a velocity)
