| ID: | 3545 |
| From: | ge...@igor2.repo.hu |
| Date: | Sun, 24 Nov 2019 05:12:07 +0100 (CET) |
| Subject: | [pcb-rnd] g-code export reconstruction |
| replies: | 3546 from ge...@igor2.repo.hu , 3547 from Bdale Garbee <bd...@gag.com> |
Hi all, I am going to remove the old g-code export plugin and write a new one. You are affected if you have a milling machine or router and you create your PCBs using those machines (mechanically removing copper). If you don't, it is safe to stop reading here. However, if you do or plan to use g-code, please step up now. Please note: such features in pcb-rnd are user-pull, which means if there's no user interest, no testing, nobody is really milling boards and nobody is willing to test the new code, it will quickly stop growing. So if you are interested in g-code and milling your boards, please join the effort with testing and feedback. 1. What's wrong with the old plugin? - it converts pcb-rnd's vector data into pixels, rendering a png as a side effect, then uses code borrowed from potrace trying to convert back the result to vectors - it has a lot of hardwired logics in C on how to do the milling - as part of that, it seems to use only one tool diameter, which is good in some cases but may be supobtimla in others, e.g. in the next point - the only one way it seems to work is forming copper islands for the nets by tracing teir contours; this is good for galvanic connections, but bad for insulation - it does not warn the user when copper featres are too close - it just does the wrong thing, causing shorts, silently - (no, it doesn't do arcs or anything clever, it is really just a huge number of line segments) 2. why now? - I've just finished the polygon offset (and self-intersect-cleanup) code, which allows us to do the required contour calculations in vectors, without any pixmap conversion - I've written camv-rnd this summer, which can load and display g-code files, so I finally have a sane viewer - I wanted to get rid of the old code for a logn time: it's large, it does unreasonable things, it depends on too many things and at the end it does the bare minimum coded in a way that doesn't make me want to extend it 3. what's going to change - the new code uses vector calculations, no pixelation involved - the new code is structured differently: instead of one hardwired mechanism, it provides a set of simpler steps, e.g. one that traces contours, another that can remove larger copper areas, there will be one that can "drill" arbitrary sized holes using a mill, etc. These tools will be exposed so it will be possible to export different milling strategies for different boards - there will be support for multiple tools; this does not mean you have to use multiple tools: using a single tool is a subset of being able to use multiple tools. However, even with manual tool change, I bet it is worth using a small tool for the contour tracing and then a large tool for bulk polygon removal and drilling the holes 4. what's NOT going to change (yet?) - at this stage, there won't be arc support on the output: just like the old version, the new version will do line approximation. I know this is bad for your CNC, but this can be fixed only after the poly lib rewrite (this requires arc support in polyogons - even if your board doesn't have polygons) - at the moment I am not aware of any user trying to use the g-code path in practice; that means I have zero feedback and the new plugin will use the old experience plus my thoughts on how things could be done better. In other words, it may be that it won't do some important things better, because I am not yet aware of what those important things are. 5. roadmap - I first remove the old code; for some time (maybe hours, maybe days) we won't have any g-code export in svn HEAD (we are in cleanup phase, so that's fine) - I will add the new g-code export code with about as much capabilities as the old one had; this will take some days and at the end we will have something similar (but not the same) as we had before - depending on user demand and actual testing, I will start extending the toolbox so all the fancy extras would be available gradually Best regards, Igor2
Reply subtree:
3545 [pcb-rnd] g-code export reconstruction from ge...@igor2.repo.hu
3546 Re: [pcb-rnd] g-code export reconstruction (status report) from ge...@igor2.repo.hu
3547 Re: [pcb-rnd] g-code export reconstruction from Bdale Garbee <bd...@gag.com>
3548 Re: [pcb-rnd] g-code export reconstruction from ge...@igor2.repo.hu