Open pmth opened 3 months ago
The reason simply is, that if you execute a homing operation you run until a homing switch is triggered and you do not want to overshoot and run your device / motor / carriage into a physical limit that comes write after the homing / limit switch is triggered. So if you execute other stuff in parallel while you are homing or even change the parameters like speed, acceleration or set a new moving target, it could lead to physical damage of your setup if the limit switch is for whatever reason read out to late or stopping is delayed. So I found it to complicated to factor all those things in and create a non blocking version. It is of course doable but I would suggest if you need something like that, that you build it yourself using some wrapper function which uses a combination of reading the status of the limit switch (directly by reading the io pin where your limit switch is connected to or using an interrupt as a more elegant solution) and the jogging command, until the limit switch is triggered, and then you stop the motor and set the current position to 0.
Appreciate this library, it's very helpful. I use this library to control multiple motors that has potential to take a while before reaching home limit switch. Having blocking call to
moveToHomeInSteps
is a challenge.What's your thoughts on having non-blocking
moveToHomeInSteps
and is there a reason why it was implemented as blocking (I know that simplicity is probably one of the reason). I am working implementing a wrapper for this library to archive this.