How hard is it to sand off the glass edge? Like really sharp edges should not even be an option.
As for the end stops, yes they are meant to prevent crashing into different parts if the machine, but it's not like end stops can't fail. This has already happened once, even with an end stop it still crashed the machine. Sometimes things work different in real life then In theory. I agree with Stefs approach, seems easier to implement than to include all new ends stops and have to adjust the firmware for those additions. Cheers!! On Oct 22, 2013, at 3:42 PM, d-_-b <[email protected]> wrote: > I have cut four new beds out of 6mm clear glass. I will bring them in > tonight, and we can store the extras somewhere close to the printer. The > glass edges are sharp. I shouldn't have to say that, but I think I'll go > ahead and cover my ass. The glass is sharp. It will cut you without mercy. > Beware. > > > On Tue, Oct 22, 2013 at 9:45 AM, Mark Roy <[email protected]> wrote: > 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/ > > > > -- > -- > ) thor.robinson; > ) icon/phreshlyspun/ppca/skullspace > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GMU/O/AT/! d- s+:+ a C++++ UL++++ P L+++@ E---- W@ N! o K? w--- > O- M-- V? PS+++ PEY+ PGP+ t+ 5+ X R tv++ DI++ D++ G+ e* h-- r y+ z+ > ------END GEEK CODE BLOCK------ > _______________________________________________ > 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/
