Skip to content

openGrid: Add customizable cutout, screw caps, rename "Full"#131

Open
mitufy wants to merge 6 commits intoAndyLevesque:mainfrom
mitufy:cutout-screwcap-etc
Open

openGrid: Add customizable cutout, screw caps, rename "Full"#131
mitufy wants to merge 6 commits intoAndyLevesque:mainfrom
mitufy:cutout-screwcap-etc

Conversation

@mitufy
Copy link
Copy Markdown
Contributor

@mitufy mitufy commented Apr 6, 2026

This PR is several updates for openGrid.scad rolled into one.

  • Added support for cutouts. Users can now input coordinate pairs through the customizer, and there's no limit on the position or number of cutouts. I try to preserve the board-edge geometry where possible, and screw holes or connector holes that would interfere are automatically disabled.

  • Added options for screw hole caps. The idea comes from Gavin F, and a stand alone parametric version already exists. By adding this option to the board generator, we can ensure that the cap size matches the screw hole size. The screw head inset would also be adjusted so that there is enough room for the cap even after the screw is installed. I also tweaked the design to make the center of the cap thinner, so it can be removed by pushing it through with a pair of tweezers.

  • Renamed "Full" board to "Standard". With the addition of KYZ's openGrid Heavy board (13.8mm thick), calling the 6.8mm version "Full" becomes confusing. After renaming, board_type now has "Lite", "Standard", "Heavy" as options.

image of a 5x5 opengrid board with cutout coordinates "[1-1,1-2][3-2,4-4]"
render5x5_2

animated demonstration of installing/uninstalling the screw hole cap

0001-0161.mp4

@jhuizingh
Copy link
Copy Markdown
Contributor

Cool!

It took me a while to understand the cutout coordinates system. It seems like you have [{y range}, {x range}] repeated once for each cutout.

Is there a reason for doing y first and then x instead of the standard use of coordinates where x goes first?

Also, one of your dimension ranges has 1-2 and another has 3-2. I personally would expect it to always be smaller-larger. It's great if your code supports either order. I'm wondering if there's a reason that you put them in a different order?

@mitufy
Copy link
Copy Markdown
Contributor Author

mitufy commented Apr 13, 2026

The cutout coordinates actually work like this:
Untitled design
Hope this badly edited image makes sense. I was thinking in "row-col" instead of "x-y". Do you think the latter would be more intuitive for the users?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants