the ij format works fine for complete circles, or arcs that have not been split, ie a circle or arc drawn, and then split anywhere except an arc segment intersection.
if they have been split then Sketchup reports incorrect endpoints , the endpoints are not on the circle but rather on the chord that Sketchup *displays*. using IJ for this situation then generates errors in the Gcode controller because the end points do not match the radius, this is a fatal error and processing stops.
therefore, IJ cannot be used for arc output at this time.

what you want to do is to
a) create arcs with more segments, say 48 to a circle (should be a multiple of 4). the bigger the circle the more segments you use so that
the chords do not get so big you can see them in the cuts
b) explode all arcs before creating cut lines
the result is that all the gcode output is straight segments and you will not have any arc strangeness

again I say it 'Marlin needs to be fixed, not SketchUcam' (-:

 

the only way to draw a circle on an XY machine is by using the 'split it into segments' method, same as on your screen, the Windows graphics library just splits it into pixel sized segments so they look smooth. on a thing like Marlin I would split into 'machine resolution' segments, made a lot more complicated if X and Y have different resolutions. then I'd use the larger one.

I have already modified the code to be able to use the IJ format function call, and reinstated the storage of the center point which you need for that. it even gets transformed already! (but commented in one place)

so, in gcodeutil.rb all you need to do is replace calls to arcmove() with calls to arcmoveij() with the correct parameters. around line 1548 you will need to uncomment the tcenter stuff so you have the transformed center point available.

having done that you will need to make sure that in your drawings any circle/arc that you draw and then split on an intersection with a chord gets redrawn, ie delete it and redraw it as one arc from endpoint to endpoint. This will ensure that the first and last segments have the correct co-ordinates that are actually on the radius. OR you can do the math to recalculate them. which may not be necessary at all since I doubt Marlin does any real checking of the arc parameters and will not moan if they do not match up, happily drawing the wrong arc instead (-:

I ditched the IJ routine because the Planet-cnc usb controller and LinuxCNC both (and others I am sure) detect errors in the arc parameters and I believe using R format which 'works everywhere' is a better solution than trying to get everyone to draw arcs correctly as described above so that the code works. and recalculating the end points is more math than I want to do, I am a programmer not a mathematician (-:
(yes I know giving the incorrect end point to the R format arc will result in the 'wrong arc' beign drawn, ie the controller calculates the center point and it will not match the actual drawings center point. However, I challenge you to produce a drawing where this effect can be easily seen in the cut output The goal here is Gcode that 'works everywhere' not super duper accurate Gcode for making spaceship components.)

hmmm, strikes me this will only work this 'simply' if you do not use ramping, since the ramping code would also have to be changed to use IJ format. that is another layer or three of complexity. good luck with that (-:

as to how many segments to use..... do not go too small since your Marlin buffer is limited and will run out and pause the cut while it waits for new lines to be sent. http://forums.reprap.org/read.php?1,169532
pausing the cut will leave a mark. I have tested using 3 segments per arc, so in Sketchup it looks like 3 big flat sides, but the gcode has 3 arc commands which cut a perfect circle and reduces code size a lot.

have fun