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.
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.
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.
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?
@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).
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.
@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.
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.