sameer / svg2gcode

Convert vector graphics to g-code for pen plotters, laser engravers, and other CNC machines
https://sameer.github.io/svg2gcode
MIT License
254 stars 49 forks source link

Raspberry Pi logo fails #10

Closed thomaskole closed 3 years ago

thomaskole commented 3 years ago

I love this project, it's so much faster than any Python implementation I've found. It even runs on my Raspberry Pi!

I'm trying to create a simple wooden board holding that same Pi, but I noticed it fails on the logo. The middle berry parts turn into triangle. There's no warnings that I can see.

I've attached the SVG so you can try for yourself.

out.gcode.zip board_attachment.svg.zip image

thomaskole commented 3 years ago

Also, it seems to go over the circles multiple times, even though they are just regular closed paths.

sameer commented 3 years ago

I love this project, it's so much faster than any Python implementation I've found. It even runs on my Raspberry Pi!

Haha that's nice to hear :slightly_smiling_face: I had some plans to compile this to WASM and host it for people who aren't familiar with/don't care for the toolchain setup but haven't gotten around to it yet.

Thanks for bringing these issues to my attention, I'll take a look. My hunch is something related to ellipses

sameer commented 3 years ago

Ok, I think I have a good idea of what's going on. Like with a couple of other similar issues, this ties back to the difference between SVG and GCode coordinate systems and how I've translated things.

sameer commented 3 years ago

I've fixed the first issue with ellipses called out in c1e19741fcc046da3e19c7fb256a748e63e96e53.

image

Two problems and solutions here:

  1. There is a bug in lyon_geom itself: the G1 moves produced by flattening the curve w/ a tolerance do not work at all with a negative sweep angle (see flattening_step). There are no tests for that method either which might explain how it has gone unnoticed for so long.
    • Solution: roundabout method where the ellipse is converted to cubic bezier segments, then flattened into line segments.
  2. There is some ambiguity around large-arc, sweep, and radii when moving between SVG and GCode coordinate systems. I ran into this previously and had a temporary fix of just inverting large-arc which worked at the time for my use case, but not everywhere.
    • Solution: For simplicity's sake just transform all the points that come out of the flattening. Not as performant but can revisit the math around swapping coordinate systems for elliptical arcs later.
sameer commented 3 years ago

As for the second issue, I will check if it's still happening and create a separate tracking issue.

sameer commented 3 years ago

Other issue doesn't seem to manifest. Now that I think about it those were probably also ellipses...so the solution is the same

thomaskole commented 3 years ago

Awesome, I'll check out the fix!

sameer commented 3 years ago

follow up from the dependency issue: that is now resolved by nical/lyon#662 and I've reverted the roundabout solution 1 in e9b23c1