backing out from the endstop
-
thanks, the backoff is what I do currently.
What do you think of G1 H parameter that would guard the move (stop when a endstop is triggered or released, why not 2 options) but not change the origin (and we'll do whatever G92 we want from there).
-
@nraynaud The most common type of end stop switch is a simple microswitch and usually, there is quite a lot of hysteresis between when they trigger closed compared to open. So that could cause problem if the firmware simply looked for a change of state because the gantry that switches the end stop could be in either of two physical positions. But as David has pointed out, we can easily invert the input so that we can decide whether we want to look when the switch is open or closed. So your homing file could do say a G1 negative move towards the end stop and stop in that position when it triggers. Then have an M574 to invert the input, then do a G1 positive move away from the end stop and stop in that new (different) position when the end stop triggers again.
-
Yeah deckingman, I don't intend to home backwards, that's why I am looking for a solution to get out of the switch and come back at it in the correct orientation. (and also because there are tools and docks everywhere, only Y+ moves are allowed there)
has anyone used the probing cycles to get out of those situations? for example probing to get out and homing to click in the correct orientation?
I feel like this zone delimited by a switch is a good idea, because if I have an emergency stop or some collision that cause a stall, I know that I can't home in a straight line.
And I would probably like to use the same technique to detect if there is a tool on the head after an emergency stop.
-
@nraynaud I'm not sure that I really understand the question or what it is you are trying to achieve. When you say "that's why I am looking for a solution to get out of the switch and come back at it in the correct orientation" that's what I consider to be normal homing procedure. That is to say, do G1 negative towards a switch at a fastest speed and stop when a switch triggers, then do G1 positive by a small amount (say 10mm), then repeat the G1 negative move and stop when the switch triggers but at a slower speed.
-
I am trying to exit the danger zone (Y negative) at 40000 mm/min and stop right after the border, even if a lot of steps have been skipped. But I want to go quick, because I'll do that at every tool change.
-
I've been working out the tool change macros, and homing, for a Jubilee tool changing printer.
In terms of homing Y, my files do this:
; Home Y Axis G91 ; Set relative mode G1 Y-360 F6000 H1 ; Big negative move to search for endstop G1 Y4 F600 ; Back off the endstop G1 Y-10 F600 H1 ; Find endstop again slowly G90 ; Set absolute mode G1 Y0 F6000 ; Move to Y0.
Where the Y axis is defined in config.g as
M208 X-5:305 Y-10:365 Z-0.5:220
. Note the negative 10 for origin of Y. Therefore, that very last Y0 move places the carriage about 10mm off the switch.The above works for any starting position of Y. Including pressing the switch.
Does that accomplish what you want?
P.S. Emergency stop, sensing things afterwards? Since only a human can estop (or, really, restart after an estop), in my opinion it is OK for that human to unmount the current tool (home the lock axis) and return it to its parking posts.
-
@nraynaud said in backing out from the endstop:
the tool changer is activated by a cam shaft, and zeroing it is a bit of an issue when I can't trigger on edge.
Jubilee has a limit switch for "locked" (aka "home") and a limit switch for "enough torque has occured to assure the tool is locked". Note that second one is not an absolute position. It is a torque sensor. This is because Jubilee uses some plastic where E3D uses metal. With metal parts, this second switch could be a position sensor. These two switches are wired in series and connected to the low endstop for the tool lock axis (U).
Unlock a tool? The code is very similar to homing that axis (see below)
Lock a tool? Same thing, other direction.Also, lock/unlock are in macros, so the pre/post/free files can invoke them.
There are no "edge" issues with this setup.
; Disengage the toolchanger lock G91 ; Set relative movements G1 U-2 F9000 H2 ; Back off the limit switch with a small move G1 U-360 F9000 H1 ; Perform up to one rotation looking for the home limit switch G90 ; Restore absolute movements
; Engage the toolchanger lock G91 ; Set relative mode G1 U2 F9000 H2 ; Back off the limit switch with a small move G1 U360 F9000 H1 ; Perform up to one rotation looking for the torque limit switch G90 ; Set absolute mode
; Home U Axis G91 ; Set relative mode G1 U-360 F9000 H1 ; Big negative move to search for home endstop G1 U6 F600 ; Back off the endstop G1 U-10 F600 H1 ; Find endstop again slowly G90 ; Set absolute mode
-
here is my free0.g (axis W is the cam shaft):
G91 ; relative positioning G0 Z2 ; lift Z G1 E-20 F10000 G90 ; absolute positioning M913 Y180 X180; bump Y axis current G53 G0 X212.5 Y0 F40000 ; get in front of the dock M208 Y-70 S1 ; Set axis minimum G53 G0 Y-55 G53 G1 Y-66 W11 F10000 G53 G1 Y-55 F2000 M913 Y100 X100; restore Y axis current M208 Y0 S1 ; Set axis minimum G53 G0 Y2 F40000
here is my tpre0.g:
G91 ; relative positioning G0 Z2 ; lift Z G90 ; absolute positioning G53 G0 X212.5 Y2 F40000 G53 G1 Y-10 F500 H1 ; re-home Y M913 X180 Y180; bump axis current M208 Y-70 S1 ; Set axis minimum G53 G0 Y-60 W1 F40000 ; move and unlock dock G53 G1 Y-66 W1 F10000
here is the tpost0.g:
M98 P"tpostall.g" G1 E20 F8000
and the tpostall.g:
M703 ; load filament parameters G1 Y-60 F40000 M913 X100 Y100; axis current G53 G0 Y2 F50000; move back M208 Y0 S1 ; Set axis minimum G53 G1 H1 F500 Y-10 ; home Y G53 G0 X200 F50000 ; go towards the prime tower
my problem is that some steps might be skipped during those operations, either hitting the dock or pulling on the springs, and I want to be able to recover without losing time in the cases where I don't need to recover.
I was looking into stall detection, but I don't feel confident I can detect it reliably.
Of course with a cam shaft there is no hard stop, so finding the angular position is normally done by edge triggering.
the general design is visible here: https://twitter.com/nraynaud/status/1203771796929044480
-
@nraynaud said in backing out from the endstop:
thanks, the backoff is what I do currently.
What do you think of G1 H parameter that would guard the move (stop when a endstop is triggered or released, why not 2 options) but not change the origin (and we'll do whatever G92 we want from there).
I don't advise using G92 in homing files, because if the G1 H1 move fails to trigger the endstop, it doesn't set the homed status so the machine is safe from doing ordinary moves; but if you use G92 then the axis gets flagged as homed anyway.
-
@dc42 I think that makes the window of usefulness quite narrow.
It seems that stall detection with R3 crashes if it happens in tfree.g, it looks paused, but no button does anything (homing, resuming, cancel print).
-
The kinematic coupling is different, as is the cam lock... but the X/Y moves to free, pick up, etc. are the same as a Jubilee.
@nraynaud said in backing out from the endstop:
some steps might be skipped during those operations, either hitting the dock or pulling on the springs
-
Hitting the dock? When I was commissioning the Jubilee, I hit the dock a lot, and therefore un-set Y home. It was very frustrating. However, hitting the dock absolutely stops happening once you get the printer set up correctly.
-
Skipping steps pulling on the spring? Then the spring needs to be weaker or the motor stronger.
Having a condition where a printer skips steps, and then attempting to compensate for that, represents a fundamental flaw in an open loop design. I realize that is a very direct statement, and it is not meant to be negative. It is, however, meant to push the idea very hard. Either get the operation of the printer to where steps are never skipped, or go to servos.
-
-
@Danal I am trying to close the loop, that's what all my questions about reacting to switches and conditions and stall detection are.
I am trying to be progressive in closing the loop, because it's the fastest way to drain money and bringing noise into a system. So for now I'm trying to react to slow filterable events.
-
I cobbled something together, I don't know how far it will go:
outdanger.g:M574 Y0 C"nil" M558 K0 P5 C"ystop" F10000 H0 I1 G38.5 Y100 P0 M558 K0 P0 C"nil" M574 Y1 S0 P"!ystop"
it occurred to me that the endstops are useless most of the time anyways since there are no guarded move, I might even plug them to the emergency stop in normal situation and back to endstops during homing.
-
@nraynaud said in backing out from the endstop:
I am trying to close the loop, that's what all my questions about reacting to switches and conditions and stall detection are.
I do (still) think that servos are the real answer... at the same time... I will do everything I can to help.
@nraynaud said in backing out from the endstop:
I might even plug them to the emergency stop in normal situation and back to endstops during homing.
I've had that same thought. Perhaps wire to both, with a relay (or transistor) to break the path to e-stop when homing?
-
my 1000 feet view it to wire them to a M999 script, because the capacitors in the DC power supplies pack a lot of puch and they really don't stop quickly.
-
I have significantly reduced the tool changing forces by using this wonderful and clever invention: grease. I should use it more on my moving parts.
I have had very good positional repetition and no stalling since.
I am posting a picture because I really needed a lucky break on this project. -
Nice!!!
It is a great feeling to get a multi-color print.