The z-axis end stop is, by design, supposed to be at the bottom. The reason we moved it to the top is because we couldn't set end stop position accurately enough so that the end stop activated at exactly 0mm. Moving the end stop to the top completely negated this issue. Part of the problem was that the hal effect sensor has a hysteresis so the point at which it activates is different than the point at which it deactivates, this made setting its position very difficult. Now that we are using a micro switch it maybe easier set its position but I still think homing to the top is the better solution and I'll explain why in a moment.
First, however, I would like to talk a little about end stop handling. There has been a lot of discussion on the reprap forum about how the firmware should handle end stops and the consensus is (unless something has changed) that the end stops should only be used while homing and ignored at all other times. The reason for this is noise on the end stop wires could cause a false positive reading of the end stop which would stop and zero the axis associated with that end stop which would ruin the print. There may be one exception where if the axis has not been homed contacting the end stop will cause it to stop but I have not tested this. This is most likely the way that Marlin handles end stops but again I haven't tested it. Given this model of end stop handling you can see that even if the end stop were at the bottom it would not necessarily stop the extruder from crashing into the bed. The main reason to home to the top is that it makes it easier to adjust for changes in bed height (from leveling, changing bed material that has different thickness, etc.). If the end stop is at the top then changing the bed height is a simple matter of changing a value in either the firmware or the slicer. If the end stop is at the bottom the end stop needs to physically be moved to adjust for changes in the bed height. This can be tricky and becomes tedious quite quickly. There is a z-axis offset setting in the slicer that can be used to compensate for small changes in the bed height but that can only be used until the screw on z-axis contacts the body of the micro switch (a few mm at best). In addition the z-axis offset is only used while printing and will not compensate for changes in the bed height while moving the z-axis manually. Also setting the z-axis offset incorrectly could cause the z-axis to crash into the bed and/or end stop. The link below has a more in depth explanation of the benefits of homing z to the top and it is what convinced me that it is a better solution. http://hydraraptor.blogspot.ca/2012/06/only-way-is-up.html Finally, the reason the z-axis keeps crashing into the bed is that the z-axis end stop position is not set correctly in the firmware. When you home the z-axis it moves up until it contacts the end stop and the then sets the z-axis position to some value greater than its actual position, we will say 200mm because that is the default setting. If you then move the z-axis to 0mm it will attempt to move down 200mm to reach zero. This is a problem because our z-axis end stop position is currently set for approximately 177mm. This isn't an issue while printing because I have added a line in the "additional g-code" section of Slic3r that sets the correct value of the z-axis after homing. This additional g-code gets prepended to every g-code file generated. This value does sometimes need to be adjusted to compensate for changes in bed height and should be verified before printing. Currently, if you intend on continuing to manually move the z-axis after homing you MUST issue the command that sets the z-axis position to correct value. Currently the command is: G92 z177 but the value of 177 changes every time the bed height changes so the best thing to do is copy this line from the "additional g-code" section of Slic3r. To prevent crashing the head in the future I suggest we set the z-axis end stop position in the firmware to something much less than the actual position and continue setting the actual position through the "additional g-code" for printing and manually for manual moves the z-axis. This way if someone manually homes z but forgets to set the position the z-axis will stop short instead of crashing into the bed like it does now. There should be a way to to set the z-axis position in the firmware without re-flashing which is the best way to do this but I haven't figured that out yet. On Sun, Oct 20, 2013 at 8:51 PM, Brian Kulyk <[email protected]> wrote: > I think we can change the z-axis end stop to be at the bottom instead of > the top, but it will require firmware changes. We can discuss this on > Tuesday. > > > Brian Kulyk > 204.887.6988 > > > On Sun, Oct 20, 2013 at 3:58 PM, Edwin Amsler <[email protected]> wrote: > >> My guess is that the head needs to go so close that its hard to have a >> safety switch/sensor that didn't give false positives. >> >> It'd be nice to have some sort of proximity sensor though. Maybe get some >> fancy auto-levelling business going. >> >> -- >> Edwin (on the move) >> >> On 2013-10-19, at 2:33 PM, [email protected] wrote: >> >> > I especially don't get why the design doesn't have a sensor at the >> bottom to stop the head before it rams into the table - I wonder why the >> (Mendelbot?) engineers didn't add one in. We could probably make one. >> > >> > >> > -----Original Message----- >> > From: Ian Trump <[email protected]> >> > Sender: [email protected]: Sat, 19 Oct 2013 >> 19:22:47 >> > To: [email protected]<[email protected]> >> > Reply-To: [email protected] >> > Subject: Re: [SkullSpace-Discuss] 3d printer >> > >> > _______________________________________________ >> > SkullSpace Discuss Mailing List >> > Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss >> > Archive: https://groups.google.com/group/skullspace-discuss-archive/ >> > >> > _______________________________________________ >> > SkullSpace Discuss Mailing List >> > Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss >> > Archive: https://groups.google.com/group/skullspace-discuss-archive/ >> _______________________________________________ >> SkullSpace Discuss Mailing List >> Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss >> Archive: https://groups.google.com/group/skullspace-discuss-archive/ >> > > > _______________________________________________ > SkullSpace Discuss Mailing List > Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss > Archive: https://groups.google.com/group/skullspace-discuss-archive/ >
_______________________________________________ SkullSpace Discuss Mailing List Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss Archive: https://groups.google.com/group/skullspace-discuss-archive/
