A couple of things with G2 and G3
-
Just for the hell of it, I started playing around with controlled arcs using G2 and G3 and came across a couple of little issues.
The first is quite important. When doing a controlled arc move, the axes limits are ignored and it is possible to crash the head either by exceeding the maximum or minimum limits. That is to say that after homing, it is possible to send a G3 command that will send the head below X =0 or beyond X max as defined in M208 resulting in nasty crunching noises :). I haven't tried G2 nor the Y axis limits but assume these would exhibit the same behaviour.
The second thing I'm not sure about. I was trying to do a full circle so sent G1 X150 Y150 F3600 then G3 X150 Y150 I-50 J-50 F3600 and as I half expected, the print head didn't move as the start and end points were the same. Interestingly just a slight change is all that s needed to do a full circle so doing G3 X150.0001 Y150 I-50 J-50 F3600 works (i.e adding 0.0001 to the finishing X value). The question is, should G2 and G3 be forced (in firmware) to do a full circle if the start and end points are the same or is that a dangerous thing to do?
-
On my CNC machine with Mach3 your gcode would mill a circle.
-
I'll add those items to the work list. What should the firmware do if the arc would exceed the axis limits: ignore the command completely?
-
I'll add those items to the work list. What should the firmware do if the arc would exceed the axis limits: ignore the command completely?
I'm not sure. I'd say for consistency, do what would happen if it was straightforward linear move which would exceed the limits. I believe that would be to go as far as possible then just stop?
BTW, it's not urgent. I'm just playing around with ideas to create vases and similar simple geometric shapes without using a slicer to generate the gcode. Just messing around to see how far I can push the limits of speed and see how pressure advance would behave by using true arcs instead of simulated (segmented) curves.
-
The second thing I'm not sure about. I was trying to do a full circle so sent G1 X150 Y150 F3600 then G3 X150 Y150 I-50 J-50 F3600 and as I half expected, the print head didn't move as the start and end points were the same. Interestingly just a slight change is all that s needed to do a full circle so doing G3 X150.0001 Y150 I-50 J-50 F3600 works (i.e adding 0.0001 to the finishing X value). The question is, should G2 and G3 be forced (in firmware) to do a full circle if the start and end points are the same or is that a dangerous thing to do?
On older CNC controls the arcs had to be broken into quarters (90 degrees max per segment) so 4 moves to complete a circle. More modern controls will handle 1/2 circles (180 degrees max). Typically CAM software will break up arcs into 2 or 4 segments automatically so you don't have to modify tool path geometry. In the program line the center of the circle is called out based on the start point of the circle with "I and J".
So to cut a 10.0 arc 90 degrees the line would read G03 X10.0 Y0.0 I0.0 J-10.0. This tells the control that the center of the arc is 10.0 below the start point (J-10.0). Many controls also just an R value to call out the radius size and if the radius is going the wrong direction then you invert the R value by making it a minus value.
-
Is there any kind of standard in the CNC/CAM world? I guess the main purpose of introducing G2 and G3 into the Duet firmware would be so that the Duet boards could be used for CNC machines as well as 3D printers. So David would want his implementation to be as close to a "standard" CNC format as possible. IMO the use of true arcs in 3D printing is a long way off because it's hard to implement with slicers and stl files which is what we all tend to use. So it's probably best to do it right for CNC machining. It's only crazy people like me who want to experiment by by-passing the stl/slicer route.
-
The standard as far as in my experience (32 years) has been to break up arcs into 2 or 4 segments. Not in the actual model or geometry but with the software that post processes the tool path. Personally I have my Mastercam set to 90 Degree max arc segments. It would still make a huge difference on how fast the printer processor can process paths if there were only arc segments instead of tiny short movements around each radius encountered.
Most Cam systems also use what is called tool path filtering so when running a 3D type tool path , it takes anything like spline type segments and converts them into G2/G3 moves. So having arcs in an stl file wouldn't be necessary. This greatly reduces the program length and allows the machine control to process the path much quicker. You set a "tolerance" of how far the new arc path must stay to the actual path. Typically .001" is plenty close enough and still reduces the program size significantly
.
When the control can't keep up with the moves it creates brief pauses. This causes an opposite effect of a tiny dent because the tool is sitting still while spinning at RPM. Of course on 3D prints the effect is a blob or pimple on your part.Anyway, I wish the slicer folks would get on board and add a tool path filtering type function before the GCode is created. That would make for much better looking printed parts.
I have heard of a script that you can run your GCode through and filter it into G2/G3's but haven't had a chance to try it yet.
-
BTW deckingman, I think your printer is amazing and I love the experimental work you do with it. The results you post have helped many of us here.
Thank you for your efforts!
-
BTW deckingman, I think your printer is amazing and I love the experimental work you do with it. The results you post have helped many of us here.
Thank you for your efforts!
Ahhh, thanks man. A bit of positive feedback is always welcome.
