Hi,

Great convertor it's so close to perfect for what I need. Wondering if there is a setting that I can choose to rather than outline a shape in SVG > GCode but to infill/pocket.

I'm hoping so and I just haven't configured it properly. Please can you review and advise if this is possible with SvgToGcode Repositiory.

Images attached, outline is from this repo - filled in tool path the other convertor which I can't use.
SVG is the source.

Other Convertor

This repo convertor

Thank you so much
Chris

Certain svg throw this error:

AttributeError: 'NoneType' object has no attribute 'isnumeric'

Is there some specification required for the input svg?
My svg(path only) was created with potrace.

I'm trying to use svg-to-gcode to generate Gcode for a 3D printer that doubles as a plotter. The resulting Gcode does not work when previewed in Cura (the print head doesn't move). The problem appears to be the space between the axis and the position in the G1 commands.

G1 X 62.978162 Y 79.032154;

If the space is removed from all G1 lines so they look like this, everything works as expected:

G1 X62.978162 Y79.032154;

The Marlin firmware Gcode reference does not show spaces. I think Gcode.linear_move() should not include the spaces in G1 command or provide an option to leave them out if they are needed by other types of machines.

gcode_issue.zip

Thanks

I'm using git master of svgtogcode and j-tech with a laser driven by grbl.

I've activated Dwell Time.

This adds G4 P statements into my gcode

These statements are however added AFTER the laser did it's cut.
When cutting things like cardboard, it be very useful if the dwell time is here:

1. laser powered off (m5)
2. laser is moved to next position (g1)
3. laser is turned on (m3)
4. dwell time (G4 P)
5. laser is moving for a cut (g1)

right now step 4 is done before step 1.

I'm not sure, if my use-case is different, or if this is a bug.

The readme hints at a TOLERANCES['approximation'] variable to tweak the output detail of the gcode.
It doesn't seem to work, I'm getting the exact same output no matter the setting.
My test SVG is about A4 in size (mm), and I'm getting multiple steps per mm of travel.

Thanks in advance

From svg:

I got:

It's perfect, make absolutly sens, love it! But would be nice to have option to get a flatten lines when curse are closed and filled.
Or is it title bit out of scope?

I'm not seeing it, but given the first letter of SVG, can the output be scaled? I assume that would happen in the interpreter. Or would that be in the compiler? Or maybe the geometry.

Use cases:

• "I want the output to be half the size"
• "I want to make sure the output fits on X surface"

PROBLEM

When using SVG to GCODE the generated GCODE assumes that ending on the exact position as the cut started on will finish the cut perfectly.

However, when using this to drive less accurate lasers or blades, the cut will not finish - rather, a tiny piece of material is left uncut.

Example

Cutting a box generates (pseudocode)

MOVE 0,0
START CUT
MOVE 0,1
MOVE 1,1
MOVE 1,0
MOVE 0,0

SOLUTION

Add a tiny (configurable?) overshoot at the end - similar to starting a second pass, but only for a tiny cut (approx. 1mm or even less).

I had a look at the code briefly and it may belong to append_curves in compiler?

Fixed example

Cutting a box should generate (pseudocode)

MOVE 0.0, 0.0
START CUT
MOVE 0.0, 1.0
MOVE 1.0, 1.0
MOVE 1.0, 0.0
MOVE 0.0, 0.0
MOVE 0.0, 0.1 # Overshoot cut

The Compiler class' init method allows setting of a unit, and it raises an error if the provided unit is not allowed.
However, the unit then never gets used and thus the corresponding G-codes G20 or G21 never appear in the output.

(feature request) The rotate transform in SVG can take a centre point as well as the angle of rotation. It would be good to add support for that.

(feature request) At present the viewBox attribute of the svg elements is ignored, which can result in things ending up the wrong size.

(feature request) Support for circles and polygons would be nice

While running the tests for #12 (Yay test code!) the new viewBox support was producing slightly different gcode for the hiking.svg test file.

Digging into it a bit I found that it was because the SVG height and width attributes were being truncated - I was getting a height of 791.716 for example, rather than the full 791.71631 in the SVG file. The viewBox code ended up scaling things a tiny bit, which threw the test code off.

The problem seems to be with the lines like this:
canvas_height = float(height_str) if height_str.isnumeric() else float(height_str[:-2])

Seems that isnumeric() returns False for strings containing decimals, and the code assumes they've got a mm or px, etc. at the end and chops off the last two characters - in the case of hiking.svg that's the last two decimal places of the number.