Cutting speed doesn't seem right

Thanks for all your help. I simplified the paths in the SVG, tweaked the image a little, and minified the file reducing the decimal precision.

I then dropped the tolerance in Fusion 360 to 0.1 inches which produced much less dense g-code. (725.6 KB)

The final result cut in about 3 hours.


What size bit? I have cut intricate items using a 1/16th bit. You might get more detail. Nice job!!!

The 1/4 inch 2 flute upspiral from the Maslow store. This was my first cut after the permanent sled.

1 Like

Wow! looks great for a 1/4 bit. Get on Amazon and order this.

They are basically disposable and I get a lot of cutting time off of them. You will need a Collet to fit into the 1/2 inch router shaft. You will get more detail.

Thanks for the photos again!


Revised my SVG by connecting a number of the cut lines in order to speed up the cut (Z travel seems to account for about 2/3 of the actual cut time):

Followed the excellent recommendation of @Blsteinhauer88 and switched to a 1/8 in bit which allowed so much more detail to come through.

Unfortunately, the added detail pushed up the line count in the G Code file: (1.7 MB)

As a result everything cut rather well for about 3 hours aside from the sled catching on a couple of edges and needing a little tending from me (no tabs so I was keeping an eye on it). Then unfortunately, disaster struck. Despite the assurance from Ground Control that:

The current file contains 82623 lines of gcode. rendering all 82623 lines simultaneously may crash the program, only the first 60000 lines are shown here. The complete program will cut if you choose to do so.

Once the last visible bit was cut the sled immediately did a fast move to the center without lifting the bit and started to move around. At that point I cut the power. :persevere:

I suppose the next step is to break the process down into several smaller sub-60k files and try again.

1 Like

Autch, that hurts :cry:
Guess you are the first to test that and are therefore a pioneer.
I have not tried this one with gcode that long, but perhaps worth a try.
Thank you for exploring the limits and sharing.

1 Like

I’m sorry to hear that!

I have not tested a file that big but I will give it a go first thing in the morning to see if I can figure out what happened…to help me narrow it down do you know roughly what the line number was when the error happened?

I’m out of town on business so I can only go from memory, but it happened sometime around 60,000-61,000. On Saturday afternoon when I get back, I’ll look for the exact spot and upload a picture for reference.

1 Like

Yes Bar, remember in the early days I ran the code for that Disney bench I cut. And the gcode was capped at 8000 lines or something, and you opened the cap to something higher? Well I remember that when I reached the cap, the machine ignored the rest of the code after reaching the limit. It just stared moving in a random direction cutting until I stopped it. So if he hit the cap that’s what happened. @Tyler_W_Cox if I have a large file now I split the cuts. Select the cuts in the upper half and generate a code, then the cuts in the lower half. It looks like it will be amazing. Glad you like the bits!


Looking at the cut:

Comparing it to CAMotics:

Tells me that the problem happened right around 60,500 give or take 50 lines. Looks like the last Z movement beforehand was on line 58,626 and the next Z isn’t until 71,703. I don’t see anything but G1 X Y commands around the area where this happened, so I think it’s safe to say that this was due to some sort of glitch either in Ground Control, the Arduino code, or on the physical layer.


Since 60,000 is the max ground control will render that is where I’m going to start looking.

Where was the home position when this happened?

Huh, didn’t know there was a limit. Good to know. Is it possible to alert the user when a file with more than the limit is loaded - before the cutting begins?

The numbers 60,000 and 60,500 triggered my memory, see this issue. In that instance the ‘Home’ location had been moved from 0,0 and GC wasn’t accounting for the coordinate shift of the unrendered lines.
@Tyler_W_Cox, was the ‘Home’ location moved away from 0,0 before beginning the problem cut? It is valid to do so, but knowing this might help zero in on the cause.

1 Like

How do we feel about just removing the limit. The limit was there because on a slow computer if you open a file with like a million lines it can take a really long time to load. This used to cause Ground Control to freeze, but we fixed that. Now it will just take a really long time to load. How do we feel about removing the limit entirely or increasing it to something big like 500,000 lines?


My home for this cut was defined at about X -694 mm, Y -380 mm and the position it fast traveled to was the normal home at 0,0 in the center of my spoil board.

@blurfl, I believe you’ve spotted it. That seems to exactly describe the events I experienced. I did in fact have my home moved away from 0,0 and after the router moved back to 0,0 it seemed to be continuing with the cut in the original coordinate frame (although I shut off the machine too quickly to be sure).

1 Like

I’d suggest a middle route.

Warn the user the file may take a long time to load and ask them for confirmation. Also, possibly show a percent loaded indicator while loading the file. That way someone unfamiliar with the software knows it hasn’t stalled out. Bonus points if there’s an option to cancel while loading.

1 Like

@Tyler_W_Cox good suggestion! I will increase the limit first and add a warning saying that it will not cut correctly if the home position is not moved first because that will be quick and right now it is broken. Then I will work on adding what you recommend.

I’m a little hesitant to suggest this at the risk of causing more issues because it hasn’t been tested well yet…but I added a new feature in response to your original post about increasing the cutting speed when cutting complex files. There is now a setting which will tell ground control to store lines of gcode in advance on the arduino for faster processing. It makes the machine quite a bit quicker when cutting complex shapes, but we saw issues on some computers with a similar feature in the past so test it with caution.


The portrait file still crashes GC for me and has only 23711 lines.
It was the number of Z that causes an issue here.

1 Like

Great point @Gero the issue isn’t just the number of lines but also the type.

I think at this point the line limit isn’t really protecting us from anything and it is causing more issues. I’ve opened pull request #726 to increase the number of lines to 300,000 which essentially removes the limit.