Slow down before endstop?

[theKM]

Is there any way to connect a sensor that's near the endstops so that it can tell the machine to slow way down before touching the endstop?...

Issue is, machine is large and heavy. Telling it to stop on a dime when hitting a switch 3d-printer-style makes a god-awful crunch. And it's of a size, that telling it to go super slow would take forever to traverse the machine.

So electronically it would be super nice to have a "you're close, slow down" switch/sensor, but I understand that that would require a different kind of interrupt in the controller that would allow it to continue doing what it's doing but just decelerate for the impending endstop switch.

I've done a bunch of searching, but only end up with usual endstop switch setup.

It's not super critical (I can keep using it with the endstops just as emergency measures), but it would make the machine more productive if it can sort out its total workspace when turning it on, regardless of where it was stopped last.

[fcwilt]

@thekm

Have you considered using IR beam break sensors? Something like below:

Since the sensor can be mounted so that moving part the breaks the beam can pass through (and even beyond) the slot you can position them to allow stopping motion with no risk of impact or damage.

I use them on most of my printers.

Frederick

[chimaeragh]

@thekm I'm interested in seeing if there's a solution to this as well. I have a screw driven Workbee 1510 and homing at the default feedrate of 2400 is painful to watch. However increasing this value to a more tolerable rate, e.g. at least 4000, means the limit switch is subjected to more force which can reduce lifespan of the endstop.
Maybe induction sensors could solve this problem

[fcwilt]

@chimaeragh

Yes induction sensors would work but IR sensors like I mentioned work just fine as well.

I even had a setup with two such sensors. The first was approached at a very high speed. Then it continued on to the second at a safer speed.

Frederick

[jens55]

@thekm, is the 'crunch' generated by the motor trying to stop or is it generated by the carriage hitting the switch? If the latter I would try and set up a mounting for the switch that is spring loaded and can give.
The standard procedure for finding the end stop is to use a fast traverse to locate the switch, back off the switch and then approach the switch at a very slow speed for accuracy. Only the slower pass is used to determine switch position. If the printer can't stop in time and the stop is mounted in a flexible way it will give but since that event is not used for the final position, it doesn't matter as long as the switch returns to it's proper position for the second pass.

Doing a second switch shouldn't be a problem either but I have never contemplated how to do it.

[chimaeragh]

@fcwilt With CNC machining, being the messy process it is, isn't there a possibility of this sensor being triggered by waste material falling on it and breaking the beam?

[theKM]

In thinking about this from a gcode point of view, is there a way to describe a an ideal deceleration?

In pseudo-code...

• travel fast until switch A
• change from fast to slow over 100mm
• travel slow until switch B

...the first line is already what happens, just that the next line is "abort" or "set machine position as___"

Reading the gcode docco, that sounds it might just be the existing feedrate codes as long as there's a following traversal command for it to continue with... but would the board think that the machine is still at speed or assume it's starting the next command from 0?

[theKM]

@fcwilt nice sensor!... electronically it seems pretty straight forward, even using a microswitch that can slide would work fine... I'm as much needing the knowledge that there's inputs on the board to take the switch, and the g-code resembles to get it to work

[theKM]

@jens55 ...the crunch is getting the machine to stop on a dime, it needs the interpolation of acceleration to do anything elegantly. When I was first setting it up, the default acceleration for printers is super fast, it was rather horrible watching it move

[jens55]

Another method that is often used with CNC mills is to allow the switch to be bypassed. Instead of the carriage directly activating the end switch, the switch is mounted to the side and a lever is used to activate it. The carriage approaches the lever and depresses it which activates the end stop switch but there is no hard stop so if it takes a mm for the carriage to stop, nothing is harmed.
You could use a micro switch with a lever with a roller on the end and have a protrusion on the carriage that activates the lever without running into a stop.
Hard to explain but very simple and effective.

[theKM]

@chimaeragh ...the "you're close" switch I imagine would be ignored unless explicitly told to watch for it when homing, otherwise the machine would just calculate if it's in bounds and do its thing, and stop with the e-stops if something went horribly wrong (jammed, lost steps, blah blah).

I'm also thinking that a swiping/roller style micro switch would work fine and wouldn't be triggered by waste material.

[fcwilt]

@chimaeragh said in Slow down before endstop?:

@fcwilt With CNC machining, being the messy process it is, isn't there a possibility of this sensor being triggered by waste material falling on it and breaking the beam?

Sorry, I missed the fact that this was posted in the CNC section.

You could likely arrange the sensor so swarf wouldn't block it but during homing operations you wouldn't be creating any would you?

And the activation of the sensor is only meaningfull during a homing operation, any other activations are simply ignored.

Frederick

[theKM]

@fcwilt ...sounds perfect, what's the g-code and inputs look like for that?... is it just like the usual "travel until switch" gcode, and then the next line is a new feedrate?

[theKM]

@jens55 ...the arm sliding/roller was what I was thinking, but just curious about the hookups and g-code, is it just having the new feedrate on the next line with some distance to travel after that?

(I guess line after is the new feedrate, then after that the usual "travel until endstop")

[jens55]

@thekm, this is one of my homex.g codes:

G91               ; relative positioning
G1 Z5 F6000 H2    ; lift Z relative to current position
G1 H1 X-550 F6000 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000       ; go back a few mm
G1 H1 X-550 F360  ; move slowly to X axis endstop once more (second pass)
G1 Z-5 F6000 H2   ; lower Z again
G90               ; absolute positioning

This is on a 500 mm x axis hence the '550'

[chimaeragh]

@thekm May need to use conditional gcode in this one

[fcwilt]

@thekm said in Slow down before endstop?:

@...the arm sliding/roller was what I was thinking, but just curious about the hookups and g-code, is it just having the new feedrate on the next line with some distance to travel after that?

(I guess line after is the new feedrate, then after that the usual "travel until endstop")

If you can arrange things so that the sensor is triggered a suitable distance before the end of travel and remain triggered until the end of travel I believe you would be fine with one sensor, be it a micro-switch equipped with a roller, an IR sensor, an inductive sensor, etc.

The important thing being is that the sensor cannot be struck by the moving part.

For example on one of my printers that uses the IR sensors the axis is 300mm long and the sensor triggers at 280 and remains so until 300.

So even at a high speed there is plenty of time for it to stop. Then I back off a bit and do it again at a slow speed to improve accuracy.

Frederick

[theKM]

@fcwilt the backup-and-go-again is an accuracy thing. In my case, it's the stopping at speed that is the problem. it really needs to decelerate to go slow before being told to stop.

[fcwilt]

@thekm said in Slow down before endstop?:

@fcwilt the backup-and-go-again is an accuracy thing. In my case, it's the stopping at speed that is the problem. it really needs to decelerate to go slow before being told to stop.

Well if you can say with certainty how long it takes to stop then you can position the one sensor at an appropriate location.

The important thing is that the sensor remain triggered from that position until the end of travel.

Normal moves have controlled acceleration/deceleration. I don't know what controls deceleration when an endstop is triggered - I would need to do some research.

Frederick

[theKM]

@fcwilt ...I get what you're saying, it stops wherever it stops, then re-measure it. But again, it is the stopping that is the problem. When it stops, it a hard stop. It's asking a very heavy machine to stop instantly, and the inertia is putting a lot of unnecessary strain on the ballscrews, the crunch is terrible. Nobody mechanically minded would think that the crunch is the sound of a properly operating machine during regular operation

...so I'm after a way for the controller to apply the max deceleration value and slow it down nicely ahead of the stop.