Closed AlexCPU closed 1 year ago
Looks like the kerf calculations are off as well, the picture shows a kerf of 5, even though the kerf is set to 10
Thanks for reporting - will look into this. I need to put some test case together to capture these kind of errors, Hoe did you find the error ?
I've been fiddling around as I'd like to change the fingers to be symmetrical (i.e. start_up=1 has one more tab than start_up=0), and to support a tabsize attribute (so that thin flat boxes can have one tab on the short edge, and many on the long edge).
The easiest way I've found to make sure that you've got your kerf code correct is to set it really high and watch if everything breaks (which it did).
I've got a fix that works for the above example now, just need to check it out against all the other functions that use it.
Think I got it. Attached PR should do it. Also found that the bumps weren't compensated for kerf, so sometimes ended up inside the tabs.
Thanks for the report and the pull.
First and last cubes in a row of fingers calculate position/size incorrectly for kerf.
Taking an extreme example generating fingers along a 100 edge, with kerf set at 10 highlights the issue where the first and last gaps and blocks are too big, last block even overhangs the edge of the shape.