Is there a way to adjust the homing deceleration? When in the homing cycle the limit switches are activated the motors come to a hard stop. This isn't the best, particularly for the y direction where the full weight of the gantry provides sufficient inertia that my table shakes. The only thing I see I can do is lower the homing speed but then the homing cycle takes a lot longer. One solution would be to have some room behind the limit switch so that the axis can decelerate on 2-3 mm, then it backs up and slowly finds the accurate position of the limit switch. But that requires a way to adjust the deceleration.
I would - lower the homing speed - create a parking macro that sends it to 1/4" short of the home switches and use it EVERYTIME before power off. Now, speed doesn't matter because it is always only moving 1/4" (except for crash recovery of course) G20 G90 G53 G0 Z-0.25 G53 G0 X-0.25 Y-0.25
David, your parking suggestion is interesting. However, in my case, since I am storing my machine upright, the parking position in y is about 2/3 away from home because that gets it close to the axis of rotation for the tilt table and works better with the available space in the upright position. But I do have a defined parking position because I move the gantry to a special position for storing it. I thus know exactly how far away from home it is. Is there a way I can tell the machine on startup without first homing where it supposedly is? I could then get it close to home before actually starting the homing cycle.
You could use a G10 L20 command to tell the controller where home is relative to its current position and that would be straight forward. Alex.
Ok, let's see if I have this right. I do park my machine with: G21 G90 G53 G0 X-20 Y-380 Z-35 Next time I use the machine, I could then before homing, after turning on the machine, run this code: G21 G90 G10 L20 P0 X-20 Y-380 Z-35 Assuming that the machine has not moved it should now know where it is. If I wanted to make sure, I could now move close to home and then start as David suggested a homing cycle that due to its proximity to the switches would be slow and gentle. The full script would then look like this: G21 G90 G10 L20 P0 X-20 Y-380 Z-35 G54 G0 X20 Y20 Z20 ;fast to get close to home G0 F200 X5 Y5 Z5 ;slow to get even closer $H
no, you cannot change the MCS, it is set by poweron/reset/$H command, that is all. everything else is an offset and does not affect the MCS 0,0,0 and, if homing is on you may not be able to jog into positive space (it will alarm), maybe with soft limits off? on the other hand, just give it a try, if you always park in the same place, then after power on the distance to travel to 'near home' is always known and a macro can do it for you, ie rapid to near home, then do the homing
just tried various settings. if you have homing enabled soft limits disabled then you can jog (or command) moves to anywhere, including beyond machine 0 if you have soft limits enabled then trying to go beyond 0 will result in an alarm
Just found an even better solution. I realized that when I turn on the machine the x and y coordinates are set to the maximum x and y specified in the GRBL settings minus the homing pull-off distance. Since I know where my machine is parked I can now travel to the home position towards zero without worrying about the soft limits because they would not be triggered since I am traveling towards zero coordinates and thus staying inside the soft limits. However, I am encountering two new problems. 1) Why can't I write something like: G0 X[5+50] Y[5+380] It gives me an error about the expression. 2) $H doesn't work. It says that the command '$' is not allowed or something to that effect. I thought one can use the GRBL $-commands.
1) you can do maths inside Javascript macros: Getting started with Javascript Macros in CONTROL / Library of Macros created by the community - math first then send the command 2) make sure homing is enabled: Grbl v1.1 Configuration · gnea/grbl Wiki - make sure its the only command on that line
Just to be precise, the error reads: "Error 2: Numeric Value not valid." This is what I am running: G54 G21 G90 G0 X[50+15] Y[50+380] G1 F200 X[5+15] Y[5+380] $H Yes, I can do the math, but this way is better for documentation. It makes it clearer what I am doing. Why can't one do expressions in this place?
That is LinuxCNC, not Grbl: Home · gnea/grbl Wiki "The [grbl] G-code interpreter implements a subset of the LinuxCNC standard "
Ok, no expressions then. The movement now works but it doesn't want the homing command. I am getting "Error 8, '$' command, Not idle". This is the code: G54 G21 G90 G0 X65 Y430 G1 F200 X20 Y385 $H Homing is enabled and works fine if executed through Interface button press.
Try a G4 Pxxx where xxx = enough seconds for the machine to come to a rest / sync the buffer before the $H You send some commands, they go into Grbl's buffer. Buffer should be empty before you send $-commands. See Grbl v1.1 Interface · gnea/grbl Wiki to learn more (particularly Grbl v1.1 Interface · gnea/grbl Wiki)
Ok, that did it. G4 P1 was enough to accept the homing command. The dwell does not have to be the duration of the prior movement. One second is enough. For reference, the full code is: G54 G21 G90 G0 X65 Y430 G1 F200 X20 Y385 G4 P1 $H Thanks for your help. G-code is definitely not intuitive. I am developing software for now more than 50 years and had a little bit of G-code exposure due to 3D printing. But G-code for a CNC machine is a bit more layered with more things to consider. Help from the experts here is much appreciated.
