Hello, I want the zero point to be at the front left corner of my Eleksmaker Mega, which I use with a pen holder instead of the laser for drawing, so that when I home the machine it goes to this point. but I don't understand how to set this point. I have installed limit switches. The board: Eleksmaker Mana SE v. 3.2 Grbl 1.1f Kind regards ProApe
Hello, I was hoping someone could answer my questions here, but the 51 users who have looked at them so far don't seem to know the answer either. Yours sincerely ProApe
well you see, it depends..... I am going to assume you mean home, since we usually say 'zero' for where we are going to run a job, which is set using a probe or the setZero buttons on OpenBuildsCONTROL. 1 - make sure the machine moves in the correct directions when you jog. X+ moves the pen right, Y+ moves the pen away, Z+ moves the pen up 2 - enable homing in the settings and reset the controller 3 - jog to the middle of the machine 3 - press the home button. if anything homes in the wrong direction, make a note of which axis it is, and turn the controller off before anything crashes. 4 - change the bitmask for homing directions (setting $23) grbl/doc/markdown/settings.md at master · gnea/grbl 5 - jog to center, click home, check directions, repeat until everything goes toward the switch you want. 6 - set the axis lengths grbl/doc/markdown/settings.md at master · gnea/grbl so that is knows how big the machine is.
Hello, thank you very much for the very detailed instructions, but - please correct me if I am wrong - the zero point is not where I want it to be, namely at the front left corner. These settings have already been made correctly. Kind regards ProApe
After moving your homing switches to the corner you want to home to you will need to follow point 3 in @David the swarfer's post. To (hopefully) clarify you can put your X and Y homing sensors/switches where you want (Z must ALWAYS home at the top of it's travel), then use the $23 setting to tell your controller which corner you have put your homing switches in. The reason we refer to homing is because, wherever you have put your switches, the homing process sets the MACHINE co-ordinate system ZERO as the back, right, up corner - that's the reference point for everything else but you can have your X and Y switches in any of the four corners. Alex.
Hello, "After moving your homing switches to the corner you want to home to ... " I don't understand that: the limit switches are used to prevent the machine to go farther than the physical boundary. And when it touches a limit switch the machine stops and I have to unlock it. And they are not used for homing, or am i wrong? With my CNC milling machine, which is controlled by LinuxCNC, it's different: the homing consists of the spindle moving on one axis after the other up to the limit switch, touching it, and then moving back a short distance defined in the HAL and thus rearming the limit switch. Is this probably not possible with GRBL? In LinuxCNC the spindle may not go farther than it can, because the GCode is checked for that and a warning is emitted - that one may ignore, what I never did. I manually moved the pen to the front left corner with the mana board off and pressed SetZeroX and SetZeroY. Then I moved it with the arrows elsewhere on X and Y, selected the first option under GotoZero (which is actually the right one to move only on X and Y, the Z axis is not needed in my case as the laser signal is used to raise and lower the pen), and the pen moved to the specified 0 point. However, when I turn off the machine and turn it on again, the 0 point is lost. Is it possible to change this so that the machine knows where the 0 point was set even after switching it off and on again? And what is the difference between the Home All button and GotoZero? Pressing Home All moves the machine a few centimeters forward on the Y axis, and then the machine locks with the message “Homing fail - Cycle failed to clear limit switch when pulling off”. Does limit switch refer to the physical limit switches? They are not touched; the pen holder is far away from them. I'm afraid that I still lack a lot of knowledge to be able to see clearly. Is there by any chance a tutorial video on this problem? Kind regards ProApe
It is exactly the same with GRBL - this is what people are referring to as homing. It uses the same switches (or sensors) for homing and for limit switches. Homing is optional in GRBL, and many people manage without it, as they are happy to set a new work position every time. If you want the machine to 'remember' work X,Y zero positions between sessions, then it is essential to enable homing. After the machine has run through the homing cycle once at power up, it 'knows' where the axes are and can then move to the same X,Y zero as previously. Additionally, if you enable 'soft limits' you get the same warning with GRBL as you would with LInux CNC where an out-of-range move is requested. It's not clear to me whether your machine currently has homing enabled or not - does it need to be 'homed' on power up before it can be unlocked? Perhaps worth taking a backup of your configuration settings and attaching it to a post here so we can take a look.
Read and reread this section carefully until it makes perfect sense. Frequently Asked Questions In essence: position of homing switches irrelevant. Moving the switch from axes max (default) to axis min doesn't change where Machine Zero is. Machine Coordinate Space is Always in the negative quadrant. So 0 is always at Axis Maxima If you home to max, switch trigger point is zero (at axis maxima where switch is) If you home to min, switch trigger point + max travel distance in pos direction = zero (at axis maxima opposite where switch is) But you use Work Coordinates in any quadrant you want. Home literally anywhere you want. Firmware will set machine envelope to negative quadrant with Machine Zeros at Axis Maximums. Then jog to front left and hit SetZero to set Work Coordinates 2-axes (disable Z homing) is covered in that same FAQ, needs a recompile see Frequently Asked Questions (or a more modern controller like https://docs.openbuilds.com/blackbox-x32 where its easy to change homing without a recompile) This should be your STEP 1. All your other plans depend on WORKING homing. Without a Z axis fitted, trying to do 3 axes homing = fail. With a failed homing none of the offsets are restored. Fix this FIRST Home. Setzero. Done its stored Power off, power on, rehome. Done. Old Work Zero is back (same offset from home, rehoming re-established where it is in the real world) Note standard Grbl PWM doesn't work with servos. You need a special build of Grbl (cprezzi/grbl-servo) or a more modern controller like https://docs.openbuilds.com/blackbox-x32 where pwm is configurable straight in CONTROL
It works already! Here attached the GRBL settings, exported with LaserGRBL; I didn't understand how to do it with OpenBuildsCONTROL. I have to study the lot of information that were posted, trying to understand them, not easy to me! So, for not homing Z, one has to alter the config file: Is that the file that is sent to the board when I change something in the settings within the program? And for other changes of settings one has to write them directly to the file opened in an editor?
All that you have written, is it independent of the program used (OpenBuilds CONTROL, LaserGRBL, GRBLPlotter, Lightburn, ...) or does it apply specifically to OpenBuilds CONTROL? The changes that have to be made, according to the linked instructions, to deactivate the homing of the Z-axis, have to be made in the config.h file. Is this the file that is written to the board or is it on the computer? Where?
CONTROL is but a host. Takes the gcode or user jog button and sends it along. Its just a messenger... So no relevance to any of this really LaserGRBL was a thing between 2009 and 2016, ever since then Grbl (with the release of V1.1 in 2016) itself has Laser Mode so I don't see the point of it existing anymore as a firmware. For Servo's we've had cprezzi-grbl-servo since around 2017, and then overtook by grblHAL having built-in servo signal timing tuning (Servo's needs a slower pulse train than the fast-pwm used for spindles/lasers) - Servo specific firmware as servos are not lasers - use at the time with pen CAMs like laserweb's pen tool, OpenBuilds CAM's Pen Plotter toolpaths, etc Lightburn is the best Laser CAM around, and works with stock standard Grbl/grblHAL (no need for the historic, offbrand, weird and confusing forks like lasergrbl and all the other forks from a decade ago, things moved on) - but its for Lasers For a Pen Plotter, use a PEN CAM like DrawingBotV3 – Transform photos into drawings, effortlessly (A pen is not a laser, its not a spindle, its a PEN) It's 2024, use a modern 32 bit controller like a BlackBox Motion Control System X32 running grblHAL with your servo configured as docs:blackbox-x32:connect-rc-servo [OpenBuilds Documentation] and any of the modern pen CAM options (OpenBuilds CAM, DrawBOTv3, etc) - trying to use decade old tools is futile and frustrating and pointless
Either your servo is a little abnormal (accepts PWM instead of PPM) or you aren't running stock Grbl (running a hex compiled with one of the other board maps or other config changes to change prescaler) Do the research to understand GitHub - cprezzi/grbl-servo: Special Grbl version for use with servo instead of spindle or laser. - the readme explains the changes needed in brief (built into that fork) Older reading material: Using Grbl’s Spindle PWM to Control a Servo at Buildlog.Net Blog 20ms Standard: Servo control - Wikipedia. (50Hz is not 1KHz and actually PPM not PWM - good to stick to standards to keep compatibility) How servos actually work Servo Tutorial - How a Servo Works (nice section on the Pulse Position Modulation protocol) and Relevant stock firmware config entries grbl/grbl/cpu_map.h at bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e · gnea/grbl (Default is 1/64 not 1/1024 prescaler, pulses to fast for most standard servos, but nice for Laser diodes (grbl 1.1 introduced Laser mode) - where the slower prescaler would ruin grayscale work with a laser) If standard PWM did the job, there wouldn't be Arduino Libraries to correctly send out the servo control protocol (you'd just analogWrite) GitHub - arduino-libraries/Servo: Servo Library for Arduino - work your way through the source code, and you'll see renmants of all the above info (50hz, 0.5ms-1ms-2ms duty cycles, etc all the old PPM still alive) Nice that it works (for now), but arm yourself with knowledge for when it no longer does (like trying a different servo)
