If it's not practical to sand them, maybe they could be covered with something - electrical tape, plastic frame, putty? On Oct 22, 2013 3:58 PM, "Aemilianus Kehler" <[email protected]> wrote:
> 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]> >> <[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 Kulyk204.887.6988 >> >> >> On Sun, Oct 20, 2013 at 3:58 PM, Edwin Amsler <[email protected]> >> <[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]> <[email protected]> >> Sender: [email protected]: Sat, 19 Oct 2013 >> >> 19:22:47 >> >> To: [email protected]<[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/ >
_______________________________________________ SkullSpace Discuss Mailing List Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss Archive: https://groups.google.com/group/skullspace-discuss-archive/
