Homing within a part

Discussion about the arduino based g-code interpreter, grbl
Post Reply
glendresser
Posts: 38
Joined: Sat Sep 08, 2012 5:45 am

Homing within a part

Post by glendresser » Sun Jan 12, 2014 2:46 am

Is there a way to get the system to home itself midway through a job within g-code?

For example, what I'm trying to set up a job using nesting in cambam. My intent is that at the end (or beginning) of each iteration, it homes itself, returns to the correct workspace and location, then continues the next piece in the loop.

The way this makes sense to me is to create an MOP footer in cambam defined as "$H, G55, G0 x0y0, G0 z0". But the $H commands generate a 'error: busy or queued' statement. The problem doesn't seem to be using tokens inside gcode, since if I just embed a '$$' token, this returns a list of grbl settings, as you would expect. I imagine that what's happening here is that it just skips the homing routine if there are incomplete commands in the queue ahead of it. I thought I might be able to use "!" to do a feed hold, "$H" to home, and then "~" to continue the job. But homing routines don't seem to execute while it's in a feed hold state.

Is there a way I can make the machine pause before the "$h" token, make sure that all commands are cleared, and then continue? Or some other workaround?


EDIT:
okay, ten minutes after posting I figured out a hack that gets the desired results. Here's my MOP footers:

Code: Select all

G0
G0
G0
G0
G0
G0
G0
G0
G0
G0
$H
G55
G0 x0y0
G0 z0
So what's happening here, I think, is that the G0 lines generate errors (invalid statements), but in doing so, give the system enough time to clear any previous legit G-code. By the time it hits the $H command, there's nothing cached, and so it runs right away.

However, this is an ugly, ugly way of getting the desired results. Anybody have the proper way of doing it?

twforeman
Posts: 1347
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: Homing within a part

Post by twforeman » Sun Jan 12, 2014 10:28 pm

I'm totally confused as to why you would want to re-home the machine in the middle of a job.

The only reason I re-home my machine is if it crashes, or hits a limit switch (or get's an EMI tripped limit switch, which still happens once in a while,) or if I've powered it down.

Re-homing will only reset the machine zero to where it should already be currently set. Can you explain more fully why you need to re-home the machine?

Once it know where machine zero is, it shouldn't need to be reminded. Unless you are using G93 to reset the zero, which you should not be doing if you have home/limit switches.

You should be homing the machine at the start of your work session and then creating work coordinates with the G10 Px L2 command. Then you reference them with the G54-G59 commands. These are also stored in the eeprom, so if you power off you can just re-home and then say G54 and your zero is ready to go. This is super useful as it allows you to have 6 stored sets of work coordinates.
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

glendresser
Posts: 38
Joined: Sat Sep 08, 2012 5:45 am

Re: Homing within a part

Post by glendresser » Mon Jan 13, 2014 5:12 am

Because occasionally my machine will miss steps, and while these missed steps might not be noticeable in a single part, it will become noticeable if there are multiple missed steps over the course of a complex job. By homing after each part, I know that these missed steps are never going to escalate over the course of a big job. Particularly, if it's a job that requires tool changes, if I do all my cuts with one bit, and I'm not aware that there was a missed step in the first part, then when I switch to another bit (which requires homing anyway), all my new cuts are going to be misaligned from the original set.

twforeman
Posts: 1347
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: Homing within a part

Post by twforeman » Mon Jan 13, 2014 2:05 pm

Ah, that makes a little more sense. If it were me, I'd work on fixing the source of the missed steps. I run pretty long jobs with multiple parts and don't have any missed step issues.

As for tool changes I set GRBL to leave the steppers powered all the time so the axis are locked. I don't usually manage to move the carriage when I change the tool and then I only have to reset the zero for the Z axis.
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

Downrazor11
Posts: 3
Joined: Wed Feb 08, 2017 4:48 pm

Re: Homing within a part

Post by Downrazor11 » Thu Jun 08, 2017 5:54 pm

glendresser wrote:Is there a way to get the system to home itself midway through a job within g-code?

For example, what I'm trying to set up a job using nesting in cambam. My intent is that at the end (or beginning) of each iteration, it homes itself, returns to the correct workspace and location, then continues the next piece in the loop.

The way this makes sense to me is to create an MOP footer in cambam defined as "$H, G55, G0 x0y0, G0 z0". But the $H commands generate a 'error: busy or queued' statement. The problem doesn't seem to be using tokens inside gcode, since if I just embed a '$$' token, this returns a list of grbl settings, as you would expect. I imagine that what's happening here is that it just skips the homing routine if there are incomplete commands in the queue ahead of it. I thought I might be able to use "!" to do a feed hold, "$H" to home, and then "~" to continue the job. But homing routines don't seem to execute while it's in a feed hold state.

Is there a way I can make the machine pause before the "$h" token, make sure that all commands are cleared, and then continue? Or some other workaround?


EDIT:
okay, ten minutes after posting I figured out a hack that gets the desired results. Here's my MOP footers:

Code: Select all

G0
G0
G0
G0
G0
G0
G0
G0
G0
G0
$H
G55
G0 x0y0
G0 z0
So what's happening here, I think, is that the G0 lines generate errors (invalid statements), but in doing so, give the system enough time to clear any previous legit G-code. By the time it hits the $H command, there's nothing cached, and so it runs right away.

However, this is an ugly, ugly way of getting the desired results. Anybody have the proper way of doing it?
I know this is an ancient thread but I really want to know if this worked for you @glendresser?

I am hoping to avoid a similar issue doing multiple steps with lots of travel as a single job (more than an hour long), it would be nice to ensure that the zero points don't drift too far (if at all). The (axial and radial) tolerance of the parts being cut needs to be less than 0.05mm, I can get 0.02mm by running each segment of the entire cut but that means every 7 min or so I need to load the new gcode file and I always re-home then, it would be nice to leave the machine for a half-hour or so.

Dan_the_Chemist
Posts: 76
Joined: Thu Nov 10, 2016 2:52 am

Re: Homing within a part

Post by Dan_the_Chemist » Fri Jun 09, 2017 9:56 pm

Downrazor11 wrote: it would be nice to leave the machine for a half-hour or so.
I tend to stay close to my CNC machines when they are busy. Not necessarily hovering, but in the same room.

https://www.youtube.com/watch?v=6dg467-fPEQ

hatallica
Posts: 60
Joined: Fri Oct 30, 2015 10:31 am
Location: Western PA, USA

Re: Homing within a part

Post by hatallica » Sun Jun 11, 2017 3:05 am

Classic video ... I love it.

I cringed a bit when I read the part about leaving for a half hour. Hopefully, some type of nanny cam is being used in such cases.
Shapeoko3 #1153

Downrazor11
Posts: 3
Joined: Wed Feb 08, 2017 4:48 pm

Re: Homing within a part

Post by Downrazor11 » Sun Jun 11, 2017 5:08 am

Let me clarify, my design computer is 15 feet away from my running machine (in the same room and in sight if I turn around) so it would be nice to be able to do design work on my design computer while my running machine cuts for a half-hour straight, I can see and hear the running machine while it does so. That is not to say it is the safest thing in the world, but that is an acceptable situation for me.

As it is I have to change the file every 5-10 minutes because I am worried longer programs would allow the axes to drift (I have already noticed 0.05-0.10mm drift it in my z-axis after longer jobs), so I would still like to know if it is possible to run an effective re-homing in the middle of a job. Is this possible?

twforeman
Posts: 1347
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: Homing within a part

Post by twforeman » Mon Jun 19, 2017 3:47 pm

I would be more focussed on fixing the Z axis drift instead of re-homing.

Why is the axis drifting?

Is it losing steps? Maybe the stepper motor is overheating. Or your Z carriage is binding. Or your stepper motor is under-sized. Or you are plunging too fast. Or your stepper motor is bad.

Is it skipping teeth on the belt? Make sure the belt is tight.

Is the pulley slipping? Check the set screws. Is there a flat on the stepper motor shaft? If not, add one. Loctite might be needed.

Is the tool slipping in the collet? Are you using a stock collet? They can slip if you are not careful. Is the shaft on your bit under sized?

There should be no reason for the Z axis to drift during a run. Or for any other axis to drift for that matter.
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

Post Reply