How fast can you run on 8bit?

Okay, so I’ve got most of the kinks worked out, and have started bumping up my feed speeds. I’m currently starting to pass the 1800mm/min (30mm/s) mark, and I’m seeing some odd behaviour. The machine will pause and then continue from time to time with a bit of a jerk to the motion. Typically this is near arcs, but then EstlCam puts arcs in at all of the corners, so it’s hard to be sure.

Note that it is not missing steps, and the finished cut looks okay.

It seems to be most common at a junction between a straight segment and an arc. This did not happen before, and seems to be an issue with the higher feed rate speeds. I know these 8 bit control boards run much faster with 3D printing, but most slicers do not use G03 arcs, they break arcs down to short line segments. I’m wondering if it has something to do with that.

When it first started happening, I thought that there was something wrong with the motor wiring, but it keeps to the programmed path, just with a few unexpected jerks and stops. If it’s a multiple pass cut, it does not do it every pass, and the pauses are not all the same length of time.

Way back when I was first starting this, I was thinking about using a Duet board. I’m starting to consider it again to see if it solves this issue.

Hmmm. A lot to cover. Board, step rate, resolution of your file, SD/Pi/USB, firmware version?

A test a while back with with Omri’s files showed USB was faster than the SD. On a ramps/LCD stack (32nd stepping). Not sure about the V1Pivs USB, I assume it is the same or slightly slower.

Arc’s should free up a ton of lines of code…but there are firmware versions that do glitch with arcs, the current one should be fine though.

Now if you are talking lasers…a whole new ballgame. The inline commands seem to choke things up a bit. 28mm/s for 32 bit, 22mm/s 8bit…so that is odd, not what you would expect but the tests verified that a while back. I assume that is a SD limit so TFT vs LCD pipeline, not an actual processor test.

Okay… Details…

It’s an MKS Gen L v1.0 board. Firmware is (I think) latest Mega2560/RAMPS, working primarily from LCD. 32X microstepping on DRV8825s. LCD is one I got from V1 store.

Files have been various ones created in EstlCAM, as that has been my primary GCode generator all along. I too was under the impression that the G03 arcs should free up lines of code and speed up processing. I’d be freaking out if my printer did this, and it’s going more than 3X this speed. (It’s also running a Duet board, so it had better be faster.)

I might limit speeds to 1800mm/min, and consider slowing it further from there if it doesn’t clear up.

The move needs to be communicated to the board and then the board has to do the planning. Then the board has to spend some cpu stepping.

Switching to arcs makes the serial faster (or the sd card comms). But then the cpu has to do more work. I can imagine large arcs being more smooth when they are precomputed in CAM.

Something would have to be pretty wrong for the steps to be the bottleneck. But you could try 1/16th microstepping to make that go down by 2x.

I have nothing of value to add - other than that I think you all are great people!

5 Likes

Another, mechanical aspect that may be important: The faster you go, the more inertia there is. I don’t know if you can change the setting if you don’t use Estlcam to cut the parts though, but then again your software might have a setting for inertia as well (maybe).

There is a maximum acceleration. Which can significantly slow down moves. There’s aren’t any other inertia settings.

Inertia doesn’t seem to be the problem. When this happens the system doesn’t use the accel value, because it assumes that the machine will keep moving at the end of the arc (or line) and continue straight on to the line (or arc). When it stutters, it comes to an abrupt halt, and then jerks back to a start at full speed right away. Even so, it manages to not visibly lose any steps, there isn’t even a ridge in the finished cut. At these speeds, it might even be possible to ignore acceleration entirely… But I don’t like the jerky motion. I’d rather lower my acceleration threshhold further, but it seems acceptable where it is.

Anyway, I can count on it happening once I get to 2000 mm/min, and hardly ever at 1800mm/min. I think that I could cut with the single flute at 2100 mm/min with the 2.25mm DOC. That seems to be pretty good for producing chips (And not just sawdust) I have to slow the router down at 1800.

I’m thinking that it might be a floating point problem, calculating the arcs seems to be the sticking point. I hand coded some straight moves at 3000 mm/s in a sort of star pattern and ran it (with the router not running) at various angle. It doesn’t seem to be a problem with stepping at all.

That’s my guess. Maybe I didn’t make that very clear. I think doing the trigonometry is the hard part (although I vaguely remember a comment from thinkyhead that he was using a look up table, not floating point trig). Have you tried turning off arcs in the CAM? That is essentially precomputing the arc calculations, and then the problem goes back to being a serial comms problem :slight_smile:

Or, maybe this is just a case of buying a 32 bit board and forgetting about it.

That’s a serioius consideration. I still have the Duet Wifi board sitting here that would handle the job very nicely.

I’d of course have to do all of the firmware configuration, but I know that I’m not alone in this, there have been several people talking about configuring for the MPCNC in the Duet forums. I have a pretty good handle on how to configure what I want anyway.

I can see about turning off the arcs in EstlCAM though, and see what that results in. I don’t think it’s a matter of the serial or SD card speed. Like I said, most 3D printers run much faster than this. I typically print 80-100mm/s print head speeds.

Flip that switch and turn off arcs. See how it goes. This has been a known source of issues every so often. Slicers do limit the file resolution though. I know I have seen a video or two about it. One of the bigger channels tested this for sure. There are issues at higher speeds, not everyone notices them though.

1 Like