feat: new side-hinge box

[gcollic]

Hello,

I needed a box for a project, but with some constraints not met by the existing ones, so I created yet another hinge box.

The hinges doesn't protrude from the box, but the sides needs double walls. When opened, 2 sides are opening, improving access inside the box. An optional latch is included, based on a mechanical switch and a 3D printed button. The latch is one-way: the box can be closed freely (this side of the button is angled, and totally smooth since it's the printing bed surface), but can't be inadvertently opened.

The inside wall corner rounding is useful, but subtle to actually see. It's easier to see with more extreme values such as hinge_radius 30.

I don't know if it's merge ready yet, since:

• I'm really not sure of what name would be clearer, between the multiple hinge boxes
• I reused the AgricolaInsert NoopEdge trick, so I moved it to the common code, but duplication would be fine with me (or another way to do 2 sides in one pass)
• the latch option is not compatible with thickness greater than 3.7mm. In this case, I raise an error, but I'm not sure it's the right way to validate this constraint
• I generate the latch button 3D printing code (based on box wall thickness) inside the generated file, but it could be moved to the documentation instead if prefered
• I don't have the thumbnail unix environment ready, would you mind generating the thumbnail?

Thank you!

[florianfesti]

This is really neat. I polished a few minor blemishes.

Shipping the OpenSCAD "file" as text in the drawing is super cool.

I wonder if the button could also be made completely laser cut - using a long leave spring and two circles. I might try that as soon as this gets merged.

[florianfesti]

I wonder if you can just on the fly modify the button code to fit the thickness. Simply by putting + {t} at the right place.

[gcollic]

I wonder if you can just on the fly modify the button code to fit the thickness. Simply by putting + {t} at the right place.

Well, Indeed it's already the case ^^

[florianfesti]

Well, Indeed it's already the case ^^

Yeah, I only really saw that after commenting. As I understand the 3.7mm is the travel of the key. What about using btn_h = ear_t + plywood_t + min(plywood_t, 3.7)? That way you can always depress the key far enough to open the lid.

In general raising an Exception for such thing is fine. But the Exception to raise is ValueError. This is picked up by the WebUI and displayed properly.

[gcollic]

Yes that's a good idea! Maybe with a warning in the description, if I'm not mistaken in such a case the switch would need to be inserted before adding the walls and wouldn't be removable. Under 3.7mm, you can remove the square to push further the button, and there is then enough room to remove and replace it. Over 3.7mm, the square is useless, so it could be not generated if the cube for the switch is one thickness shorter. Or in contrary we could add a second not-glued square in this case, I think it should make the switch removable.

[florianfesti]

If you limit the switch height to 3.7mm as suggested above you can also always remove the switch after removing the square - at least as far as I understand the geometry from looking at the drawing alone.

If you adjust the generated OpenSCAD code I think we are done here - unless someone suggests a better name.

[gcollic]

I just changed the latches option (in a dedicated commit), as an int to allow for a second one. I found afterward that a second latch on the opposite side would have been more adapted for the box size and content I did.

If you limit the switch height to 3.7mm as suggested above you can also always remove the switch

Yes, you are right. I changed the OpenSCAD code (there were other impacted lines too)

I think we are done here

It looks good to ship for me too🚀

[florianfesti]

OK, added choices to the cherrymx_latches parameter so it is now a drop down with 0, 1, 2.

And a squashed all the commits into one. To me this also looks ready to be merged now.