New to Smoothieware, are travel limits supported?


I upgraded my Prusa i3 to Smoothie over the weekend and it’s now up and running nicely with the current Edge firmware.

Coming from Marlin, one major difference I’ve noticed is, even after homing Smoothie will happily move an axis right past an endstop switch if you ask it to. For example, when jogging an axis around in Octoprint it’s easy to accidentally leave the jog distance set to 100mm instead of 10mm or 1mm.

In my case, even after verifying my endstops were configured correctly, M119 showing the correct endstop status, and successfully homing the printer….I incorrectly assumed Smoothieware would know better and with one wrong mouse click my Y carriage tore the micro-switch clean off the endstop PCB…fortunately nothing else was damaged. Had it of been the Z axis the likely result could have had broken glass and bend rods.

Shouldn’t triggering an endstop mean *STOP*?

And once homed, shouldn’t Smoothieware apply limits to how far it will travel? As configured, Smoothie knows min is 0 and max is 200, and since I homed the printer it knew where the axis were currently positioned, shouldn’t the firmware know better?

Enabling the limit switch options kind-of helps, assuming switches are positioned at both ends of all three axis. Unfortunately Prusa’s are typically only equipped with endstops at the 0 positions so there would sill be nothing to prevent someone from accidentally jogging an axis too far. Not to mention the difficulty of setting the Z height because enabling the limit switch option requires home retracts.

So I’m curious…am I going about my endstop configuration all wrong? Does Smoothieware support configurable travel limits?


Imported from wikidot


We indeed only support “physical” limit switches ( which you’ve successfully used ), but not “soft” limit switches based on a declared work area size.

I’m pretty sure that is the only feature Marlin has that Smoothie doesn’t at this point :slight_smile: The thing is : it’s easy to implement, but hard to implement well. And we try to only implement things right in Smoothie.

This, combined with the fact that very few people actually want to use the feature, leads us to it not being implemented yet.


I ran into this as well today. One wrong click and the x carraige crushed my build plate (glass) and also bent the bed support screws…

I really would have expected such an advanced firmware to have basic safety features like this.

Because Smoothie is so advanced, this means this feature is much more complex to add than in other simpler/dirtier firmwares.
This goes over some of the challenges :

First, sorry for the unnecessarily goading tone of my last post. That was uncalled for.

Being a software developer myself I can certainly appreciate the complexities of this feature.

Would it make sense to add a warning to the documentation that soft limits are not yet supported and users have to be careful when manually jogging the axes?

Where do you think would be the most adequate place to put such a warning ?

This issue is what I came to the forum to ask as well, then I found this topic.

I think this should be mentioned on the motion page, on the endstop page, and with a comment in the configuration file.

The ability to move past soft endstops is not something that many users will expect (especially if coming from other firmwares like Marlin) so by not having soft endstops there is a high risk that a user will assume soft endstops exist and will damage their device.

When risking damage to the machine, you want to have warnings about it in as many places as possible.

I’ve read your Google document above about implementation challenges, and to be honest I think just one config option soft_endstops true/false would suffice for now, where the true option behaves like the ignore suggestion.

You’re obviously a person with strong ideas about how something “should” be done and I totally get that, I am the same with many aspects of my life too. However I’d also say don’t let “perfect” get in the way of “good enough”.

The ability to not crash motion into the frame would be “good enough” for most people until the feature can be implemented as fully as you’d like. For those who are not satisfied and need more control, either wait for the full feature or contribute the code.

That’s great that that default would be good for you, but I know by experience ( I get asked for/talk about this feature a lot ) that a very large number of users would be upset at that default, and would think their default is the right one ( that most users would be ok with ) and yours is the wrong one.

Also, Smoothie doesn’t do “good enough”. If we did, we’d end up like Marlin, with unreadable and unmodifiable code.
If Smoothie, 5 years after it’s creation, has the most features around, but still has stellar code quality ( where other firmwares instead have crappy code and can’t add features because of it ), it’s because we don’t do “good enough”.

We plan ahead for what the feature will need to be, and we do it as well as we can from the start. It makes the code better, and it requires less work from the contributors in the end.

Jim just added a first try at an implementation of soft endstops into the code, so the feature should be added officially fairly quickly. I still need to document it.

Fair enough.

In the meantime I’ve noticed alpha_limit_enable and friends, which at least covers this for not moving in the negative direction past endstops.