Is there a maximum number of lines of gcode processed per second?

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.

David Lang

Thanks David,

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.
1 Like

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.

There are a number of g-code optimizers online, and madgrizzle is working to add
one to webcontrol.

David Lang

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.

Webcontrol does not require being online to use.

think GroundControl but using a browser as the GUI

David Lang

Ahh OK - I’ll still do my own gcode, the current stuff is in Typescript. So I can easily flick that out and run it from the command line using node.

But using WASM in the browser would be an awesome way to go.

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.

why doesn’t it work on the the rpi?

I was using or-tools from google and it’s not supported on arm platforms.

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 was planning on rewriting what I’ve got in C# anyway and then using .net core 3.1 - that gives support for:

  • x64 on Windows, macOS, and Linux
  • x86 on Windows
  • ARM32 on Windows and Linux
  • ARM64 on Linux (kernel 4.14+)

I do a lot of Python for work. Let’s just say that I’d prefer to use C# or Typescript, or maybe take this as a learning experience for Rust.

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.

1 Like

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.

1 Like

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?