in that BETA version (that means a test version, right?!) the IJ arc formats were experimental. it was discovered that they work fine for complete circles, but make a complete mess when the circle gets edited because the partial segments at the ends have incorrect co-ordinates.

so in the 1.1e RELEASE version, I went back to the R format arc segments.
The current version 1.2a retains the R format arcs, because they always work. This is not going to change, because the way Sketchup stores the arcs after editing breaks the IJ format.

Internally, Sketchup stores a circle as a bunch of straight segments with the added attributes of 'this is an arc' and 'radius'.
If you do not edit the circle or partial circle, these attributes stay set, and when Sketchucam generates the Gcode it outputs G02 and G03 arc segments.
However, some editing operations, and always the 'explode' operation, removes the 'this is an arc' attribute and SketchUcam has to consider it a line segment and cut each segment as a straight line.

As BobAd said, if you use more segments in an arc than the default 24 you can barely see the straight line segments. Try 48 or 96 and see for yourself (do not go much higher, it does not add precision and takes much longer to draw and cut) . You can set the default in the preferences so every new arc will have the desired number of segments.

BTW 1.2b will fix the problem that polygons get cut as circles unless they are exploded.

 

Claus, please watch this video

in the video I draw 2 circles, explode the second one, add inside cut lines and generate Gcode.
in the Gcode viewer you can see that the first circle (on the left) is made of arc segments, while the circle I exploded is cut as line segments.
They are both drawn and cut at the default 24 segments per circle. For small circles this is hardly noticeable, but as the circle gets bigger the flat edges get bigger too.

Then I start a new circle and set the segments to 96 before drawing it, watch the edit box at bottom right carefully. you have to set the number of segments before drawing the circle, that is, type the number and press enter. I use multiples of 24 because that ensures that there is always a vertex at 0, 90, 180 and 270 degrees around the circle, makes adding intersecting lines easier.

Please note that 1.1e-beta generated arc segments or line segments for exactly the same situations, that has not changed at all. if a line is an arc segment in Sketchup, the Gcode will have a G02 or G03 move and changing back from IJ format to R format has not changed that in any way.

 

Where at swarfer? I've looked everywhere to be able to save my default arc and circle segments and don't see any options for this.
My preference that works great for me is 50 on the circle and 25 on arcs.

 

well now, my memory tells me I set it somewhere, thought it was in preferences, but now I cannot find it anywhere, and cannot find a web reference to it anywhere either. sorry. <-:

however, look up the help on arc segments, some interesting stuff on setting it as '10s' or '10c', for example...

btw setting as 24 or a multiple of that ensures that there is always an intersection at the 90 degrees points around the circle. 25 will mean there is a flat edge 90 degrees from the start point, which may introduce very small errors in lines drawn from that point.

 

You know I always see that and it never really bothered me but knowing all I had to do was put 48 instead, tells me I will be doing that now.
Thanks.

 

if you change the number of segments in a circle you will need to delete and recreate the inside/outside cut lines.

 

i think you are looking at backlash in the machine. do you see similar marks at the start and stop points on straight lines?

G61 and G64 are complimentary and are not supported by all controllers, while on controllers that do support them, they may also support additional options (the P tolerance factor).

G61 is absolute stop mode, this causes a stop at all programmed end points

G64 is smooth motion mode, where the controller will try to maintain feed speed through programmed end points.
This means it won't stop, but it may cut the corner and be less accurate. good controllers like LinuxCNC support an additional parameter like this
G64 P0.5 (assuming metric mode)
where the P0.5 tells it to stay within 0.5mm of the programmed path.
by increasing the P value you can get some serious speed through corners at the cost of accuracy, so much cost that a programmed triangle will cut as a wobbly circle.

These codes are also modal. After setting it, the controller will remember it until the next power cycle.
This means you can turn stop mode off in SketchUcam using the Tools|Phlatboyz|Options|Features menu (we don't use MyConstants.rb any more, the Options menu has replaced it), and then add G64 to your startup block for the controller. Now every time your controller boots it will be in G64 mode, if that is what you want. Don't forget to set the tolerance P value so that you know what you are getting in terms of accuracy.

 

I added the options menu a couple of versions back, pretty sure I made much of it in the release notes (-:
it is also mentioned in the SketchUcam help, hit the big blue question mark in the toolbar

LinuxCNC is designed around the parallel port or the very expensive embedded servo drivers. While there are some USB drivers that are
supposed to work with it, the software end is still very new as far as I can tell, and of course there is very little manufacturer buy-in.
My problem with the USB stuff is that a lot of work went into making LinuxCNC's path planner and stepping engine very very good, why then go around it and give the task to a 'not as good' USB controller? <-:
(not to imply that all the USB controllers are bad, they are just not as mature and of course do not use processors that are anywhere near as powerful as the one in a PC. That said, I am impressed by some of them, like the TinyG with its constant jerk acceleration, and I have been messing with an Arduino with GRBL and while I favour LinuxCNC, I will use GRBL for something for sure, it is pretty good.)

End result is that if you have a PC with a parallel port and a stepper hardware driver that takes step and direction signals (like a Gecko 540 and most of the other Gecko drives) then LinuxCNC will work perfectly. I have never found setup to be difficult, but then, I did read the manual. (-:

lovely machine! I cannot find any USB drivers on the Gecko site, they all appear to be either step and direction or RS485. what did I miss?