1

Topic: Why software endstops are not enabled by default?

Hi guys,
I think that everybody made a mistake at least once with the manual controls or invalid gcode files and brought the axis past their limits. Fortunately Solidoodle is rather...solid, but the chance you break something exists...

I wandered around Marlin firmware and found two interesting flags in the configuration.h:
#define min_software_endstops true
#define max_software_endstops true

I set them to true and saw that, while homing and printing operations are running smoothly, if you accidentally send a manual movement command that is exceeding axis limits it will just stop when they reached the predetermined limits.

I think it's extremely useful and should ship the printer with the flags true by default.

Any thoughts?

2

Re: Why software endstops are not enabled by default?

Because solidoodle I guess decided they would prefer people to be able to 'move' the axi' manually in RH without homing first, and to allow compensation for 'missed steps'... With them enabled, most times the printer wont move until you hit Home first - which whilst is a better choice given that action (always hit home first) should be force of habit anyway but I can appreciate it will cause support concerns/issues as people, even if they had it there in some form of documentation, would still panic when the printer doesn't move because they didn't know to hit home first.

As shipped - people can click arrows in RH and it will 'move', and then when they hit print it will be 'all good' because it homes as one of the very first actions.

3

Re: Why software endstops are not enabled by default?

Interesting theory Adrian, this might be true...
But this condition could be easily remedied, the firmware could home as soon as the printer has been powered up, therefore until the next power cut the head will always move until the software endstop, assuming that you don't move it with your hands.
These safety checks would improve reliability perception among inexperienced users, like the cold extrusion prevention.
Then a power user like most of us can quickly disable these safety checks if needed by reflashing the firmware.

4 (edited by 2n2r5 2013-12-14 15:17:55)

Re: Why software endstops are not enabled by default?

agentsmith wrote:

Interesting theory Adrian, this might be true...
But this condition could be easily remedied, the firmware could home as soon as the printer has been powered up, therefore until the next power cut the head will always move until the software endstop, assuming that you don't move it with your hands.
These safety checks would improve reliability perception among inexperienced users, like the cold extrusion prevention.
Then a power user like most of us can quickly disable these safety checks if needed by reflashing the firmware.


I don't think having unexpected movement is ever a good idea. It sounds actually like a good way to break something. If someone has rested something on the platform, has their hands in the wrong spot or just hasn't removed some of the packing restraints, I could see this turning into a disaster before someone even gets to print for the first time. These things don't have a power button so when the power comes on, the user isn't actually looking at the printer when it happens.

SD3 w/ mods:
Glass bed with QU-BD heat pad upgrade, threadless ballscrew w/ 8mm smooth rod, spectra line belt replacement, lawsy MK5 extruder, Lawsy replacement carriage, E3D hotend, Ramps 1.4 w/ reprap discount controller, DRV8825 drivers, 12v 30A PS, Acrylic case, Overkill Y-idlers, Filament alarm, Extruder fan + more.

5

Re: Why software endstops are not enabled by default?

A partial solution that doesn't involve motion at startup would be to enhance the firmware to enable software endstops only after the axis is homed the first time (though maybe it already works that way - I haven't looked at it).