hello!
I'm running a tinyg with cnc.js and when running arcs I keep getting a planner buffer error. Buffer is visualized in cnc.js and has a max "32" read out ... when the buffer reaches 32 the program times out. I can resume the program by re-hitting start ... but this is not ideal.
Can I increase the buffer? What is the 32 unit? bytes? bits?
Thank you in advance
I have not heard this one before, but then cnc.js is much more aggressive in displaying returned (from tinyG) status and error messaging.
A common issue with tinyG and Arcs is end point errors due to lost precision in the 8 bit math environment.
Is your Gcode in inch or mm? MM runs with better precision, due to fewer mm to inch conversions.
You might also try generating your Gcode without arcs (will use short linear segments)to see if that Gcode runs.
Have you browsed the tinyG wiki at https://github.com/synthetos/tinyg/wiki ?
For possible methods to modify the buffer allocations, I'll suggest to post at https://github.com/synthetos/tinyg/issues where the developers pop in on occasion and heavy modifiers share ideas as well.
based on this post:
https://synthetos.comtopics/tinyg-planner-buffer
how do I modify "chordal tolerance value" to be >0.001mm?
This could resolve my error condition?
From the serial console, sending $ct=0.01 should work.
You can read back (manually verify) by sending a $ct
See https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#ct---chordal-tolerance
The typical default setting is $ct=0.01 mm.
Any reason why yours is set to 0.001 ? (mm, I assume)?
read back my setting:
$ct=0.01
it was default ... the .001mm came from link I referenced
changed it to
$ct=.1 in hopes this may elevate my error
still got error ... I didnt realize the console provides a error code:
err code:155 "arc specification error"
any idea what is causing this?
Google can be your friend for lots of discussion "tinyG acc specification error"
The root cause is the accumulation of math errors running in the 8bit machine accuracy of the underlying computing hardware. Because tinyG does all it's work in MM's, and has to do numerous inch to mm conversions when working with inch Gcode, many folks find that simply exporting your G code in G@21 (mm) notation resolves the issue.
It is not an issue with the number of significant digits of precision in parameters
Another option is to tell your G code generator to no use G2 or G3 moves (arcs). This will create much larger Gcode files as curves are represented as multiple short segments in Gcode
Google around a bit, others have tried techniques that might work for you in your tool environment.
Back to TinyG Support or the forum archive.