0
$\begingroup$

I've designed my own cnc plotter machine. I've programmed by own "paint" program that generates G-Code which is sent from Universal G-Code Sender (UGS) to an Arduino running GRBL.

As far as I'm aware GRBL does not support backlash compensation, therefore I think I will have to add it to my paint program.

Is there a G-Code command that can be used to step the motors without the position of being changed? So when my code is going to change the direction of one of the steppers I want to be able to add in a few extra steps to take up the backlash without UGS updating the position that it thinks the head is at.

I think I may be able to do this with the G92 offset command but it seems like there should be an easier way...

Any help would be greatly appreciated.

$\endgroup$

1 Answer 1

0
$\begingroup$

I don't know anything about G-Code, but would refer you to the concept of Separation of Concerns - Should a paint program really be doing mechanical backlash compensation? More regarding your question - how would the G-code know that position won't change if the motors are stepped?

I know this isn't really an answer, but it kind of is?

  1. Don't prematurely optimize. Backlash isn't an issue until you can prove it's an issue.
  2. If backlash is really an issue then the easiest solution would be to fix it where it originates - mechanically. Get a better gearbox.
  3. Finally, if replacing the gearbox isn't an issue, then it might be possible to change your toolpath to only approach from one direction. Instead of and active left-to-right followed by an active right-to-left, try starting at a home position, move right, then return home with the tool disengaged before moving right again. If you only cut/draw in one direction then you wind up with no backlash effects, as long as you move far enough in the opposite direction that you run out the backlash before the tool engages.
$\endgroup$
5
  • $\begingroup$ Thank you for the answer Chuck. I agree that it doesn't really make sense to have the compensation in the paint program. It would make more sense for it to be in firmware settings of GRBL. There are professional CNC controllers which do have firmware settings for backlash compensation but I think I should be able to fix this without moving to an expensive controller. I know this is a backlash problem as I can control the position of the head manually with UGS. When I jog the head a certain distance in the controller, the head will move that distance predictably, except when I am $\endgroup$
    – vonLuckner
    Apr 6, 2022 at 19:07
  • $\begingroup$ (cont'd) changing directions. In this case I have to add in an extra amount of movement to compensate for the backlash, after which it will move predictably again. Changing the gearbox would involve redesigning a significant amount of the machine, I'd prefer not to do this for what (I think / hope) should be a relatively easy thing to fix in software. I'd also like it to draw continous lines, circles etc so moving back to a home position all the time isn't a great solution. $\endgroup$
    – vonLuckner
    Apr 6, 2022 at 19:08
  • $\begingroup$ Maybe a g-code post-processing step then? Any time you detect a change in direction, add a move of whatever length is required to jog the motors as necessary to take out the backlash. $\endgroup$
    – Chuck
    Apr 6, 2022 at 20:43
  • $\begingroup$ That's what I'm trying to do. Currently all my g-code uses absolute moves. So I tell it go from x1 y2 to x0 y3 to x2 y4 for example. Its easy to see that there would be a change in the x direction. I could add post processing to compensate for this but because the code currently works in absolute terms every coordinate after the direction change would need to be updated. Or I could update all my code to only work in relative movements. (Note I can't just stick in a relative move after the direction change because this relative move is still tracked by UGS / GRBL and all the following absolute $\endgroup$
    – vonLuckner
    Apr 6, 2022 at 22:55
  • $\begingroup$ (cont'd) coordinates would be off.) So what I'm looking for is a g-code command that will allow me to step the motors in a way that wouldn't change where UGS / GRBL thinks that the head is. If this doesn't exist / isn't possible then I guess I'm stuck with changing all my code to use relative moves or adding a post processing step that updates all of the coordinates after every change in direction. Or maybe there's another way of doing it that I'm missing? $\endgroup$
    – vonLuckner
    Apr 6, 2022 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.