Cutting speed doesn't seem right

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?

2 Likes

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.

2 Likes

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.

2 Likes