Hi,
I’ve noticed that there is an extra G1 move being inserted in the Gcode. This causes a slight hesitation in movement and gives a slight divot with plasma. I’m not sure when this start but I’ve noticed it for awhile now. I tried some other post processors but they also seem to insert the G1. Is this a postprocessor problem or something with the way sheetcam is outputing the file?
I will attach support file… I am using version 7.0.13
Thanks!
Jeff Tice
M68 E0 Q20 (Auto DTHC is ON)
X-0.184 Y0.864
X-0.007 Y0.957
G2 X1.470 Y1.534 I3.287 J-6.242
G1 X1.726 Y1.599
X1.727
X1.985 Y1.656
X1.986
G2 X4.486 Y1.911 I2.793 J-14.985
X5.951 Y1.882 I0.480 J-12.742
X6.932 Y1.708 I-0.405 J-5.140
X7.688 Y1.338 I-0.598 J-2.181
G1 X7.689 <------------- This one
G2 X8.013 Y0.951 I-0.777 J-0.981
Y0.937 I-0.013 J-0.007
X7.688 Y0.559 I-1.081 J0.597
G1 Y0.558 <-----------------This one
G2 X6.872 Y0.178 I-1.388 J1.914
X5.951 Y0.024 I-1.371 J5.346
X3.616 Y0.034 I-1.097 J16.262
X2.515 Y0.147 I0.909 J14.236
X-0.007 Y0.932 I0.938 J7.460
G1 X-0.095 Y0.978
G0 X-0.094 Y0.979 (Add tiny extension)
M5
Support.zip (37 KB)
I have not looked at the gcode shapes, but could it be that you have and inside or outside offset set that are affecting arcs (G2 motion) and not centerline so the post processor is stepping to the outside of the arc (or inside) for the next move
try the post processor with no offset.
if this is art work then no offset ((ie it follows the actual centerline of the line and does not offset for the torch kerf) would probably be better.
if you have any mounting holes or an outside frame the just put those on their own layer and apply an offset to them
also if you are using uccnc or linuxcnc you can use the blended motion planner tolerance parameters G64 and you won’t get any hesitation, set this for your plasma kerf width.
http://linuxcnc.org/docs/devel/html/gcode/g-code.html#gcode:g64
This is largely due to the shape you are trying to cut. G-code only understands lines and circular arcs. The curves in your drawing aren’t circular so SheetCam breaks them into a number of of circular arcs that approximate the original curve. The problem is that after offsetting you end up with small joining moves between these arcs. The joining moves are arcs but as they are very small SheetCam converts them to lines.
Edit your post and add this line to function OnInit().
minArcSize = 0.001
This will force these tiny arcs to be output as arcs instead of lines.
That did the trick. Thanks!
Jeff
Edit your post and add this line to function OnInit().
I had tried using G64 P0.010 Q0.010 but it still had a pause which seemed odd to me. Changing minArcSize = 0.001 in the post as Les mentioned seemed to fix the pause.
Thanks!