Hi, OK, I'm a little confused. I would have thought that putting limit switches on the X-min and Y-min positions would allow me to zero X and Y (as happens on a 3-D printer) where the printer travels negatively on both the X and Y axes till it touches the end-stop switches, backs off a bit and retries at a slower speed to arrive at X0 and Y0 However, David has written: "in other words, hitting a limit switch is a fatal error, like windows 'blue screen of death'" Can someone clear this up for me? Duncan
When you home the machine that has limit switches, the Z-Axis moves to the limit switch, touches it, backs off a little bit, and moves slowly to the limit switch and touches it. Then the X-Axis and Y-Axis do the same thing. I think that David meant to say that if a limit switch is hit while running a job, that's fatal error.
When GRBL does a homing cycle it finds the limit switches just fine and hitting them is not a fatal error 'during the homing cycle'. After that GRBL enters normal operation mode and then, yes, hitting a switch is fatal. Homing is not something you do by jogging to the switch (-: Note that once you enable homing in GRBL it will boot in an 'alarm' state to force you to do a homing cycle, for safety. Note that the industry standard for cutting machines is to home at positive ends of travel though GRBL does support -X and -Y homing please please make sure that Z homes at the positive end, which is UP away from the work. All of the Gcode generators assume that Z home is high and safe for general movement, because that is the standard.
Also note that in GRBL moving to X0 (or Y or Z) WILL hit the switch and cause an alarm. This is why the OpenBuilds Fusion360 post will output safety moves with an offset. G53 G0 Z-10 is the default, which means raise Z to 10mm short of the Z home position. One can reduce this number (depends on the switch used), but never to 0.
Also, remember that in 3D printers you only see one coordinate system. Work (G54). In a CNC you have Machine Coordinates (G53) zeroed by homing, and several Work Coordinate systems (G54-G59.1) which are zeroed by G10 commands, and are Offsets from Machine Position (to maintain coordination after power/reset simply by rehoming) Homing tells the firmware where the Machine is, but you still need to use the Setzero or probing routines to tell it where the Stock you want to machine is (in Work coords, and thus how far offset from Machine Zero) The Grbl FAQ has a nice write up too gnea/grbl
My SainSmart Coreception 3D printer has two motors and two limit switches for Z-Axis which raises and lowers the build platform. Homing the printer causes the Z-Axis motors to raise the build platform until both sides touch the limit switches, causing the build platform to be level. CNC routers with two motors for Y-Axis have one limit switch. After homing the machine, I have to check both sides with a ruler to make sure that the Y-Axis carriages are the same distance from the end of the frame. Why not add two limit switches to Y-Axis on CNC machines?
Hi, From what I gather, this was a limit within GRBL, which has (since v1.1h) been remedied. You will need to check the GRBL docs for details. However, it is my further understanding that if you are using the BlackBox motion system, you're pretty much locked into how it is set up - but I could be off course here. Duncan
It's easier to Build the machine Square from the beginning. If you are going out of square between homings you have something seriously wrong (skipping steps, loose components etc) That said however, you can use two switches (see gnea/grbl ), and we played with it but its just too much of a bother compared to building the gantry square from the start. Also better, don't let the motors strain to pull a badly built frame square! That just doesnt make sense. Maybe on belt driven machines I can see the potential point, but for everything else. Build it right. Square up the gantry before tightenening down everything. Easy as can be. you'd be surprised how much trial and error it takes to make two switches trigger at a perfectly square point. Also false, see the Y2 Step and Dir jumpers: docs:blackbox:jumper-slaveaxis [OpenBuilds Documentation] which also mentions dual axis homing (last picture on the page) What if the Gantry is fine, and your base is skewed like a parallelogram - referencing off the ends may not be accurate, if its not perfectly square (again, adding switches to compensate for a skew frame, even if they are then set the same distance from the ends, still, same problem - hopefully that explains my point on why its better to square the build)
I squared the frame as best as I can and mounted the frame to the table. I have Spark Concepts xPro V3 using GRBL V1.1. Is it possible to set up dual-axis homing on this board? Once in a while, I forget to zero XYZ after homing the machine and one of the gantries crash into the frame before I hit the E-Stop.
Thats why Hard/Soft Limits are for e-stops has a delay in the form of user realizing mistake, panicking for a second or two, trying to remember where the e-stop is. Not good enough... Automate it with limit switches Yes, refer to the A-axis solder-jumpers, but note that according to schematics https://github.com/Spark-Concepts/xPRO/blob/master/Schematics/3V2_CNCxPro_Schematic.pdf?raw=true they are on A4 and A5 (so also have to edit that into the Grbl config)
