Endstop OM request and support analog?

gtj0

@dc42 @chrishamm Can we get sensors.endstops to report a status like "not stopped", "near", "stopped" or something similar, in addition to the "triggered" boolean? Kind of like M119.

Also would it be possible to add analog capability for endstops? If we've got sensors that can provide an analog signal, it would allow us to home X and Y with the same 2 stage velocity that we can with Z.

Didn't dc42 just now say he was wanting to remove the "near" function for probing?

I was thinking in the same lines when I learned that some of the io_n.in had analouge support, but

gtj0

@bearer Now that you mention it, he did mention something like that. I don't get it though. Why remove a potentially helpful feature? Anyway, I hope he doesn't remove it. There's no point to having analog input capability if you can't use it for anything.

Lets hope he meant remove it for probing and move it to ends stops

(a smooth deceleration and slowly creeping to the end stop would be, well, smooth)

chrishamm

I don't think a "near" indicator for endstops is reasonable since this is already implied by the analog value of a Z-probe. Since RRF3 supports multiple Z-probes, it would be more straight-forward to define multiple probes for analog endstops and to use them when needed. You'll know that a Z-probe is near when the value exceeds 0.9 * trigger_threshold. To be fair, I haven't looked into the configuration of multiple Z-probes for homing, though.

In general, general-purpose input ports will report the analog value in a future version (that's why we changed sensors.gpIn[].value from bool to float). It will probably take a while before this is fully implemented, though.

dc42

I have no plans to support analog endstops. In RRF 3.02 all endstops will be interrupt-driven, which will make it even harder to support analog endstops. This is necessary to allow endstops connected to the Duet 3 main board to stop motors on expansion boards. Endstops connected to Duet 3 expansion and tool boards are already interrupt-driven.

analouge value combined with a 2 stage velocity move would suffice, but if the latter is due to be removed its a bit of a moot point

edit: that feeling when your comment gets rendered moot as you type..

I suppose I'd be just as happy to use probe command if we could specify some amount of allowable safe overshoot to facilitate some deceleration on the first pass.

gtj0

@dc42 OK interrupt driven endstops make sense in that context.

I hadn't noticed or tried this but M574 does say

Snnn 1 = switch-type (eg microswitch) endstop input, 2 = Z probe (when used to home an axis other than Z),

I'll play with that and see how it works.