I just finished a rather long (13 hours+) cut.
I had used estlcam to generate the gcode. The result was normally around 8-15 lines of gcode per millimeter of cut (and about 15MB file size).
What I noticed in Groundcontrol as it was processing it was that there seemed to be a maximum limit of around 10 lines of gcode per second.
Is there a limit on the throughput rate for lines of gcode? Is the limit in Groundcontrol or the Arduino?
After doing the above cut I’m thinking of doing some gcode preprocessing for eliminate some lines of gcode that are ‘redundant’ (within some tolerance). But I’m still interested in learning of what processing limitations there may be.
Yes, there is a bottleneck on the arudino reading and parsing logs. there is an
option to do buffered processing, which can speed things up (it can also cause
problems in some cases, so it’s not on by default), a slow computer sending to
the arduino can make the problem worse.
I’ll do some work on a gcode preprocessor to ‘thin things out’. I’ll figure out the algorithm first and do something standalone. I do a lot of work in Python, but it is too slow and cpu intensive, so I’ll switch to .net core and c# for some speed while still being managed code (or maybe rust?)
Yeah that seems excessive!!!
I don’t use estlcam but:
You may want to simply/optimize the model before opening it in estlcam. Illustrator and Inkscape have path smoothing/simplification. CAD programs often have path optimization (to tolerance) or refit/rebuild operations.
Also the file type you are importing may make a difference. STL will approximate curves to short line segments and should be avoided. Most DXF version will also do the same - check export setting and use highest version which might support splines. SVG, IGES keep curves.
Check the printer/cnc configuration options:
If there is an option to use G2/G3 for curves/arc then enable it.
If there is any smoothing/optimization or refit to tolerance that you can do on the tool path to reduce the number of points.
The original image I had was an SVG source. I put it through a LOT of processing, so that I could get edge detection working well enough to generate a new SVG image based upon the edges. Throughout there was lots of smoothing being done.
estlcam accepts SVG as a source, which is what I used in this case.
My preference is to write my own gcode reprocessor. I think that will be more useful than trying to futz around with estlcam’s options.
Online, gets tricky here. Plus I’ve already got some gcode parsing stuff that I’ve built as an extension for VS Code. So, I figured, why not. I was thinking as a simple command line utility.
The gcode optimizer I was working on just rearranged gcode so that it would minimize the travel time of G0 commands. But the code I got working doesn’t work on an RPI (only for x86 machines) so I’ve shelved it for a while.
the gcode tools extension written in python for inkscape is available on github so perhaps you would not need to write the entire thing… maybe just improve an exisiting gcode generator to output optimized gcode?
I’m curious what your ax to grind with python is or are you most concerned with the compiled execution time improvement with the C# code? I’m not a fan boy or a professional programmer, just curious what has influenced your preference.
I know you didn’t ask me the question, but I’ll chime in on my take. I’ve written two pretty decent sized web-based applications, webcontrol using python and scientific program using c#/aspnet. Both programs were my first attempt at using those particular languages. If I had to do everything over again, knowing what I know, I would still write the programs with those languages. The c# program uses Cuda to utilize a GPU to do parallel processing. I’m not sure how to do that in python and some of my routines can’t be gpu-accelerated so writing those functions in c# gives me a performance increase over an “interpreted” language like python. For WebControl, I used so many opensource libraries (seemed like there already was one written to do what I wanted to do) and the language was very accessible. You don’t really have to know python to be able to read python whereas c# seems a bit tougher to decipher. I think by using python, more people can contribute to the project than would with c#/aspnet. Webcontrol doesn’t need the speed associated with a compiled language and doesnt need GPU acceleration to complete a task in a reasonable time.
That sounds reasonable and I was wondering along similar lines. I just looked up rust and wasm which is web assembly. I used to write a little in assembly for microcontrollers. C was worlds better to write and understand, but not always easy to fit in the available memory. One would really need to be resource constrained to go that direction it seems. Usually there is a history with a project requirement or experience to point to a certain preference… just curious.
With respect to Python it definitely has its place, and you can’t deny its popularity. However, even though it had a “Benevolent Dictator for Life” for most of its history, it still is obviously “designed by committee”. There’s lots of hard-working and enthusiastic people involved in charting its course, and they are often very well-thought and articulate in describing why certain things were done they way they were. But you get the feeling that an overarching vision for the language has always struggled to be heard.
And when I’m working with so many other languages the whole time, coming face to face with these (apparently) niggling inconsistencies so often, I’d just rather not be bothered with it for any personal project.
so it is more work to work around the inconsistencies to make it work than to just do it directly with a purpose built language… it is trying to be all things to all people and not succeeding?