Jogging after aborted print in Smoothie Web causes erroneous movment

I’ve noticed that from within Smoothie Web if I abort a print and then use the jog controls to lift the Z axis or move X/Y, the first move after the abort can have some pretty weird results.

So for example: After I abort a print, once the printer stops if I lift click the jog control to lift the Z axis this usually results in X moving as well, and a lot faster than Z. Sometimes the X axis will move so quickly it runs right into the X-min end-stop or if it goes the positive direction it slams into the mechanical limit where I don’t have a limit switch connected.

It’s only during the first move after aborting a print. Any moves after that work normally, assuming the erroneous move didn’t hit the limit switch which requires an M999 or reset to recover from.

Has anyone witnessed this before? I’m using Edge from last week but I don’t have the build number on hand at the moment.

Imported from wikidot


Is this on a delta by any chance ?

Nope, it’s an Ord Bot Hadron.


You can find your current version using the version command.

How do you abort exactly ?

As I understand it, abort *tries* to keep track of position ( that code has seen quite a lot of work done on it recently, but still has some stuff to perfect ), but is not guaranteed to at the moment. So you’ll probably want to home after aborting.

Is any of the Z-compensation or levelling methods active ?

Sure, version via Telnet returns:

Build version: edge-00ff2c8, Build date: Dec 18 2015 04:05:27, MCU: LPC1768, System Clock: 100MHz

As far as Z-compensation, or auto leveling…nope. I still do it old-sckool—I adjust the Z-min end-stop set-screw and re-home :slight_smile:

Oops, forgot to elaborate on how I abort.

In Smoothie Web, down at the bottom next to the “Progress” button, there’s an “Abort” button.

If it’s in the middle of a print and I need to abort due to a bed adhesion problem or something, I just hit Abort and it immediately halts the print. But since that leaves the hot nozzle just sitting on the print, I like to quickly jog Z up 10-20mm, then shut off the steppers so I can push the X axis out of the way and pull the bed towards me so I can examine the print, remove the glass, etc.

But when I jog Z up, instead of just moving up, X shoots off in one direction or the other. But only for the first Z movement click. Any subsequent clicks after that act as I’d expect them too.

It’s not a major problem for me, the problem only occurs in Smoothie Web so using the Jog controls in Repetier-Host works fine. But I’m finding myself liking Smoothie Web and getting used to its simplistic approach so I’ve been using it more lately and not bothering with the USB connection.

Figured I’d report the issue in case it turns out to be a bug I wouldn’t want it to go unreported. …which now that I think about it I probably should have submitted it to the Github Issues list. So if you think it might be a bug I can submit it there if you think it would help.


I’m also a little confused about jogging Z. The position shown on the jog screen doesn’t change, but Z can be changed by the current print file, like on a layer changes. So if I start a print and notice a problem with the nozzle touching the print surface and no extrusion taking place, jogging Z should correct this, right? But if a movement causes a retract, z-height changes and I need to jog again. Is this by design, or should jogging set a new offset? What is is best way to level the print surface? Shims under the bed supports? Is there a good way to check if the bed is level? A manual calibration method is fine, I need the right tools to determine what to fix mechanically.



Can you try the very latest edge ? The problem may be solved there.

OK, I tried with the latest Edge and it still does it. I also double checked and the problem applies to jogging from Repetier-Host over USB as well, not just Smoothie Web. But it’s always just the FIRST Z move after clicking Abort…

…I like the new icons on the graphic LCD display though :slight_smile: They must have been updated since the week-old Edge I was running.

I would like to add that I can confirm this to also be a problem when Jogging from the LCD interface as well. Like clockwork: Abort print, try to lift Z axis and another axis jerks in some random direction as well—often quite aggressively.

I am replying to also confirm this issue. From the web interface I noticed it way back if I hit the jog z up quickly after hitting abort my X axis would move. In the past if I waited until the printer truly stopped then hit jog z up everything worked fine. Now if I hit abort, wait until the printer stops and hit z-jog up my X axis will move.

Since I am setting up a new printer this is becoming a slight problem. What I do to minimize the X axis motion is make my first z-jog up a .1 mm move.

Oh I am using a cartesian system with the latest edge firmware. (I like the new icons on the lcd :slight_smile: )


OK I’m glad I’m not the only one! Yeah moving Z .1mm certainly helps limit possible damage. Since the unexpected X or Y movements can be quite aggressive, if I click anything besides .1mm it can violently slam the X or Y axis into the mechanical limits. …another reason software end-stops would be nice (hint hint).


To follow-up on this in case anyone has the same issue and stumbles on this thread, wolfmanjm figured out it what the problem was and re-added a fix that had been removed at some point.

The latest Smoothie Edge cbbd33b has the fix in place and solves this problem. At the moment it has to be built from source but I assume it will end up in whatever the next available binary becomes.

I should also note that I’ve learned it is suggested to always re-home after aborting a print, but in my case I can not because there is a not nozzle sitting on the printout and must lift Z at least a few millimeters before the object and be removed from the bed…

In any case, this fix does the trick for me.

Thanks Arthur for the help too, regards!