This is a general question NOT related to some issue so no klippy or anything.
I was looking for another way to stop the printer dead in its tracks, but not with the “emergency button”.
Reason being is that the emergency stop kills all the processes while a “soft stop” does not.
In machine logic you always have the two different stops. The emergency stop is for critical dangerous situations and kills power to all systems which results in a dead stop BUT you cannot simply move the machine again without going through the reset sequence.
The soft stop stops the machine dead as well, but with a minor difference that it does not power down all systems so you can move the machine again without going through the whole reset sequence.
In klipper I do not see the soft stop feature in reality, since the “STOP” button in the status window of klipper continues always to the end of its current command. If this is a macro of some length you have to wait.
My question is if anybody knows of a way to cut the process regardless and leaves the machine is a workable state without continuing its processes.
I know you will loose the print but that is not relevant here, I simply want a quick stop instead of the emergency stop.
In practical sense I would use this if I have just started a new print and right when I clicked the start button I realise it is the wrong print. In this instance you have to choose to wait till the end of the STAR_PRINT macro, which takes time due to bed heater, quad level and bed mesh, or you emergency stop the machine, which means you have to reboot it all.
If this is not possible I will have to live with it but I cannot find any info on this in the documentation nor in past posts.
Thanks a ton.
Currently, there is no such possibility.
As it stands, most of Klipper’s processes are synchronous in nature to secure the timing requirements and the only completely asynchronous command that bypasses all buffers / queue etc is M112
Aha, I did not take into account the clock with regards to a soft stop.
Correct me if I am wrong, if you created a soft stop which jumped out of the current gcode and simply went back to a safe position without switching off the steppers, which would mean the machine remains calibrated, one would not need to keep the clock speeds synchronous. Or is this statement wrong?
It looks like these threads on github are left to die a certain death. While the stuff discussed there is really of some merit with regards to the instant abort rather then cancel, it seems either too complicated or not deemed of enough value to continue with this development.
I just got a github bot warning me that these pull requests are becoming inactive due to no volunteers to review them (or something of that nature).
I am of absolutely no use there due to lack of knowledge, but I would love this to be developed. What can I do to show my interest in this and for those who know these things to continue?
Essentially there is one lead-developer and unfortunately and very inconveniently he apparently has a life besides Klipper. Something I cannot endorse in any way, but it is like it is.
Joking aside:
Apart from likely being quite complex to change from synchronous to asynchronous execution, these PRs are from @koconnor himself, so there is a certain likelihood that they eventually get merged as long as no negative side-effects pop up and his time permits.
Hahaha, I can fully agree with you on the “unfortunate” bit of having a life besides your hobby, I feel like that every monday to friday. I have followed the klipper stuff for a while and know that @koconnor is a busy person and despite having a life besides these things, actually accomplished something almost non-human already with klipper. I am certainly not complaining about his efforts or speed of progress. My message is probably the result of still feeling like a visiting alien whenever I go and see things on github, I totally do not understand how that works and when the bot sent me that message I thought it was not getting attention anymore.
Focus more on patience I shall.