kennetek / gridfinity-rebuilt-openscad

A ground-up rebuild of the stock gridfinity bins in OpenSCAD

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

holes got broken

avxmw opened this issue · comments

commented

I don't know when it happened, but a quick look found me revision b2104fb to be working as expected while current and a few revisions before fail.

I'm relying heavily on x.5 / y.5 boxes, but at least for them holes are no longer generated no matter if "style corners" is true or false.

Comparison screenshots, working on the left, current on the right.

gf-bug-1
Same settings, left gives me holes, right doesn't - I want/need left behaviour.

gf-bug-2
Playing around with div base values, only the shown setting gives holes at all, but the base looks/works differently.

commented

Well, I did not know that anything would be generated when using decimals in the grid parameters. You are only able to fill in natural numbers in the UI. I don't think we support the use case of very odd grid parameters. If you want different grid sizes you can use the length parameter.

You created bins with a grid of 21mm which has magnet holes for a baseplate with a grid of 42mm. This should be incompatible.

My advise would be to change the usage of this repo. I don't know if you tried to fill in 0.6 or 0.8 for gridx. It generates the most peculiar bins. If we are going to support non natural numbers for the grid, we should support everything. The code is not up for that task at all. I think you are lucky to be able to even generate a usable bin with these settings.

You are welcome to keep using b2104fb for your needs.

I noticed another issue wile looking at this #106. Which should be fixed. If you are lucky this would also fix the issue you are encountering.

commented

Only tried .5 units so far since I think that is reasonably easy to fill the grid with and staying flexible. I prefer odd-size boxes over wasted space.

I'll keep a copy of that revision, thankfully I already rendered a full set of filled in boxes at least so that is safe :D

I'll try to figure out how to pull that PR locally and give it a shot tomorrow.

commented

Regarding #107 it gives me holes on 21mm boxes. However the holes slightly overlap and are thus not usable with the common 6mm magnets. I don't know where the d_hole_from_side=8 is originating from, but changing it to 7 makes this use case work for me.

Maybe instead of the options of 'holes in corners' or 'none' there should be other options available like 'single hole in center with configurable size'.

commented

I think it is a step in the right direction for you. I based the d_hole_from_side=8 on the original design for 42mm bins. Maybe It should be calculated relative to the grid length. However, you will always end up with bins that are too small where holes will overlap.

commented

I'd say anything smaller than 21mm is highly unlikely to make sense, maaaybe 14mm if going for 1/3 2/3 boxes. With boxes that small only a small amount of weight would fit anyhow, so a center magnet of configurable size would probably be enough.

As for larger boxes, maybe options like "corners only", "every corners+center", "every x increment of $length" could be helpful. In the end the question is how much complexity should be taken care of?