Add generating SVG file for CNC usage

[jeroenrnl]

Generate SVG files, like DXF files for CNC usage.

Mostly just copied the DXF implementations and renamed DXF to SVG.

Not entirely sure if the tests are right, I just found a place where I could add an SVG-generated file and added it there (bom.scad). Also, in scripts/deps.py I changed svf to svg as I assumed this was an existing typo.

[nophead]

There was already the ability to make SVGs corresponding to the dxf() calls but I haven't actually used it myself because I haven't got around to building a laser cutter yet.

With this change it means all the dxf() calls would need to be changed to svg() in the source code. Not really a problem for a private design as one would just code it produce the files for the machines one has access to but a public design might be routed by one user and laser cut by another. On the other hand a single design might use laser cut acrylic parts and routed DiBond parts so this then make sense. So I suppose one could convert one file format to the other if one was making somebody else's design.

I think you have missed changing one in_dxf in the svg() module.

[jeroenrnl]

Yes, the idea that I had was that the one creating the project would choose whether to use dxf or svg. Hadn't thought about the idea of making it somehow configurable for the end user or maybe just generate both always?

I did find an issue where the images aren't always showing up correctly in the readme file. (Somehow some of my SVG's do show up, some of the SVG's it's looking in the dxfs directory. Not sure what is causing this. (This is still the case after adding the in_dxf fix you suggested above).

I will try to fix this and await your thoughts on the DXF vs SVG config.

[jeroenrnl]

I have fixed the issue with the SVG's sometimes not generating. I also found in issue with the colour of the SVG's, I removed the svg_colour variable I previously added and now use dxf_colour. I also rebased to the fixed PCB spelling.

[tpimh]

Maybe this idea can be taken one step further and the G-Code for the router, laser cutter, 3D printer, etc. can be generated from the resulting STLs, DXFs and SVGs? From the Python side it should be extremely simple: just calling one more external command with appropriate parameters. The biggest problem is a unified interface for command-line G-Code generators.

I know PrusaSlicer has a command-line interface, but I am not aware of a laser/mill G-Code generators. The task of converting DXF to G-Code seems trivial, so there should be a lot of implementations. I only used pcb2gcode, but it expects Gerber input, not DXF/SVG.

[nophead]

I use PyCAM for 2D but I it is an interactive GUI program.

I have often thought of adding slicing but it would need some parameters adding to the STL to specify material, infill density, etc, and everybody uses different slicers, so it would need to be super configurable, or a script for each slicer.

[tpimh]

There's a unified slicer interface: Print3r/Prynt3r. It doesn't support all the slicers, but the most popular ones are supported. Don't know how well it works, needs to be tested.

Having a unified slicer config parsed by NopSCADlib makes sense, the parameters for first layer height and layer height might affect the STLs that are generated. Possibly some other parameters? Also, the color can be specified in the same config. The infill density can also be used to calculate the amount of material required to put to BOM (that's a bit trickier than calculating the square of DXF/SVG).

[tpimh]

Just did a small research, and it seems there are two good CAMs with CLI: viaConstructor (DXF and SVG) and DXF Plotter (DXF only).

Do not yet know how would they handle tool change (e.g. if you need to make round holes in sheet material, the DXF would have circles, you would then need to change the tool to a drill, and the G-Code is just the X and Y center of the circle with Z changing down and up again). For laser should work with no problem, so a simple two-axis GRBL with a diode laser would work just fine.

[nophead]

Yes there are lots of CAM tools which is why it is hard to make a general interface. I use Skeinforge to slice most of my parts when I need accurate dimensions.

OpenSCAD never puts circles in DXF files as all the output is polygonal.

[tpimh]

Yes, in this case it would be good to just add some kind of post processing support. Based on configuration, make_all.py can just run custom CAM script for each file (can also work with GUI tools, but will require user input), and then just check that the output file was created.

And from the viewpoint of CAM a true DXF circle or an approximation using polyline should be treated exactly the same: find the diameter (that's the tool that needs to be used), then find the center (that's where this tool needs to be lowered). If these approximations confuse the CAM, I think you already have a script to convert them into true circles, and it can be used as just another step in a post processing script.

[nophead]

What is the advantage of converting to circles and using a drill? I just use the drill() module that creates an outscribed polygon with many sides and mill it with a 2.4mm diameter bit. Then I can make holes any size from 2.5mm upwards that are round enough for any of my uses.

I do have a pneumatic tool changer but have never got around to using it. I plan to use a bigger bit for outlines to get better chip evacuation from a wider cut.

[tpimh]

I don't know what is the actual advantage of using circle over polyline for drilling. All that is needed is simply a dot with X and Y (or POINT in DXF terms, but OpenSCAD doesn't support it either) and a drill bit of the diameter of the hole. But milling works fine if you got the right bit.