kennetek / gridfinity-rebuilt-openscad

A ground-up rebuild of the stock gridfinity bins in OpenSCAD
Other
1.14k stars 164 forks source link

fix dynamic hole location on grid length #107

Closed Ruudjhuu closed 1 year ago

Ruudjhuu commented 1 year ago

fixes #95, fixes #106

DJDDDM commented 1 year ago

I guess, your changes can solve the problem. But I feel there is a better way. First of all, we need to think about how close we want to stay at the original specifications: https://gridfinity.xyz/specification/ I would say, that the length of 42 is an integral part to gridfinity and everything that not has length 42 is not gridfinity by definition of gridfinity being defined in the link above. Same with magnets. The standard defines magnets to be 6x2 mm. However, since magnet manufacteurers wont supply us with what they say, but change the dimensions slightly, it would be nice to create an offset parameter for hole_size and hole_height to let them be a few μm smaller or bigger depending on the magnets (and your print settings) you have for this part. So use offsets instead of absolute values for fitting magnets. Then about the length. If we stay with an option to change the length, I would argue, that it should be a simple scaling factor. With the d_hole_from_side you are creating more ways to differ from the standard then necessary. We probably need to figure out, what we want to scale (z, walls, height, lip...) but I would say that for example a minifinity bin (length = 42/2) can be created by simply resizing the standard gridfinity bin (length = 42) (at least in xy). The baseplate would then need to be changed, so that the minifinity fits into it. I want to avoid, that people create two different minifinity standards just because they randomly/arbitrarily choose different ways to scale down. If you want, I can approve this, as it fixes the problem. But given the above text, I would assume you would want to work on this ticket before release.

Ruudjhuu commented 1 year ago

Indeed, good question: how far do we want to deviate. Personally I don't want to deviate at all, I like standards.

I am not a fan that 42 is in the customizer file as this value can break or make compatibility with everything. My feeling is that this value should belong in the constants file. If anyone wants minifinity. They can addapt the constants file and all items they generate with other customizer files will be compatible with their custom defined gridfinity "standard".

I understand your point regarding magnet holes. If the magnet does not really fit, a tolerance should be changed. If a different magnet is going to be used, again I think the place for this is in the constants file as you redefine the standard. The magnet hole size for tolerance is not in scope of this pr and needs to be a feature request (there are already issues for this) I don't want to scale everything when someone wants a smaller grid. It has a high probability of creating unprintable features. The way I used 'd_hole_from_side' keeps the gridfinity defined standard even when gridsizes are changed and generate the holes inside the grid it belongs to when using smaller grids. It is possible to create a half sized bin and keep using it on a normal baseplate because the magnet location standard is not adapted (same distance from the corner). If the user wants to change this, go to the constants file as you will break compatibility.

The changes I might want to do further in this pr is moving the length 42 to the constants file, but then it will be bigger than just a bug fix and breaks the way some users use it. I am willing to do small sensible changes in a bugfix pr. Let me know what you think.

DJDDDM commented 1 year ago

we think alike. I personally have always moved the "length" variable to the /[hidden]/ section. So lets move "length" and "d_hole_from_side" to the current "constants.scad" file and rename it to "standard.scad" (or similar) to create the unspoken message, that if you want to change something regarding the standard, you should know what you are doing and therefore as a "noob check" we will not supply a customizer file for this, but only the standard.scad (which should be fine enough for everyone advanced enough to change the standard.) We can then create a new "constants.scad" to save "real" constants like math stuff.