Manual stepper - stop on endstop seems to prevent movement

General Discussion
1

Basic Information:

Printer Model: Custom device
MCU / Printerboard: SKR Pico
Host / SBC RPi 4b
klippy.log

klippy(8).log (86.5 KB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

I’m building a custom device based on klipper, as an alternative to a different opensource board. Recently, the project implemented jogging, so my solution needs to do that too to achieve feature parity. I have read around and I know that Klipper doesn’t do realtime movement too well, but the alternative is to scrap the entire project, which isn’t acceptable at this point yet.

I’m trying to interrupt a jog using a drip move, and then triggering an endstop. I’m using klipper virtual pins to simulate the endstop for now. I setup a manual stepper with the virtual pin as the endstop. This seems to work fine:

obraz
obraz955×147 4.85 KB

However, when I try to move it via console with the “stop on” included, the stepper refuses to move at all. I can hear it “buzzing” slightly as if it’s trying to do something? But ultimately, it doesn’t move. When I remove the “stop on” clause, the move happens as normal. It doesn’t matter that the endstop isn’t triggered.

obraz
obraz1209×177 9.9 KB

Alternatively, is there a way I could do the same thing, without using manual steppers? There’s the “home” command, but that only goes towards one direction. I have a printer.cfg for all three axis using carthesian kinematics, but have no idea on how to setup a movement interrupt there, since “hardware” endstops aren’t a thing in klipper. I also tried not using “virtual pins”, tried an output pin instead, but it doesn’t work as an “input” pin at the same time, so the endstop gets ignored. Virtual pin seems to correctly trigger in the “query_endstops” command at least.

Changing “diag pin” to the virtual pin does the same thing. Doesn’t matter whether the jumper is on the board or not, there seems to be no movement.

Edit: I also updated everything through the web interface, klippy log might show an outdated version, but the problem still persists after an update

obraz
obraz1441×461 22.9 KB

2

How are your Python skills?

klippy/extras/force_move.py: enables MANUAL_STEP. It shows the syntax for moving a single stepper and how it updates stepper positions.

Expand on this method to bypass the motion planner and move steppers at will.

Add to the existing module or code a new module?

Can it work?

3

Strictly speaking, to do “real-time” movement, we have to lose the ability to synchronize motors.

So, from the low level, one has to modify the MCU’s stepper commands in a way that will only apply the speed/pauses between steps.
(Basically execute scheduled moves as long as there is a queue).

That is it, if there is no time scheduling for execution on the MCU side, and the MCU only ensures that the time between steps is honored, one can get rid of ~300ms delay from the host completely.

And well, this would be close to the “speed” control.
Where one still can’t cancel the scheduled motion, I guess, it may not be a big deal in such a case.

Where otherwise, one can either propagate commands upward through the stack or, well, simply schedule short movements from the host.

Again, if there is a “real-time” control, there is no real need for all complicated scheduling and synchronization, so small bursts of movements should do the trick.

This is my guesses,
-Timofey

4

I wasn’t clear. Jog mode is only enabled when printer is “ready” not while “printing”. I guess one would need to disable any other functions that could trigger the motion planner.

Essentially just a routine that does a [manual_step] in a loop until the joystick is centered. Am I mistaken in that [manual_step] bypasses the motion planner? If [manual_step] passes through the motion planner… Disregard my post above, and this one as well.

5

Everything to some degree goes through the planner:

So, it still goes to the trapq, then through the itersolver, to the stepq, where it goes through the compression and gets scheduled to the execution.

Where the drip move is just a hack to have short, up to 25ms moves, but they are still scheduled, and all of that, they just have a shorter deadline.
Where they can be stopped by the endstop, and well, any scheduled move past the endstop trigger time is simply discarded.

Where I guess, even initial drip move is delayed by some time from the toolhead, I guess, the same ~250ms or +100ms, depending on which branch you are looking at.

-Timofey

6

For my usecase, it doesn’t have to be incredibly precise, ~100ms delay would be alright, and I saw someone get that with the gamepad on this forum. The problem is that the endstop doesn’t seem to trigger for me, and I don’t know if this is because of me using the virtual pins module, or doing something else wrong.