Make --offset work with --mill-diameters

[chaotix-]

I think the new feature mill-diameters where you can use different tools is a great idea. I'm just missing the offset feature from before.

Let me elaborate a bit:
Most of the time traces don't need to be very thin. But sometimes you need to route between two pins so you choose a thin trace width in your PCB layout software.

When using the traditional milling method I could just add "offset=0.2mm" (or something to that effect) and pcb2gcode would enlarge all the traces where possible. When the additional offset did not fit it just traced along the center line of the two areas. This works great.

With mill-diameters the tools don't honor any extra spacing (or I am not able to find how to do this). Thin traces are a lot more fragile during the milling process. I think it would be great if the additional safety offset could also be used in this case. So tolerances don't need to be so tight where it is not really necessary.

Yes, I could layout bigger traces on the board in KiCad or any PCB layout software where spacing allows it. But this would a lot of manual work. And as pcb2gcode already has this feature (although in a different milling mode) I think it would be great to enable this for this new milling mode.

[eyal0]

I think that --mill-diameters already does what you're asking for. When you specify multiple milling bits, they get used in the order that they are provided. Each bit is used only if it will fit. For example, if your bit is 3mm and you try to clear out the space between to traces that are just 2mm apart, it won't go there. If the traces are more than 3mm apart and then get closer, it'll mill away the part that is wide enough but still skip the small gap.

The exception is the last bit that you mention. It will separate traces no matter what, even if the bit doesn't fit. It will always do at least one pass of isolation. This is the code that handles it.

So that sounds like it should take care of what you're trying to do. If not, maybe draw or send me an example so that I can understand better?

[chaotix-]

If it is possible to do what I tried to explain, I don't know how.

Here is an example:

With --offset=0,25mm pcb2gcode will mill along the outer edge of the brighter areas. On the one I marked with an arrow it will mill along the right edge. This will result in wider trace than specified in the gerber-file and so it will allow for extra tolerance during milling where this is possible. Further down where the red trace meets the greenish trace this area is smaller as the full extra offset does not fit between those two traces.

When using --milldiameters pcb2gcode does not use this extra offset. It will mill along the left edge of the marked area. So in theory the resulting trace should be exactly the size specified in the gerber file. But this does not allow for tolerances during milling and setup. The spindle might have some run-out, the machine some backlash and the milling bit might get a bit dull with the time and not cut perfect edges. So in practice the resulting trace will probably be a bit smaller than specified.

Also just increasing the global trace width would not work in this case as the widened mint green trace would not fit between the purple and brownish pad in this case. Yes, I could do this selectively in the PCB layout software, but this would be really a major hassle and pcb2gcode already kind of knows how to do this.

I think it would be nice if one could use the advantages of --mill-diameters and also could specify some tolerance with --offset for the production to allow for non-perfect machining.

I hope I articulated more clearly what I mean.

[chaotix-]

Maybe it is clearer with the copper layer after simulating back.ngc of both methods.

With --offset=0.25mm:

With --mill-diameters=1.2mm,0.6mm,0.15mm:

What I would like is to have the traces like in the first picture (as this is more fault tolerant to mill) and the spaces in between removed like in the second picture.

[eyal0]

I think that I understand. You want to use mill-diameters but you'd also like to add a little offset to all traces everywhere. I forgot how offset and mill-diameters work together, I'll have to look into it.

What I will try is to have offset just fatten everything before it starts, and then have all the mill-diameters work like normal. I think that will accomplish what you want. I'll look into it.

If I get it done, do you have a file that you can run with both options and let me know how it worked?

[chaotix-]

Yes. Exactly. Enlarge everything (if possible) and then use the regular mill-diameters calculation.

I will be glad to test the code.

[eyal0]

So here's a question: would doing this have the same effect as just increasing the size of each mill diameter by a little?

[chaotix-]

That war my first instinct to fix work around this on the user side. Just specify larger diameters but use smaller ones for the actual milling. But without any changes this does not seem to be very efficient. Me (and I guess a lot of other people) are using a V-Bit for the smallest mill. Let's say this has a 0,1mm wide tip. Now if you want an offset of 0,2mm you had to specify a 0,5mm diameter. This works fine for a single pass but for larger cleanups this would result in very small --mill-overlap and very inefficient cleaning of larger areas.
But aside from being inefficient I think this would end in the wanted result.

[eyal0]

Looking at the code, I see that right now, mill-diameters replaces offset. If you set both, it's an error. If you set only offset then it's the same as setting a single mill-diameter that is twice the offset.

So I could change it so that it continues to work the same way as previously except in the case when you set both offset and mill-diameters. In that case, it would do the new effect that you would like. How to do it is the question.

The easiest would be to just twice the offset to each mill. Piece of cake. The downside there would be that the mill-diameters when reported in gcode comments wouldn't match the numbers provided. Also, the code assumes that the mill-diameter is what is actually cleared out so there would be gaps where the first mill actually cleared out less than pcb2gcode thinks. We really want the offset to just be some space away from the traces and not actually an assumption of the mill-diameter.

Another option is to just fatten up each trace. I think, however, that might be a bad idea. Here's why:

mill-diameters uses each bit, in order, only in the places where they fit. But the very last one that is specified will be used everywhere, even if it doesn't fit. (Explained here.) That way you get guaranteed isolation.

If we fatten each trace by the offset, it's possible that two traces that weren't touching are now touching, and then the last milling bit won't get in there, even though it should!

So far, here are the things that I'm thinking about:

• Make sure that the mills reported in the gcode comments match those provided.
• Make sure that traces that are close together don't get merged by offset.
• Make sure that the multiple mills correctly clear out an area.

[chaotix-]

I didn't know that you used the mill-diameter trick with offset. That is clever, but not helpful right now. :-) I was hoping --offset would already do the calculation to fatten the traces. Then it would have been easy to implement, I guess.

But don't you already calculate the fattened traces and pay attention to where the offset has to be shrunk down as to not merge with its neighbors? The image in #412 (comment) was calculated by pcb2gcode and displays the enlarged traces.

[eyal0]

pcb2gcode calculates the voronoi region of each trace and milling is confined to that region. So if two traces are too close together, the milling is limited by the voronoi region, which in your image is the faint colored part.

I'm trying to see if I could just increase the milling diameter artificially and then also increasing the milling overlap to compensate. I think that it won't work for multiple passes, however. Say I have a tool diameter of 1mm and no overlap. Two passes will clear out 2mm. Now if I set the mill-diameter to 1.2 and set the overlap to 0.2 and do two passes with a 1mm bit, it will again clear out 2mm but pcb2gcode will think that we cleared out 2.2mm (1.2mm, twice, minus one overlap of 0.2mm). Then when you switch bits, pcb2gcode is going to think that an area that was cleared actually wasn't. pcb2gcode will keep out of that already milled area, even though it wasn't actually milled. That's no good. You'll have little gaps when you use two mills.

So it might be best to apply the offset to the traces and that's it. The offset will be how much to keep away from traces. If it's zero, it'll have no effect. Unlike the milling diameter and the milling overlap, it only affects distance away from the trace, shifting all extra passes paths by a constant. This is as opposed to the milling diameter or overlap, which shift each extra pass by increasing amounts.

I also see a potential bug in the overlap code. The milling overlap is taken into account when using a single mill but when you switch to a different bit, the first pass on it doesn't account for overlap. Hmm! I will try to make a nice example to prove it to myself and then fix it. Shouldn't be too hard.

[chaotix-]

I understand the voronoi region part, but I was not talking about the feint colored part. I have beautifully highlighted the lines I mean in blue.

If you could use those lines as the outlines of the traces to mill no messing around with different diameters and offsets would be necessary.

But I do think that if you change the calculation that the overlap will be honored between changing mills and that the overlap can account for the offset this should work as well. Maybe in this case the offset value should also be automatically added to --isolation-width.

[eyal0]

I think that it should suit you now. Let me know if you need more help with it.

[chaotix-]

Thanks for you work.

It kind of does what it is supposed to do, but I think there are still some issues.

I tested it with a small rotary encoder breakout board.
This is the result with no offet specfied. Everything looks fine:

With offset=0.25mm some pads have really weird angles:

And with offset=0.15mm it even cuts through traces and a pad. I looks like it's not raising the mill sometimes:

I don't know if this is related, but I had some problems compiling. I'm just adding this on the off-chance that it might have something to do with the results:

• I was not able to compile with libgeos-dev installed. (bg_helpers.hpp:210:102: error: request for member ‘get’ in ‘geos_in’, which is of pointer type ‘geos::geom::Geometry*’). So I deinstalled it and it fell back to the geometry calculations with boost.
• "optimise=true" in my millproject file did not work anymore. Changing "true" to "1" made pcb2gcode produce some output, but it was completely messed up, so I changed it to "optimise=0".

[eyal0]

The optimise flag used to be true/false. I changed it to a value so you can choose the amount of optimization, which is roughly how small a segment you care about. The default is 0.0001 so any motion smaller than that might get removed.

Maybe you and I have a different version of libgeos? The Geos website says that their c++ API is in flux so you can't count on it to be stable. The c API claims to be stable. Maybe I'll switch to that instead? If you check the pcb2gcode version, it should show you the Geos version.

Anyway, I don't think that Geos will help you in this case. Geos gave better results for me in cases where boost wasn't just a little wrong but wildly wrong.

I'll try the offset option on more inputs and see how it performs. I didn't treat it very thoroughly.

[eyal0]

For what it's worth, I'm on geos 3.8.1, which I installed from sources. What version are you on?

└──> ../../../pcb2gcode --version
2.1.0
Git commit: v2.1.0-6-gdd1e7b5-dirty
Boost: 106600
Gerbv: 2.7A
Geos: 3.8.1

[eyal0]

I'm not seeing the results that you are seeing. I tried a couple of the examples in the testing directory and they looked accurate. Maybe you could send me an example to try? Please include the command-line that you ran and any millproject files that you have.

For the lines that you see passing through the traces, I can't tell yet if those are due to the offset feature or the new "spikes" feature that I added. See this picture which explains it pretty well. Maybe what you're seeing is a spike that went out of control.

[chaotix-]

Is the geos dependency new? I'm using Debian Buster. I never had any problems compiling and I did not have libgeos++-dev installed, but previous version compiled just fine. But I did have libgeos-dev installed and ./configure found it, but threw an error when compiling about not finding a header file. So I installed libgeos++-dev and got the error that I was quoting above. The libgeos version in Buster is 3.7.1 (for C and as well as C++).

I have attached my used test gerber file and a more or less minimal millproject that produces the same output:
I used the following command: /usr/local/src/pcb2gcode/pcb2gcode --back Rotary-Encoder-Breakout-B_Cu.gbr
(The output is the same if I use a drill and and outline file. This is just the minimal version that produces the output as seen above.)

Rotary-Encoder-Breakout.zip

[eyal0]

Yup, the geos support is new. I adjusted the configure script so that it'll use geos but only if it is available. Otherwise, it doesn't use it. The reason is because the boost geometry buffer command was giving me too much trouble.

buffer is the one where, given a trace, will draw a polygon around it that is bigger. That's how pcb2gcode makes lines for milling that are spaced away from the trace.

For the most part, it works. But it's a complex algorithm and it has to deal with stuff like buffering a shape and now different parts of the shape overlap or disappear. Like if you buffer a horseshoe shape a lot, eventually the hook parts of the shape need to disappear. Mostly boost geometry gets it right. But there are some weird cases where, if the conditions are just right, it'll do something entirely wrong like make a shape with a negative area or a self-intersecting shape or other stuff. This completely messes up pcb2gcode, which is depending on sensible results, so you get like, milling that fills in a trace instead of going around it.

I tried lots of stuff to work around boost geometry's weird behavior, including upgrading and simplifying paths before buffering and buffering just one shape at a time and combining them but nothing worked. So I finally gave up and tried libgeos. libgeos wasn't too hard to use and it just plain worked. So I have it compile only if it actually works.

On my computer, sudo apt-get install libgeos-3.8.1 is available. So maybe that would work for you? However, I don't think that libgeos will solve your problem anyway.

---

Those stray milling lines are definitely the "spikes". If I comment out "add_spikes" in surface_vectorial.cpp line 605 then it works better. I'll have to keep debugging that new feature. It's nice but kind of risky in how it works!

[eyal0]

BTW, you can run ./configure with the option --with-geos=no to disable geos, that way you don't have to uninstall geos. I'll fix it so that it works for older versions of geos in the future.

[eyal0]

I'm also seeing a weird behavior with multiple milling bits. You specified 1.5mm isolation and your first bit is 1.45mm, so I expected that the first bit would do two passes. Instead, the first bit did one pass and then the second bit had to get the rest. In some places, the 1.5mm bit can't fit so that seems fine but at traces around the edge there is basically no limit to how many times you can go around so I expected it to mill that out with the big bit, too. Using the bigger one as much as possible is better because it's going to be stronger and can clear out more per pass, so it's also faster. Better to use it to the limit! and only after that use smaller bits.

Maybe I did a weird calculation on the number of passes, like I did 1.5/1.45 and rounded down instead of up? I'll take a look!

[eyal0]

Oops, nevermind that last bit. The isolation width was 1mm so a single pass was correct. I don't get why the next bit did yet another pass. I'll look into it.

[eyal0]

Give it a shot now, thanks.

[chaotix-]

Just found some time to test this with some boards. Looks really great. Thanks a lot.