Hello, Don't mind me, I'm just a lurker. I disagree with you on a few points below.
Firstly, the end-stops are recommended in any CNC machine (especially one which has no encoder or feedback mechanism). Homing is a great feature of the end-stops, but it is just a bonus. The primary reason to have end-stops is if there is a problem with your machine it could loose track of what position it is in, for example, if one of your stepper drivers overheats and stops sending steps for a short period, or missed steps, etc. In this situation, the machine could crash. The end-stops are the last line of defense against ramming your machine into the sides and potentially breaking the carriage or damaging the motors/couplers. Also, if you have novice users who might load a g-code which doesnt fit in the build area, it will prevent a crash. I also argue that the end-stops (if you only have one switch per axis) should be on the negative axis because a machine is much more likely to loose steps which would cause it to crash into the negative axis when it moves back. You argue that end-stops should not be used because they may cause false positives. I argue that if you are seeing false positives then there is something wrong with your electronics, perhaps you could solve this easily with a smaller pull-up resistor and/or a small filtering capacitor. In the firmware that i have written for my own printer, I only check the end-stops when I am moving in their direction since I only have the negative endstops (maybe after reading my own arguments I should consider installing positive end-stops as well). As for positioning the negative end-stop for homing to exactly zero, might I suggest a micro end-stop adjuster such as the following: http://www.thingiverse.com/thing:11341 I'm not sure exactly which printer you have, but printing out one of these certainly helped in that regard for my printer (Prusa Mendel i2). I can now very finely control the position that the endstop triggers by turning the knob slightly. This way you don't have to move the switch, just adjust the screw that triggers it. Also, hysterisis should not be a problem for homing. The way you get around this is with your homing routine. First you home at a moderate speed, and then once the switch (or hall effect) has been triggered, you back off 1mm and slowly home again. Since you are only ever homing in one direction, the hysteresis should not matter. With a proper end-stop, a crash will not be catastrophic. For example on my machine I could not cause a crash that could break the heat-bed glass since the end-stop would trigger. Even if my z-stop were very poorly aligned, the head would come down and since the bed is suspending on springs with a few mm of play, it should trigger well before any damage is caused. Cheers. Mark Roy On 10/21/2013 6:48 PM, Stefan H.A wrote: > 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/
_______________________________________________ SkullSpace Discuss Mailing List Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss Archive: https://groups.google.com/group/skullspace-discuss-archive/
