cmcgrath5035

Not that I have seen/heard of at the level of functionality in Chilipeppr. A few folks have said they were working on something, but no confirms they were ready to launch.

Have you considered breaking long jobs into two or more segments?

Hopefully someone else with better ideas will stop by.

Good to know. Thanks for update.

I am not familiar with sheetcam, but looking at the above am guessing this is inch mode (G20) Gcode.
First recommendation would be to regenerate your job in MM (G21) mode and try that. TinyG is native mm, has to convert all inch dimensions, which sometimes causes accumulation of precision errors and triggers Gcode ‘rule checks violations’.

There is a general issue with Gcode Arcs, G02 and G03 commands, not just circles.

Another fall back would be to have Sheetcam generate Gcode without arcs, rather use short G01 moves. Youl’ll have to look into Sheetcam post processor options to see if that is possible.

tinyG issues status reports, see

https://github.com/synthetos/TinyG/wiki/TinyG-Status-Reports

But status reports will only be useful if the tinyG process remains sane.

There are numerous possibilities, not much known about your specific setup.

Spindles, when pushed too hard into material, can generate enormous additional electrical noise that could be impacting Limits stitches.
Steppers and drivers will heat up if they are unable to make commanded ‘steps’
Power supplies, if instantaneously overloaded, may dip output voltage in current limit mode, causing tinyG to ‘glitch’, misread code, lose sanity.

Bottom line, there is no easy way to determine if you machine has the capacity to do what you are attempting to do, except experience.

If you have not already, head over and look at what is posted on the Ox forum,

https://plus.google.com/communities/110852928951643236736

I have seen several good posts by users on their successes, and failures, in aluminum machining. Perhaps there are similarities discussed applicable to your situation.

For some, transitioning away from G2/G3 to all linear moves has helped. On very complex jobs, the Gcode file sizes get very large, often hitting the limits that Chilipeppr can handle. Some Gcode generators have a ‘no arcs’ option, I am not sure about Fusion360.

Try a Google search on ‘tinyG helix’, you see several recent threads and discussion of Fusion360 post-processor tweaks.

I have no first hand experience with helix motion, but would say that logically, complex motion (arc moves) in 3D (x-y-z) would be more likely to find bugs than would just 2D (x-y) motion.

If you do find a ‘cure’ that works for you, please report back and share it. We have had several threads of this type that just go silent.

Gcode sender programming is really out of scope for this tinyG user Forum.

Xon/Xoff has been around for a long time, and is usually handled by the serial driver layer. Are you planning to develop the entire sender, including the serial I/O handler? Big job, timing is critical. You could also use RTS/CTS (hardware) flow control.

You ask about queue based flow management. The only implementation I have heard of is Chilipeppr and the SPJS(serial port json server). It is all open source, but way beyond a “snipet” in scope and complexity

Good luck with your project.

Yes and no.
What you are suggesting would be typically considered CAM layer processing, but there are no strict boundaries between Machine and CAM in this zone.

I have not seen any discussion of adding this to tinyG, but devs look here from time to time.
You could enter the suggestion at

https://github.com/synthetos/TinyG/issues

A lot more detail on how you believe the distortion would be measured and entered into a parameter(s). would be helpful.

If you really need this solution soon, I suggest the Chilipepr route