This is a new job, simple one at that. Eight (8) holes and two circles.
The CAD generated Gcode used a single G03 (ccw) arc command for each circle.
When I originally found it didn't run, I manually changed the two commands from G03 to G02 (cw) arcs and created a second file.
Results:
FW Ver SPJS CW CCW
------ ---- -- ---
440.18 1.83 OK Bad
440.18 1.80 OK Bad
440.20 1.83 Bad Bad
440.20 1.80 Bad Bad
Bad == Bit descends to proper cut depth then immediately returns to safe level and moves to next line of Gcode without any arc movement.
This is a new job, I never tried it on 440.14 and no longer have the 440.14.hex around.
If of use, the tinyGV7 parameters are here (same used 440.18 and 440.20)
-------
For rtgallus - 440.20 has been tested by Alden with a MUCH tougher Gcode file and worked well, so whatever is going on here may not affect others.
The fact that these are full circle cuts may be the issue.(?)
If 440.18 is failing you for some reason, I would say give 440.20 a try and post your results.
Thank you. I'm actually using 440.19 and SPJS 1.80 and also 1.83 and have had no problems. My problem in the past has been overloading of the buffer with other version of SPJS that have resulted with the machine pausing.
I have not had a problem with CW or CCW circles run in gcode generated by CamBam, either in inches or mm. Here is a dropbox link to a file that I ran in air just a little while ago. Most circles are G2 but some G3 also.
FYI, I found that My issue was resolved by invoking a Gcode generator option to cut circles as two half arcs.
But I see that you have some full circles, so yours will be a good test.
Your job seems to run fine, but it is so large it is difficult to tell if there are issues.
In fact, looking at it it is not obvious that there are any single command circles - 360 degree arcs from a point back to that point.
Can you with "designer knowledge" identify any (by Gcode line number)?
Thanks.
Apparently, the implementation of full circle (360 degree ) arcs is highly non-standardized in the Gcode world.
If you look closely, you will see that in fact your files send two arc commands that comprise 360 deg.
That may explain why my gcode tool has an output option to break circles into two arcs, which does work for me.
So problem understood, if not completely solved.
BTW: I found it amusing that my Gcode simulator imports your files with error - 3/4 of a circle and 1/4 of the circle arc incorrectly rotated! No wonder Alden is pulling his hair out with Arcs.
After upgrading from build 438.02 to 440.20 (and note, this also applies to 440.19), G2/G3 lines are no longer interpreted, i.e. these lines seem to just get skipped over, and no response is sent back from TinyG - Everything else seems to work fine, but no more arcs/circles :(
1) How can roll back to build 438.02? Is the hex file available? Couldn't find the branch on GitHub, or a hex file repo. If it's available somewhere or someone still has it, would really help so I can get some jobs done until I figure out what's going on.
2) What else can I provide to help debug this further?
P.S. Just in case it's useful, here's a second file that also used to work; It cuts complete circles (using G3) while simultaneously lowering the Z axis to create a spiral:
Are all your G2 and G3 full circles?
Mine were. It turns out there is a long standing disconnect in Gcode space with the formal definition of a full 360 degree arc.
The common, longstanding resolution is to send full arcs as two half arcs, most Gcode generators do that by default or provide an option.
Full arc Gcode that does not meet the Linux CNC formal syntax criteria is skipped.
This topic is from the original forum (October 2015). Your reply starts a new discussion linked to it.