Help me check my g-code checker?

I have made a g-code checker to scan for common errors or possible/likely mistakes. Although it’s a web page, it operates entirely client-side.

https://vector76.github.io/gcode_tpgen/checker.html

This is an alpha version and I am looking for feedback on things that could be helpful to improve.

Eventually I want to extend it with post-processing capability where it can modify and “download” a version with optional adjustments made:

  • Split long movements into multiple smaller movements so the GUI and LCD have less lag
  • Collapse multiple tiny movements that are collinear (within some tolerance) into single larger movements to reduce stuttering
  • Inject fake tiny extrusion movements so that Octoprint will render the toolpath
But that is later.

Any thoughts, however minor, I’m happy to hear.

1 Like

This may end up messing with dual endstop machines (where weve mapped E0 to a random pin), or if we ever get EXTRUDERS=0 to work.

Calculating the Z speeds, especially in 3D carve operations is going to be very useful. If you can then reduce them to be within some limit, even better.

Regarding the total xyz limits. It would be neat to output a little limits code (at least in xy). So you could test the bounds of the carve first. Probably move to the clearance plane, then walk around the outside bounding box. Even better would be to actually trace the outside contour.

Are there specific laser gcode checks? Turning the tool off at the ends? I would have to go back and look at all the things we learned about M106/M107 in that laser thread.

You might know more about web dev than me, but have you ever tried create-react-app? Thay, along with reactstrap make a pretty nice looking webpage pretty quickly. The structures in place are really nice for developers.

In general, this seems pretty awesome. I hope people will start sending you their gcode file for you to have a decent test collection.

1 Like

Let me know if you want me to review any or all of it. (But be warned, I’m generally a C++ coder).

Subscribed. I need to run some gcode through it and see what happens. Cool idea for sure.

Thanks, I will take a look at React js. I doubt I know more about web dev than anybody. I still write html by hand and it shows.

I think an option for inserting an XY perimeter at the start is a great idea. I can start with minimum bounding rectangle and perhaps later inplement a convex hull :).

As for the extruder, you’re right it could conflict. I haven’t looked into what it would take to modify Octoprint with a plugin instead, but I doubt it is as easy.

Maybe I can gather some amount of gcode from people asking for help on the forums. It would be nice if the program gives the same advice as the human inspectors.

That would be awesome.

When I started sandify, James was nice enough to point me at create-react-app. https://reactjs.org/docs/create-a-new-react-app.html . It does use react.js, but it’s much more than that. It sets up an environment, using node.js where you can serve it locally, and whenever you make a change to the local .js files, it immediately loads the changes in the browser. It also seamlessly integrates tests, and when configured, lets you “compile” (for lack of me knowing the better word) the files into minified pieces and publishes to github.io. It will let you easily install node libraries, like reactstrap, which is a nice library for quickly making pretty web pages (it is bootstrap 4, for react).

There are a lot of terms, and they all seem to be some combination of react, and boot, and then there’s redux, which is also really awesome…

Firstly, you have to trim line in any case, even after cut trailing comments.
Secondary, () brackets are comment to (usually in grbl-style gcode, but modern marlin could support it too).
Next. I don’t remember exactly, but i think that in reference nist rs274 interpreter the execution unit is a line and a command could be in any position (not only word[0]). Moreover, i guess that a few commands from non-intersectred domains can coexist in single line. Pls check https://www.nist.gov/publications/nist-rs274ngc-interpreter-version-3
So probably it’s better to parse a line to some tuple/dictionary/object (execution unit with one or a few commands and with parameters) and then handle it.

And last. I think to achieve good level of checking you have to build true state machine as real cnc is. Otherwise the checker will not be able to catch even so simple errors as violating working area limitations when work in relative coordinates mode, when execute arcs, etc

2 Likes

I’m pretty sure Marlin doesn’t support this. NIST or not, if you’re doing this with Marlin, it’s not good. I suppose if this was trying to check grbl gcode, then that should be understood, but for Marlin, it should be an error or warning.

Thank you fir the input. I think i need to specify more clearly what it does and doesn’t (try to) do.

It’s more of a checker for beginner mistakes when feeding gcode to Marlin in the default MPCNC configuration. I need to add a warning because advanced features like workspace offsets are not intended to be handled, and it needs to be clear about that.

You are right, it looks like marlin support only one command per line. But marlin become more and more sophisticated. As example, if you look at parser.cpp you may be surprised that it could support sticky motion mode (g0-g5 + g80)

Hmm. Imho, beginners mostly should use (and they do) proven software that produces valid ready to use gcode. Like popular here estlcam or fusion 360 pp. And probably they don’t usually use handmade gcode.
Just ensure for yourself that you trying to solve real problem :slight_smile:

I think the use case is someone who is using Estlcam or The Guffy PP or Sandify and putting in values that are troublesome. We often have people paste their gcode in the forums, and we do an “occular pat down” to see if there are any obvious errors in it. Then we try to figure out which setting caused it. This would automate that a little, and give people who maybe don’t want to participate in the forums a chance at finding their problem.

Yes I agree completely. Jeff is right, it is for catching common user errors when using those well-proven tools. Like Z feed rates much too fast. Negative coordinates are problematic for dual endstop builds but CAM doesn’t know that.

1 Like