Slow down before endstop?

[theKM]

@kb58 ...simply to be able to home it from anywhere after turning it on, it wont know how near or far it the stop is.

But I think I'll just have to start a procedure of parking it somewhere known, by running a script, before turning it off... that way when it wakes up the homing distances will be generally known and it can rapid until it's close, then go slow to the endstop.

[Yveske]

@theKM Can't you just jog it close to home before starting a slowed down homing procedure ?

[kb58]

I just realized the flaw in my suggestion: If it's got enough momentum and bulk, it'll still coast to a stop even when the steppers are trying to stop it after hitting the switch, losing its known position.

This seems to make a case for stepper "servos" with positional feedback, or go for the full Monty and move to true servos.

[theKM]

@yveske ...ultimately, yes, but this is all about automation and having things sort themselves out automatically

I'm going to create a script I can run to park it in a known place before turning it off, so that when it's turned back on it can go from there.

[theKM]

@kb58 it's not about its position being accurate, but that when you turn off the steppers the immediate stop is a horrible crunch... I'm just trying to avoid the crunch.

[kb58]

@thekm Understood, but it does argue for position feedback, so that speed can be slowed down smoothly and still end up where you want it.

[cjm]

@thekm My understanding is that the current end stop approach used by Duet/RepRap firmware is required because all stepper moves are planned and then buffered so to interrupt a planned move when an end stop (or an emergency stop) is triggered requires the planner/buffer to be overridden which is an “internal” firmware controlled action.

I guess this could be avoided if a machine had absolute position encoders, but in this case you wouldn’t really need end stops as the machine would know where it was anyway.

So for stepper controlled machines (where motion control is always relative rather than absolute) then a “proper” solution will require a firmware update (as suggested by @fcwilt above) to apply a pre-defined maximum deceleration when an end stop is triggered (and maybe a different, higher deceleration for an emergency stop?).

Whilst adding a bit of complexity, as Duet applications reach ever larger machines this functionality is likely to become increasingly important so I’d certainly vote for adding it to the Firmware wish list.

[theKM]

@cjm from a code point of view, the controller already has the ability to carry on with the gcode... sure, it may have steps in a buffer to flush, but there's already that next step. it's mostly a question of how fast can it start executing that next step.

That said, it would already have the deceleration steps and timings in the buffer, the interrupt would be mostly about skipping N places in the buffer for it to slow down gracefully without much exception handling...

...would be my guess as a software dev, but it's just a guess

[cjm]

@thekm I’m sure you’re right that implementing a buffer flush/defined deceleration down to stop after a trigger event is eminently doable from a firmware code point of view.

I was thinking also about helping the Duet team see the need for this (i.e. putting it on firmware wish list) and adding a vote to support its introduction, in comparison with the many other priorities they must have.

[fcwilt]

Given that we already have G1 parameters H1, H3 and H4 which terminate the move it might be simplest to have a new parameter, say H5, which would behave like H4 but would respect the M201 setting for that axis.

That would seem to be a simple update requiring no additional parameters. It could involve using M201 to set a temporary deceleration value if desired and then reset it.

The next step would be to add a additional parameter to G1 for use with H5 which would specify the deceleration to use and eliminating the need to use M201.

I'm sure @dc42 could tell us how much work those two approaches would be.

Frederick

[theKM]

@fcwilt ...yup, your spiel about "H5" is my thought exactly. We could then find out how long the stop takes from jogging speed, place the switches and then figure out the gcode that would follow after it.

[theKM]

@fcwilt ... created a thing in the wishlist

https://forum.duet3d.com/topic/24900/g1-option-to-apply-max-deceleration-to-stop

[sinned6915]

@thekm said in Slow down before endstop?:

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?..

Y'all need to take a step back a minute and stop making everything so complicated.....

@theKM are you using RRF3 by chance?

Z_Probe in Mode 1 already does this. Its made use of with the mini IR-Probe. When the probe's raw analoge data hits the 500/1000 threshold, the machine slows down just like the OP is wanting.

Since you can define multiple probes, and can define probed as endstops, I think the heavy lifting is already done. We just need to confirm we can confgure the other probes similarly with Mode 1.

https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_M558

I think then that you would have to use a device that will generate the analog signal like the IR_probe, or use IR_Probes for endstops. I can imagine a rheostat wiper as part of a voltage divider circuit behaving simlarly.

@theKM i gotta ask, if you are driving that much weight, are stepper motors really the best way to go for your motion system? you might be better off with a closed loop system and controller that can tell abs and rel positions at all times.

[fcwilt]

@sinned6915

What you say is/may be true but that could/would make things more complicated.

What is being suggested regards H5 allows using a typical endstop sensor for both purposes, a fast approach to the location of the endstop without an abrupt stop and then normal endstop move.

I personally would rather not have to install two additional axis probes.

Frederick

[theKM]

@sinned6915

Y'all need to take a step back a minute and stop making everything so complicated.....

...I enjoy being told to stop making it so complicated, and then being given an explanation that's much more complicated than what I'm after ...which is pretty simple; can G1 be given an option to decelerate to zero rather than a hard stop. This can operate with basic switches. How can it get simpler than that?

To answer your question, "are stepper motors really the best way to go for your motion system?"... likely not, but I'll happily accept your donation of a closed loop upgrade. It's the machine I have, it works... but like literally everyone on this forum, just tinkering with it to find ways to make it more productive incrementally. Being able to home it efficiently from anywhere would be handy.

[fcwilt]

@thekm said in Slow down before endstop?:

...closed loop upgrade.

I have a number of closed loop systems that I have tested but none of them provide information about what the current position is.

With the current RRF firmware they are treated like an open loop system.

I don't know if the RRF firmware has/or will have any provision for dealing with a system that can provide position information.

Frederick

[sinned6915]

@thekm the probe and type already have the functionality that you want built into it.

how is using what you already have to use of more complicated than a NEW G1 parameter?

[cjm]

@sinned6915 The suggestion of using a mode 1 Z-probe certainly sounds an interesting solution.

However, are we absolutely certain that it does give a controlled deceleration, rather than just forcing a stop like all the other Z-probe options?

I ask because this appears to be an undocumented feature, although I might well have misread the Duet dictionary!

[theKM]

@sinned6915 ...so, your less complicated solution is to set up the circuitry of the switches so that it emulates the analog output of an IR probe...

(pregnant pause)

...clearly we have different definitions of what "more complicated" means.

[fcwilt]

@sinned6915 said in Slow down before endstop?:

@thekm the probe and type already have the functionality that you want built into it.

I looked at the docs but I cannot figure out how to connect a given probe to a given axis.

This states a probe is to be used for the X axis:

M574 X2 S2

This configures a switch type probe:

M558 P5 C"io8.in" H300 F300 T300 R0.0 A1 S0.01
G1 P500 X0 Y0 Z0

But what connects the two?

Frederick