Too fine resolution when creating gcode

LaserWeb information

On the About page, I see that I have:

  • Frontend version: _ 4.0.999
  • Backend version: _4.1.000

My settings are:

  "settings": {
    "__version": "4.0.999",
    "__selectedProfile": "DW",
    "__latestRelease": "2019-11-26T10:45:07Z",
    "showMachine": true,
    "machineWidth": 310,
    "machineHeight": 330,
    "machineBeamDiameter": 0.3,
    "machineBottomLeftX": 0,
    "machineBottomLeftY": -330,
    "machineFeedRange": {
      "XY": {"min": 10, "max": 10000},
      "Z": {"min": 10, "max": 3000},
      "A": {"min": 10, "max": 50000},
      "S": {"min": 0, "max": 30000}
    "machineXYProbeOffset": 0,
    "machineZEnabled": true,
    "machineZMatThickness": 0,
    "machineZToolOffset": 0,
    "machineZStartHeight": "0",
    "machineZProbeOffset": 0,
    "machineAEnabled": false,
    "machineBlowerEnabled": true,
    "machineBlowerGcodeOn": "M8",
    "machineBlowerGcodeOff": "M9",
    "pxPerInch": 96,
    "forcePxPerInch": false,
    "dpiBitmap": 300,
    "toolGridWidth": 310,
    "toolGridHeight": 330,
    "toolGridMinorSpacing": 10,
    "toolGridMajorSpacing": 50,
    "toolSafetyLockDisabled": true,
    "toolCncMode": false,
    "toolImagePosition": "BL",
    "toolUseNumpad": false,
    "toolDisplayCache": false,
    "toolUseGamepad": false,
    "toolCreateEmptyOps": false,
    "toolVideoDevice": null,
    "toolVideoPerspective": {"enabled": false},
    "toolVideoLens": {"a": 1, "b": 1, "F": 1, "scale": 1},
    "toolVideoFov": {"x": 1, "y": 1},
    "toolVideoResolution": "720p(HD)",
    "toolVideoOMR": false,
    "toolVideoOMROffsetX": 0,
    "toolVideoOMROffsetY": 0,
    "toolVideoOMRMarkerSize": 20,
    "toolWebcamUrl": "",
    "toolFeedUnits": "mm/min",
    "toolTestSValue": 1,
    "toolTestDuration": 0,
    "gcodeStart": "G21         ; Set units to mm\nG90         ; Absolute positioning\nM3\n\n\n\n",
    "gcodeEnd": "M5          ; Switch tool offEnd\nG0 Z0 F5000\nG0 Y320X0F15000\n\n",
    "gcodeHoming": "$H",
    "gcodeGenerator": "default",
    "gcodeToolOn": "",
    "gcodeToolOff": "",
    "gcodeLaserIntensity": "S",
    "gcodeLaserIntensitySeparateLine": false,
    "gcodeSMinValue": 0,
    "gcodeSMaxValue": 255,
    "gcodeCheckSizePower": 1,
    "gcodeToolTestPower": 1,
    "gcodeToolTestDuration": 10,
    "gcodeConcurrency": 2,
    "gcodeCurvePrecision": 0.5,
    "comServerVersion": "4.1.000",
    "comServerIP": "",
    "comServerConnect": false,
    "comInterfaces": ["USB", "ESP8266", "Telnet"],
    "comPorts": [
      {"path": "/dev/ttyAMA0"},
        "manufacturer": "Arduino (",
        "serialNumber": "75834303538351404130",
        "pnpId": "usb-Arduino__www.arduino.cc__0043_75834303538351404130-if00",
        "vendorId": "2341",
        "productId": "0043",
        "path": "/dev/ttyACM0"
    "comAccumulatedJobTime": 5568,
    "connectVia": "USB",
    "connectPort": "/dev/ttyACM0",
    "connectBaud": "115200",
    "connectIP": "",
    "jogStepsize": 1,
    "jogFeedXY": 10000,
    "jogFeedZ": 3000,
    "macros": {
      "*GotoXY0": {
        "keybinding": "ctrl+f1",
        "label": "Goto XY zero",
        "gcode": "G0 Z0 F5000\nG0 Y0 X0 F8000\n"
      "390e1e93-9333-41c7-b2ec-1aa62326af7c": {
        "keybinding": "ctrl+f4",
        "label": "Unlock",
        "gcode": "$X"
      "20869cad-f2c3-4481-bbaf-622473fba1df": {
        "keybinding": "",
        "label": "Laser Test",
        "gcode": "M3 S1"
      "bd4f4e53-b16f-40e5-8f83-8c77a99e542f": {
        "keybinding": "",
        "label": "Laser Off",
        "gcode": "M5 S0"
      "b857d0f7-00a8-4409-a7d4-70419e9d564d": {
        "keybinding": "",
        "label": "Z-39",
        "gcode": "G1Z-39F5000\n"
      "3f684c1d-8261-47c8-94b5-fa3ed69bc10f": {
        "keybinding": "",
        "label": "Entnahme",
        "gcode": "M5          ; Switch tool offEnd\nG0 Z0 F5000\nG0 Y330X0F8000\n\n"
      "1b576eb8-4ff1-40f6-8562-6e503fb4eefc": {
        "keybinding": "",
        "label": "Air On",
        "gcode": "M8"
      "90f4aa23-506f-4621-910f-5e5685d6225d": {
        "keybinding": "",
        "label": "Air Off",
        "gcode": "M9"
      "2ae50de2-2258-4fa9-8566-9a7a5a8920bf": {
        "keybinding": "",
        "label": "Go To Max",
        "gcode": "G0 X300Y0Z-40F10000"
    "uiFcDrag": {"x": 1.5632378940087506, "y": 418.3522619328087}

## Problem description

When I convert a simple svg to gcode, I expect a smal gcode file, but instead i get a big file with extremly smal steps between the gcode coordinates.

I'm trying to upload the following files here: svg-file, gcode output from LW and the output from a online svg to gcode tool. [](
*Edit: It is not possible to upload txt or gcode files here?

When I watch this two files in a online gcode viewer []( The diference is obvious. Sometimes the pen almost stops because the steps are so small. Exactly the same thing happens with the real laser.
The file from WL is about 290 KB the one from the online converter about 21 KB.

The online converter has a "Curve interpolation tolerance" setting. I set it to 0.05 mm. In the WL, I also set the "GCODE CURVE LINEARIZATION FACTOR" setting up to 0.5 but did not notice any difference to the standard of 0.01.

What am I doing wrong or what have I overlooked?

## System description

* My machine is a diode laser 
* I have a arduino with grbl
* It has grbl version 1.1 installed
* I connect via Ethernet to RPI and via USB(Serial) to Arduino

* My computer(s) on which I run LaserWeb run(s) Windows 10
The result is the same when I operate the RPI directly via the browser.

bring your SVG file into something like Inkscape and select the design, select Edit Nodes icon on the left side(just below the pointer) and then to to the Path menu and select the Simplify option.

You should see the number of line segments greatly reduced and so should your resulting GCode file when you save the SVG and then bring it back into LaserWeb.

1 Like

Thanks for your help.
I found the option in Inkscape. The gcode created by LW is now 255KB in size. (Previously 293KB). Do I have to do this several times to get a reasonable result? Where do I see the number of segments in Inkscape? And why does it work in the online tool without this change?

You can but you might start seeing some changes in the line segments.

I’ve not looked for the line segment count but can see by the nodes shown if it looks too dense or not.

I don’t follow what this “online tool” you speak of really is. Some CAM software does have a setting for line segment resolution because it used to be all curves were broken down into small line segments. I forget what it’s called… arcs… but there are GCode commands which cover curves instead of doing lots of little straight segments. Your CAM software and your firmware need to support arc( G2 and G3 ) commands.

Sorry, I do not understand that.
The CAM software in this case is LW or not?
This converts the svg file to gcode for me. Where can I tell the LW to use G2/G3.
Exactly that is the current problem that LW divides the arcs into tiny segments.
The online tool at svg2gcode divides it up in exactly the same way but in larger steps.

I don’t know how LaserWeb is setting the segment size for arcs but maybe it’s getting them from your controller if that is a GRBL based firmware. See $11 and $12 settings.

The online tool probably has a default which has larger line segments.

If you wanted to investigate, you could have both output GCode files and then load the gcode into a gcode view and zoom into the same area to see what segmenting is being used.

I would also look to see if one is using arcs( G2 and G3 commands ) and the other isn’t. I don’t know if either tool supports or doesn’t support G2 and G3 commands.

Thanks for your answer. I will test this with the parameters in GRBL.
I have already done the analysis of the two GCODE outputs (Online Tool / LaserWeb). With LW, about 10-15 times more segments are made from the same arc.

using google (laserweb segment option) I found this:

For #4 - this might be related to gcode. the other thing to note is that on curves/circles, Laserweb doesn’t automatically simplify. Some curves and circles are generated from inkscape with many intermediate points on the curve. For me I found that to slow down the machine and it was burning some curves quite bad. One way to fix this is to use the ‘segment’ option (it’s the last option in the layer/gcode menu for the workspace). I often use 0.2-0.5mm to soften up curves or complex artwork.

Thank you again for your time.
They mean the setting in LaserWeb under “Settings/Gcode/GCODE CURVE LINEARIZATION FACTOR” ? I have already increased this value from 0.01 to 2 with no difference in the gcode output.

I’ll take a look at the settings in grbl when I get a chance. I have everything in one box and the interface to the Arduion is not led to the outside.

Attached is a picture and a PDF to show the problem. Maybe someone else can help.

f***, not possible to upload PDF as a new user…
The section in the red circle requires 15 lines of gcode with the online converter und over 200 lines! when with LaserWeb converted.

Too bad, I think LaserWeb is awesome but this problem makes it unusable for me. Why am I the only one having this problem?

There has to be a setting for that and I suspect that LaserWeb is getting that setting from the firmware( a $$ command will return the GRBL settings ). The online tool should have a setting for that too but because it’s not connected to your machine, it has to have/use a default.

As for why others aren’t having this problem, if your file is 300kbytes in size and that’s a problem something is wrong with your system since that’s not a very large file at all.

I can’t find any difference in the forum settings between uploading an image and uploading a PDF. It’s not intentional, at least…

When I try to upload a PDF, I get a message that new users are unable to post an attachment.

OK I will try that with the settings in grbl.
Somehow I can’t imagine LW fetching this data from grbl.
Thanks in any case for your help.

Thank you! That helped me find the setting. As long as spammers and trolls don’t make us turn it off again, we can leave that in place.

Apologies for not responding at the time;

There is an option in the job definitions that should help: Segment, you will find it in the job options for all cutting operations.

It defines a minimum ‘segment’ size, it’s chief purpose is to address this issue and stop the generated code from containing small lines (segments) under the size limit.

With 16 bit versions of Grbl it’s not hard for LW to produce code that is too dense for the controller+buffer to process on time, and the machine stutters. This can be very annoying, and wreck cuts (depending on other factors too).

Here is a little example; Look at the segment value (which is the only thing changing):
First is with it set to Zero, so 1:1 ratio of paths in the input vs paths in the gcode.

Note the generated code size is 199.19 kB with 11.5K moves…

Now the same with my default segment size; 0.15mm:

Generated code is now 77 kB, with just 4.4K moves. Actual output quality is unaffected (on my large format machine), 0.15mm is barely wider than my beam.


It works!
This was exactly the setting I was looking for.
I’m sorry I didn’t think of that on my own.
Have tried everything but this setting ‘Segment’ not.
Many thanks to you and to everyone for your help!
Now I’m enjoying my self-made cutter again. :grinning:
Best regards, Dave


@Json_Parser if your firmware supports G2 and G3 commands(arcs) then there are web sites and tools which will convert all those segments for the curves into just a few arc commands. Older firmware couldn’t support arc’s so curves were broken into short straight segments.