coverage: 70.482% (-0.02%) from 70.501%
when pulling 444f68c on thomergil:filter_voronoi_artifacts
into 6185b56 on pcb2gcode:master.

Did you try the --optimise option? It should do the same thing but it uses a more advanced algorithm for carefully removing points to minimize deviation for the original path.

--optimise does not solve the problem. There are still hundreds of "jumps" on the milling path on my sample PCB board. I had Claude Code classify the output of both. See below.

  | Metric         | Upstream (--optimise only) | Modified (--min-path-length=0.1) |
  |----------------|----------------------------|----------------------------------|
  | Total paths    | 820                        | 347                              |
  | Paths < 0.05mm | 473                        | 0                                |
  | Shortest path  | 0.004mm                    | 0.131mm                          |
  | Total milling  | 6340mm                     | 6337mm                           |

Thanks for that research. By jumps, you mean that the CNC will go down, etch a very tiny segment, then come up and do it again? And it's doing lots of these tiny ones?

That is surprising to me because I have used voronoi many times and it has not done that for me. Can you provide test gerberfiles and a millproject file that I can run and look at?

I do not own a CNC, I am examining the output with the bCNC software.

The voronoi algorithm should create continuous lines. Even if they have many segments, the segments should be connected to one another so it should be a continuous path without too much lifting.

If many of the paths join each other at vertices with odd number then the eulerian path optimizer might create many little jumps. But the backtrack optimizer should be able to fix this. The backtrack optimizer is the one that decides that it is better to etch a path twice than to lift and lower. It is controlled by your preference for CNC milling time versus wear on the milling tool.

I am currently on holiday so I can't investigate this right now. In the meantime:

• can you send gerber and millproject files that I can use to recreate your results?
• Please look at the GitHub repo wiki and read about the options there. If there is one there that it solving your problem, it can give me a hint as to a solution.
• I have yesterday submitted an important fix to the eulerian path algorithm. Please update your code to make sure that you have the fix called "new eulerian algorithm". I had a serious bug in that algorithm.
• Use --enable-debug when running configure in order to enable some checks in the code.

I will be able to look at your issue in January. Thanks for your patience.

When I rebase this code on to the latest master branch, I find that it has no affect on any of the integration tests. It could be that this problem was already solved by the fix to the eulerian paths algorithm.

Can you test again after you rebase this code on to master to see if this PR is still necessary?

I don't understand what you are asking me. Which test should/would have caught the hundreds of tiny artifacts? And if it had no effect, are you saying the tests didn't catch those artifacts in the first place?

I'll explain. In the testing for pcb2gcode, there is a test suite called integration_tests. It runs pcb2gcode on dozens of example pcbs. The expected result for each one is stored, too. For example, the expected milling of this board and the gcode for it. Every time a new PR is submitted, everything is tested to see that the expected output is still accurate.

I modified this PR to set (0.1mm to be the default min-path-length) https://github.com/pcb2gcode/pcb2gcode/pull/748/changes#diff-4acdcdfd5e36af7f58b7aa2e006c8619d62a623dc2bb9268a414bd77edf592c2R299 . If you look at the code of this PR, you will see that this is the default. I then ran all the integration tests and some of them fail because, like you noticed, when you set the minimum path length to 0.1mm, some paths are removed. You can see in back.ngc many little paths are removed, which was your goal. Great!

However, your PR is based on code that is 4 weeks ago and that code is known to have a problem. I have since fixed that problem. I tested this PR in the same way on the the latest code. So that you can compare, I have done it in my own filter_voronoi_artifacts branch. If you look at the code change there, you will see it is the same as this one. And also there, I have set the default min-path-length to be 0.1mm. But there, with the code change based on the latest master and not the four-weeks-old one, I see that it has no affect on the integration tests. I no longer see any PCBs that are affected by the min-path-length feature. It seems that are paths are more than 0.1mm already. I think that this is because of the bug that was fixed in master.

So for that reason, I would ask you to please perform the same testing as you did before but this time use your min-path-length feature based on the latest master branch and see if it is having any effect. Because as far as I can tell, there are no PCBs for which min-path-length will have any difference.

If you still find that I'm wrong, though, then please send me a gerber file for which min-path-length is a useful feature so that I can test it, too. Thanks!

Got it! Awesome, thank you @eyal0. Will do.

I still have the problem with today's compiled version of pcb2gcode.

Can you share the Gerber file? I'm curious to see what those small lines are? I worry that removing tiny lines can cause incorrect outputs!