Problems with small arcs G2/G3

I'm using repetier for my laser-cutter and generation the gcode with inkscape. In general, it's working perfectly but I have sometimes problems.
Sometimes, when there are small arcs in the data, the laser-head moves down to Y=0 with laser on, cutting all through, then moves back to the position it should be, and continues with its normal work.
In the photo you can see an example of it. In the "8" are really small arcs, which somehow can't be handled by firmware. he problem occures roughly, when the radius of arcs are smaller than 0.5mm.

Another example, sorry for the blurry photo from a late-night troubleshooting:

In this case it seems not to be tiny arcs but straight lines. In detail it's a tiny arc followed by a straigt line, which is then cut at y=0.

Any ideas, how to solve this?


  • Do you have a small example where it always happens for testing. Might be a rounding problem with small numbers leading to wrong coordinates.
  • One example I had the last week, interesting, that there are no arcs...
    It failed somewhere between line 17-22. There are those super short lines at the corners, that seem to fail.
    It's a part from If i disable the burn-correction, those short lines disappear and so does the error. But I have no idea, why those short lines could fail.

    M3 S255
    G0 F5000
    G0 X208.2648 Y247.9524
    G1 F600.000000
    G1 X214.2648 Y247.9524
    G1 X214.2648 Y177.9524
    G1 X208.2648 Y177.9524
    G1 X208.2648 Y247.9524
    G0 F5000
    G0 X210.088 Y272.5103
    G1 F600.000000
    G1 X210.088 Y276.5103
    G1 X210.06 Y276.5804
    G1 X209.9865 Y276.6119
    G0 F5000
    G0 X209.9865 Y276.6119
    G1 F600.000000
    G1 X201.9865 Y276.6119
    G0 F5000
    G0 X201.9865 Y276.6119
    G1 F600.000000
    G1 X201.9164 Y276.5839F600.000000
    G1 X201.8849 Y276.5103
    G0 F5000
    G0 X201.8849 Y276.5103
    G1 F600.000000
    G1 X201.8849 Y272.5103
    G1 X201.9129 Y272.5804
    G1 X201.9865 Y272.6119
    G0 F5000
    G0 X201.9865 Y272.6119
    G1 F600.000000
    G1 X193.9865 Y272.6119
    G1 X194.0565 Y272.5839
    G1 X194.088 Y272.5103
    G0 F5000
    G0 X194.088 Y272.5103
    G1 F600.000000
    G1 X194.088 Y276.5103
    G1 X194.06 Y276.5804
    G1 X193.9865 Y276.6119
    G0 F5000
    G0 X193.9865 Y276.6119
    G1 F600.000000
    G1 X185.9865 Y276.6119
    G0 F5000
    G0 X185.9865 Y276.6119
    G1 F600.000000
    G1 X185.9164 Y276.5839F600.000000
    G1 X185.8849 Y276.5103
    G0 F5000
    G0 X185.8849 Y276.5103
    G1 F600.000000
    G1 X185.8849 Y272.5103
    G1 X185.9129 Y272.5804
    G1 X185.9865 Y272.6119
    G0 F5000
    G0 X185.9865 Y272.6119
    G1 F600.000000
    G1 X177.9865 Y272.6119
    G1 X178.0565 Y272.5839
    G1 X178.088 Y272.5103
    G0 F5000
    G0 X178.088 Y272.5103
    G1 F600.000000
    G1 X178.088 Y276.5103
    G1 X178.06 Y276.5804
    G1 X177.9865 Y276.6119
    G0 F5000
    G0 X177.9865 Y276.6119
    G1 F600.000000
    G1 X169.9865 Y276.6119
    G0 F5000
    G0 X169.9865 Y276.6119
    G1 F600.000000
    G1 X169.9164 Y276.5839F600.000000
    G1 X169.8849 Y276.5103
    G0 F5000
    G0 X169.8849 Y276.5103
    G1 F600.000000
  • edited April 2019

    seems that lines cause Trouble :

    G1 X185.9164 Y276.5839F600.000000

    you need a space between y coord and F

    should look like:

    G1 X185.9164 Y276.5839 F600.000000

    the code you posted has several lines like that.

    another point could be the warmup Setting of laser,  whats the Setting for that in configuration.h?

  • That missing space between the values makes sense. I haven't had a look at the repetier code, but by assuming a line parser would like to see a space after a number. sscanf or similar expecting a number would be ok with something like "276.5839", but would return a zero for "276.5839F600.000000" because of the F (and maybe the second dot).

    I will test that and give feedback.

    The warmup setting is set to zero, so that shouldn cause a problem.
  • I just used an online C compiler for testing, so I used the original float parseFloatValue(char *s) from gcode.h with the line from above, but that does not lead to a zero value. 
    The code I tested:

    I can't test it with the original arduino compiler at the moment. I will try different gcodes the next time I work with the lasercutter
  • It mainly depends on strtod and according to docs it should not be a problem. However without spaces a E would be treated as exponent and become a problem. At least according to official implementation, how arduino works might be different, so easiest would be to test code with spaces.

    What I also wonder is where are the G2/G3 arcs causing the problem in the sample? Or does the error not happen at arcs but normal lines?

    This code is also strange
    G1 X185.8849 Y276.5103
    G0 F5000
    G0 X185.8849 Y276.5103
    That is a zero move, but should get ignored as position does not change. Hope to get some time for testing soon as well.
  • I thought it were arcs, because I especially saw the problem when I used the burn correction in the box generator like the first image shows the rounded corners due to the 0.1mm burn correction, which leeds to an arc of 0.1mm radius in my case
    I generate the gcode with the repetier inkscape plugin, but on small arcs it approximates it with two short lines (second image)

  • Ok, printed it 2 times. Once from server and one time from sd card. No y glitches visible. Only thing is my printer has no laser. But same moves, so moves in general are no problem. If you do not go to laser mode, does it still happen with the gcode?
  • I tried another project and had the same problem with cutting all through to y0, and the just changed the lines with missing spaces to lines with spaces, e.g.
    G1 X133.8962 Y282.8003F600.000000

    G1 X133.8962 Y282.8003 F600.000000

    and it works just fine.

    Here are both files, if you want to try them. I run them an Mega2560, Repetier 1.x from your firmware generator tool and a raspberry3 with repetier pro.

    I'm generating the gcode with repetier inkscape plugin, which generates those lines with missing whitespace just in cases, where it approximates small arcs with lines. Just in those places the feedrate is set in one line with coordinates. In other areas of the generated gcode the feedrate is just set without (like G1/G0 F600). I will have a closer look inside that.
  • Hello,
    I have exactly the same issue with the repetier inkscape plugin : it generates lines without space before the «F400» parameter.
    I observed that it happens always at the begining of a new track, when the first move command is G1.
    For example in this case it’s ok :
    G1 F400.000000
    G2 X98.304 Y44.1663 I0.4988 J1.0124   --> here it is OK
    G2 X98.473 Y45.4451 I1.8898 J0.4009
    G2 X98.722 Y45.8109 I1.568 J-0.7999
    G1 X98.8454 Y45.8665
    G1 X98.9745 Y45.8381

    But hereafter, I have this line without space before the «Fxxx» and it fails (same effect as Domingo) :
    G1 F400.000000
    G1 X97.3341 Y41.2336F400.000000   --> here I have this Fxxx without space before
    G2 X97.3002 Y43.0723 I49.8283 J1.8387
    G3 X97.1716 Y44.8718 I-12.646 J-0.

    Does someone know if this issue has been solved?
    Thanks in advance for your help.

    Best regards

  • I had a look inside the Inkscape extension and modified it. 
    Now it works ;o)
    The issue happens only when the previous gcode is a G00 and the current move is a small radius (Domingo is right with his analysis).
    Then the code adds a feedrate instruction after the G01, but without space before...
    I believe that the best way is to remove completely this feedrate instruction, as it is not usefull since it is treated before in all cases with the addition of a G1 + feed instruction alone when necessary.

    It is around lines 2670 in the "generate_gcode" function :
            elif s[1] == 'arc':
                    r = [(s[2][0]-s[0][0]), (s[2][1]-s[0][1])]
                    # RP change to G1 ; xxx G4 P50 for laser on
                    if lg=="G00": g += "G1 " + feed + "\n"
                    if (r[0]**2 + r[1]**2)>.1:
                        r1, r2 = (P(s[0])-P(s[2])), (P(si[0])-P(s[2]))
                        if abs(r1.mag()-r2.mag()) < 0.001 :
                            g += ("G2" if s[3]<0 else "G3") + c(si[0]+[ None, (s[2][0]-s[0][0]),(s[2][1]-s[0][1])  ]) + "\n"
                            r = (r1.mag()+r2.mag())/2
                            g += ("G2" if s[3]<0 else "G3") + c(si[0]) + " R%f" % (r) + "\n"
                        lg = 'G02'
                        g += "G1" +c(si[0])+"\n" #JSA20200430 removed the +feed before "\n" (not necessary)
                        lg = 'G01'

    I have a new file for this extension, but don’t know how to post it, if necessary...
    Anyway the modification is easy to do.

    I am not a python expert, so any comment, change or suggestion will be appreciated.

    Hope it helps.
    Kind regards

Sign In or Register to comment.