Cutting speed doesn't seem right

I got my Maslow put together and cut the sled out without too many issues. After that, I decided to try my hand at an artistic cutout from 3/16 in Hardboard Tempered Panel. I made a model in Fusion 360 and generated my g-code.

According to Fusion:

  • Feed Distance: 1* 564 in
  • Feed Time: 57 min
  • Rapid Distance: 442 in
  • Rapid Time: 2 min

The problem is, the cut time in Ground Control was 8-10 hours! (I don’t know the actual time as Ground Control said it lost USB connection after 4 hours at ~40% complete. Nothing was loose and as soon as I clicked connect, it connected again.)

An estimate of 2,000 inches of cutting / 8 hours tells me the sled was moving at about 4 inches per minute. This matches my visual observations as well.

Is Ground Control running much slower than expected? Did I miss a setting somewhere? Is my g-code wrong?

Can you post the gcode? First thing I’d look at is the feedrates in the .nc file (i.e. F commands)

2 Likes

Alice.nc (1.5 MB)

Per other posts, I tried setting the feed to 35 in/min since I was cutting very thin stock, but I’m new to the CAM side of things so it’s quite possible that I’ve made an error somewhere.

Attribution: Original is most likely from “https://www.etsy.com/listing/221659265/alice-in-wonderland-paper-cutting?show_sold_out_detail=1” or “https://folksy.com/items/4368736-Alice-In-Wonderland-Paper-Cut” (not sure who copied who).

SVG variant I made in inkscape from google images:
alice

Fusion360 extrusion based on the SVG:
https://a360.co/2F9OPNO

1 Like

I’ve noticed similar behavior when using Fusion’s “trace” command to do engravings. Even with a higher feed rate specified in the G-Code, it slows down the actual cut speed. My theory is that is because the resolution is set super high in the program, and so there are tons individual commands are sent for a relatively short cut. I have not done any testing to confirm this, however. If you lowered the resolution of the cut path, does it improve cut time? Does the firmware get chocked when a lot of lines of code are sent to it?

I think this is exactly what’s going on. Making gcode line processing faster is high on my TODO list so expect a change probably in 1.13

3 Likes

Welcome!
With the amount of detail I would consider GroundControls’s estimate as highly optimistic.
Alone because of slow Z-axis this will not be achieved.
Will run it in fake-servermode starting tonight and see in the morning how far it got.
What surprises me about the g-code is that it ends at exactly 60000 lines (GC counts 60001 to trigger the pop-up).

Edit: You would need to ‘define home’ low down left, and how good it cuts at the top will be interesting.
I would rotate 90°

Edit2: I have seen worst zigg-zagg between cuts, but there is still plenty of time to be saved by reducing ‘no-cut-travel’.

Edit3: I’m missing holding tabs I guess.

Edit4: Looks good in CAMotics but count Z and look at the ‘no-cut-travels’

Edit5: It is a 0.25" or 6.35mm depth in one go.

The feedrate is set correctly in the gcode. All this detail it will take a long time; this file is even slow in ncviewer.com and that is pretty sped up.

2 Likes

the odds are good that there are just a lot of small lines to cut in the curves,
and just processing those lines takes far too much time.

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.
alice2

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

The final result cut in about 3 hours.

11 Likes

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!

4 Likes

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):
NewAlice

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:
NewAlicePlunge.nc (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.
http://www.scorchworks.com/Gcoderipper/gcoderipper.html
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!

3 Likes

Looking at the cut:
image

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.

2 Likes

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?