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?
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.
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?
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°
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.
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.
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: 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.
I suppose the next step is to break the process down into several smaller sub-60k files and try again.
Autch, that hurts
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.
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.
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!
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.
