strange gcode problem.

I have a very strange problem with a file that works well in the MPCNC, but not in the lowrider. and I do not think it’s a mechanical problem because it always happens in the same place at any speed.

In the picture you can see how the first passes are correct (red line) and all the others go a little to the center of the piece. There is no loss of steps, the only part that does not respect the program is that. The piece has 1 meter. And it only happens after the third pass

It does not feel that the router is doing a significant force or there is torsion or vibration in that particular area.

The toolpath in cambam looks good, I don’t see the problem that occurs when cutting.


What speeds, plunge, and rapid speeds are you using on each axis?

The lowrider has more mass and can not move as fast. It can usually make up for the slow feeds by making deeper cuts.

It is a symmetric file, all at the same speed, and the error is always in the same place, and only in the first passes. I do not think it has to do with speed. I used a lot more speed in other jobs.

2000 feedrate, 200 of plunge, 1.5mm of descent per pass.

No rapid speeds intervenes in the problem area. Anyway, I limited the speeds by firmware. Something more limited than those that originally come in the firmware, especially in Z because my machine is very large and the z very heavy
I think it may have to do with numerical precision, with the smoothie (mpcnc) it happened to me that some small curves cut like circles
I have a Ramps on the lowrider
/** * Default Max Feed Rate (mm/s) * Override with M203 * X, Y, Z, E0 [, E1[, E2[, E3[, E4]]]] */ #define DEFAULT_MAX_FEEDRATE { 150, 150, 15, 25 } //MPCNC (OVERRIDE)
1 Like

2000mm/min is 33.3mm/s and a 1.5mm DOC. Your be better off doing slower and deeper. A speed of 500mm/mm and a DOC of 6mm would be better. It will wear your bit more evenly too.

I highly doubt it’s a precision issue. If you had 1/32nd stepping, it would be 200steps/mm. That plus a feedrate of 2000mm/min seems pretty tame. The actual calculations are at the same precision on an 8 bit micro.

2000, I use 600. I agree with Jeff.

Rapids are always used, and need to be set, and verified they are in the Gcode. As I said I think this is your issue. Post your gcode and we can verify quickly.

The firmware does not always work to limit speeds, promise. On top of that you have your set entirely too fast. I rapid at 35, you are cutting at that, and trying to move at 150 , which is faster than the board processor can handle that is why I have a hard limit of 120, that you have over ridden. The Z axis is far less 4X actually.


If your rapids are not set in the gcode you are trying to rapid the Z at 150mm/s, when the board can only handle 30.

Whit this model I started to cut at 800mm/min and plunge of 3mm, then I tested it at 500 too, also going down 3mm. In both cases I had the same problem in the same place. But also, the bit burned the wood, a lot of smoke. I made the calculation on the basis of the milling cutter (6mm and two flutes) and it gave me that it should be close to 4000 at 18000rpm. But with the inertia of the machine it seemed too much. At 2000mm/min this stop burning the wood, and the result is excellent. That is, with other models I do not have this problem, only with this one.

this is the gcode:

palas2000p.gcode (1.26 MB)

A single flute is a better option at those RPM. Or just change the RPM. The machine is basically a fix system, you can very easily change the bit and RPM, and a larger bit spin even faster (SFM). That is why I recommend a single flute 1/8".

What would be the configuration for a 6mm single-flute bit and hardwood ?


But I insist. I Tested this model at all speeds and milling cutters. Always the same problem.

You could try configuring your drv8825s for 16th steps.

You could try cutting in HD foam.

In that picture, which way is which? Which axis moves with the wheels.

these are the axis