On two cut jobs the router did something unexpected. On one file with two depth cuts, it “forgot” to do a couple of the cuts, and on another file, it did a random move diagonaly and rapid across the work without raising the bit which ruined it. I have run the code in several simulators, no issues. Thinking maybe something in the file is not supported? Can chiliperr send code “too fast” for the TinyG to keep up with?
I assume you are focused on the "forgot" to do a couple cuts and the ranom move diagonally... comments.
Both could be symptoms of issues with tinyG's interpretation of the Gcode into machine movement directions, particularly relating to arc commands (G2 and G3 Gcode commands).
Unfortunately, simulators do help your visualize Gcode directives, but there are many ways for simulators to make interpretations of Gcode that are not or cannot be implemented by tinyG.
Suggestions: Review this:
https://github.com/synthetos/TinyG/wiki/Gcode-Support
to get an idea of some of the Gcode commands that are not implemented or fully supported.
Also, please confirm that you are running the latest FW, 440.20.
While likely not in play here, have you run enough basic Gcode to verify the dimensional accuracy of your machine's settings. e.g. when commanded to trace a 6.5" circle, do you get a 6.5" circle?
It will take some time to analyze your Gcode. In the meantime, I believe CamBam has an option to use only short linear segments, no arcs. You could try that to see if it performs more accurately for you.
To your final question above relative to ChiliPepprb overrunning tinyG; that is doubtful. ChiliPeppr, and SPJS specifically, are designed around a buffer fill algorithm and strategy that aims to prevent overflow while keeping tinyG "fully engaged".
