Off-topic grbl

Not an MPCNC, so I came to off-topic. Because I am STUMPED, I’ve spent the last 3 weeks trying to find an answer, can’t find help anywhere, and this place has the biggest brains I know.
Grbl (enducross fork) with external drivers (DM542), ballscrews, linear rails, kfb 3.0 control board (atmega2560), from cncjs.
This thing is drifting on me. It has been suggested already that my couplers were loose, the grounds on the driver weren’t done correctly, driver current too low, machine binding, maybe a couple more things that I don’t remember now.
I have tried twisting the signal/ground to the steppers(on the x, at least, and when that didn’t work I didn’t bother with the others), verified that there is ZERO slop in the machine, confirmed easy and free movement in each quadrant, so I moved on.
Handwrote some code to run a square in the air a couple hundred times so I could get an idea of the magnitude across a few runs. Well, what do you know…it’s off by exactly the same amount each time.


I home and reset the zero (that’s the marked 0,0), run the program, and send it back to 0,0 only to end up at the second dot.
It does this regardless of speed and acceleration (across 8 different runs or so). If this was lost steps to noise, binding, or slippage, I’d expect it to have a random error.
I reduced the microstepping by half (from 1600 to 800) and got about 2/3 of the error. I inverted the step signal and no change. I learned that vanilla grbl now supports autosquare on on uno, and since I have one I put that on it (back at 1600 for microstepping) and got a little more than half the error. It was suggested I unplug the enable because low=enabled, and that was no different.
I ran my test just a couple dozen iterations, and I got an error not too far from the origin. The code does not drift on my primo.
Whatever is happening is systemic, and stacks with movements (longer program=more movements -> larger error). It’s somehow tied to steps. And the uno creates less of it than the mega.
Next step might be to call a priest.

All three axis same issue?

If you run the square gcode several times in a row without powering down does the error get worse or go away, or step away the same amount each time?

What speeds are you trying to run at?

1 Like

I haven’t checked z. When I run the square a couple dozen times, small error. Couple hundred times, bigger error. I haven’t tried hundreds and hundreds, but dinner is soon so maybe I’ll go let her rip.

I can’t imagine what this could be. I would try X and Y separately to see what happens. Maybe you have a bad driver.

That’s really weird. I’m assuming the error is basically perfect. I think we can test that. Something like have it touch every cycle or every 10 cycles, and see if it makes a line, and if the distance each cycle is close to identical, etc. But if we pretend it is perfect, what can cause that?

You said the speed didn’t make a difference.

You said that changing the microstepping did.

Those two things point to drivers to me. If it was in the uno, then the microstepping wouldn’t change it, unless the speed did too. If it was anything downstream, motor wiring, electrical noise, something slipping, it would be both irregular and unpredictable.

Can you just drive them with 8825s for a while? Just to test?

Funny, I was just going to ask if 8825s were adequate under no load.

That’s what I was thinking, but it would have to be all of them, because there are 2y and 1x. And the error is the same for each axis, each time. It does seem a little worse on x than y, with x being the longer axis.

Could this be a active workspace coordinate issue? As in not homing or zeroing right? I had a heck of a time with the new zen.

I think that could be checked by just rerunning the code several times without homing between each.

I’m on the third run right now, I’ll run a fourth and get back to you.

Yep, more error.


The unmarked divot is the uno 0, 0 after running once. Where it is right now is after 4 times.
I ran again just once to double check

Super dang consistent. That’s with me resetting the zero manually because I can’t get the home switches to behave on the uno.

Is your firmware trying to do backlash compensation?

If I’m reading that right, the error is happening at 45° drifting towards positive X and Y from home.

My thought about the backlash compensation is that (from what I remember) it moves the tool slightly past the intended point in one direction, then moves it back so that the backlash is always in the same direction.

If that is trying to move the head past the origin, (say to -0.1, as an example) and the firmware is stopping it from going to negative coordinates, or something isn’t allowing it, it will instead stop at 0, then move to +0.1 to set the backlash, and the error compounds every iteration, because while it thinks that it’s moving back to 0, it’s actually iterating that small movement.

To test, instead of a square starting at 0,0, start your square at 10,10

G1 X10 Y10
G1 X110 Y10
G1 X110 Y110
G1 X10 Y110
G1 X10 Y10

and so forth. If it’s trying backlash compensation, it should succeed, and not compound an error. I dimly remember someone else having a similar problem with an entirely unrelated machine.

I went digging through the config file for backlash compensation and didn’t find it. Haven’t mentioned it because I thought maybe it didn’t exist.
I’ll do some googling for it.
Fwiw, my square is just an inch going from 1,1 to 2,2.

If it’s starting at 1,1 (Inches?) then it shouldn’t be backlash, unless it’s doing it SERIOUSLY wrong.

Rounding error in steps/unit?

Looks like grbl didn’t implement the backlash control yet anyway. At least one fork has, but that’s all I could find.
I don’t think i mentioned it, but I ran the same test in mm, too. I’m not sure how rounding works, but the end points should all be full steps at both 80 and 160 steps/mm.
Plan for tomorrow :

  1. delete all the y moves and see how it behaves in x, do the same for y. Expected outcome is the same error, but in the components
  2. jam my 8825s(found them) into the cnc shield and plug the motors into that instead. Expected outcome is magic smoke.

Just generate gcode with no homing sequence that is supposed to start and stop in the same place and run it a few times. I think the homing process you are doing might be the issue. Grbl wants you to work in a workspace, not the default space. I have not wrapped my head around it yet. Coming from Marlin, the homing stuff is actually very different.

1 Like

Not unless you are driving them at a really high voltage. The risk is that a setting for current on the 8825 is too low and you just skip steps. If you don’t skip steps, then it will be fine. If you do, you can try upping the ref voltage/current and risk overheating the drvs. But even then, they usually protect themselves and you’ll just get step commands going to a disabled driver.

Honestly, the biggest reason I suspect the drivers is because it is such a weird problem, and I have never used those drivers before.

Yeah, this code doesn’t have any homing in it. Before running I jog over to the marked spot, zero the work coordinates, and turn it loose. On my first board, I ran the home sequence from cncjs.

That’s really good to know. I don’t understand any of the electronics, really. I was thinking of them kinda the same way as fuses and breakers when you throw something with a large draw on the other end. This is why I never chime in on that stuff, lol. It’s one thing to be smart by knowing stuff, but I’m still working on being smart by identifying what I don’t know.

1 Like

99% of power supplies we deal with are constant voltage. They do whatever they can to provide the specific voltage (12V or whatever). Stepper drivers are basically constant current supplies, which are completely reversed. They can provide any voltage from zero up to their source voltage. But what they “care about” is providing a specific amount of current. If they want to provide 1A on coil A. Then they may provide 0.1V or 10V, and they do this by turning the 12V on and off really fast (PWM).

It gets extra confusing because on something like a drv8825, the current setting is picked by setting a reference voltage. Which makes sense if you know how the circuit is designed, but it is confusing for the a novice.

All that is to say, your instincts are good. You are just in a 1% situation where the dependent is independent. You need to get a bit more understanding to see how they are connected.

1 Like

Step one complete. I’m re-flashing my uno to pop the shield on just because I’m curious now, but have a look at this.
Square code:
G20
G0 Z0.6
X1 Y1
G1 X2 Y1 F39.37
X2 Y2
X1 Y2
X1 Y1
G1 X2 Y1 F39.37
X2 Y2
X1 Y2
X1 Y1
That’s just copy/pasted a ton of times.
For the components, I just ran a find/replace on the lines I didn’t want, so I’d be left with left/right and up/down. That way, I’d have the same number of moves for that component.

I ran the left/right first (x axis), and got no error. Popped right back where it was supposed to.
Ran the front/back (y axis), and got…ALL the error. The bit dropped back at the same point it hit after running the entire square.

It just occurred to me that maybe I could have double checked the first move out and back, but really I ran just a few dozen loops yesterday already, and the entry/exit to the square start at 1,1 exists in all programs, so it has to be from running up and down the Y.

Systematic noise? Is that a thing? It won’t hurt my feelings a lot to rewire this if that ends up being the solution. I just don’t want to rewire it for no reason.

I’ll post back after running the 8825s.

Okay I am not experienced with GRBL at all. I can say none of my gcode looks like that at all.

Maybe someone else can verify if that should work?

G20…probably best to leave it in metric. G0 is a rapid with an unspecified speed, grbl does have a default but did you set it to something reasonable, and did you set it in metric or imperial?

That seems to be a tiny test square. at a very slow speed.

I would do something like
G90
G1 X250 Y250 F1200
G1 X-250 Y-250 F1200

That is a diagonal move out and back at 20mm/s ( a little less than 1"/sec)

Yeah, small square by design. I thought it might be related to direction changes because I didn’t notice it at first except in arcs. GRBL G0 moves at the machine max speed, set to 6000mm/m for me. I also intentionally chose a lower speed to rule out mechanical slippage, knowing that I could increase it with cncjs by a factor of 2.
The F is 39.37ipm, ~1000mm/m for the cut speed. Since G1 is modal, GRBL will execute the following statements as G1 until it’s instructed to use something else, and GRBL remembers the G1 speed until I redefine it. The only reason I have the G1 and F39.37 repeated is because I was being SUPER lazy(copy/paste) and I knew it didn’t matter. That’s right, I couldn’t bother myself to edit that one line before I copy pasted a bunch, and by the time I thought about it I was already a couple dozen loops in. I also never expected to share it, lol.

I could have just as easily gone from X1Y2 to:
X1 Y1
X2 Y1
X2 Y2
etc.

I also did run this same test in metric, find/replacing for 25.4 and 50.8 with the same results.
I’m super comfortable and confident with the gcode as is.
I had just gotten all my plugs wired up for the uno (reflashing for the shield), but had to stop to teach my kids some judo(3x/week!) and now apparently I have to pretend I know how to troubleshoot my wife’s computer that likes to shut off unpredictably. Hopefully I can get back to it before bed.