Highlight that setSpeedInHz(0), etc. fails. Or allow 0=stopMove()

[drf5n]

Per many of the examples one might expect that

setSpeedInHz(0), setSpeedInTicks(0) setSpeedInMilliHz(0)

...would stop the stepper, but those are invalid values one should check for.

but these all return -1 and do not change the speed:

https://github.com/gin66/FastAccelStepper/blob/c1f89e49f916bb47891bc9cdf209e76fabd3e887/src/FastAccelStepper.cpp#L811-L841

Maybe something like this would be safer:

if(stepper->setSpeedInHz(x) < 0 ) stepper->stopMove();
// or 
if(x > 0) stepper->setSpeedInHz(x); else stepper->stopMove(); 

Wokwi simulation with dual steppers with workaround:

https://wokwi.com/projects/388661915235241985

Alternately, it might be nice to use setSpeedInHz(0) to call stopMove().

[gin66]

Thanks for the proposal and great simulation.

There is still a mental problem from another viewpoint. The setSpeedInxxx() functions are only setters, which do not immediately apply the value.

Setting the speed can be done with the four setSpeed...() calls. The new value will be used only after call of these functions:

move() moveTo() runForward() runBackward() applySpeedAcceleration() moveByAcceleration() Note: no update on stopMove()

This means, the direct action of initiating a stop, would not fit to the idea of being only a setter and could cause another surprise under this different viewpoint.

Moreover the setSpeedInHz/setSpeedInMilliHz may be able to stop the motor, but for setSpeedInTicks/setSpeedInUs do not have an equivalent to zero. So the functions would be not provide consistent results.

Which of the examples imply, that setSpeedInHz(0) or setSpeedInMilliHz(0) would stop the motor ?

[gin66]

stale