gridfinity-openscad
Interpretive guidance for generating OpenSCAD code for Gridfinity desktop/drawer organizers. Provides pattern selection frameworks, dimensional constraints, and stacking system integration specific to the Gridfinity ecosystem. Use when generating OpenSCAD files for Gridfinity bins, baseplates, or accessories.
What this skill does
# Gridfinity OpenSCAD Code Generation
Generates OpenSCAD code for desktop and drawer storage items compatible with Gridfinity (42mm grid, 7mm height units).
## Required Reading Before Generating Code
**Official specifications:**
- **Gridfinity Spec**: https://gridfinity.xyz/specification/ - Official specification (fetch for current details)
- **GitHub Spec**: https://github.com/gridfinity-unofficial/specification - Community-maintained spec
**Pattern references** (read as needed):
- ./common_items/\*.md - Full OpenSCAD modules for each pattern
## Core Understanding (Critical Architecture)
### What Makes Gridfinity Different From Generic 3D Modeling
**Grid constraint**: All bins align to 42mm × 42mm grid. This affects:
- Bin base dimensions: multiples of 42mm (42, 84, 126, 168mm)
- Actual bin size: 41.5mm per grid unit (0.5mm total tolerance)
- Height units: multiples of 7mm (7, 14, 21, 28mm, etc.)
- Tolerance: 0.25mm per side for proper fit
**Baseplate socket system**: Bins don't sit flat on surface. They:
1. Have base profile that matches Z-shaped socket in baseplate
2. Lock into position but can be reconfigured
3. Require specific base geometry (see ./common_items/basic_bin.md)
**Stacking system**: Bins can stack on top of each other:
- Optional 4.4mm stacking lip at top
- Lip must align with base socket profile
- Height = (N × 7mm) + optional 4.4mm lip
**Critical parameter relationships**:
```openscad
// Core Gridfinity dimensions (NEVER change these)
grid_size = 42; // Base grid unit
bin_size = 41.5; // Actual bin dimension (0.5mm tolerance)
height_unit = 7; // Vertical unit
corner_radius = 3.75; // Filleted corners
stacking_lip = 4.4; // Optional lip height
// User parameters
grid_x = 2; // Grid units wide (2 = 84mm)
grid_y = 3; // Grid units deep (3 = 126mm)
height_u = 4; // Height units (4u = 28mm)
// Calculated dimensions
bin_width = bin_size * grid_x; // 83mm (not 84mm!)
bin_depth = bin_size * grid_y; // 124.5mm (not 126mm!)
bin_height = height_unit * height_u; // 28mm
```
**Why this matters**: User requests "2×3×4 bin" but must understand that means 83mm × 124.5mm × 28mm actual size, not 84mm × 126mm × 28mm.
### Cross-System Compatibility (Critical Insight)
**Gridfinity and OpenGrid share 84mm alignment**:
- 2 × Gridfinity (42mm) = 84mm
- 3 × OpenGrid (28mm) = 84mm
- This enables hybrid wall/desktop systems
**Design implication**: When creating combo systems, use 84mm as common denominator for alignment across both standards.
## Pattern Selection Framework (Decision Layer)
### When User Requests Gridfinity Storage
Use this decision tree to select pattern:
| User wants to store | Primary pattern | Alternative | Read module |
| -------------------------------------- | ----------------------------------- | ------------------------------ | ------------------------- |
| Generic desktop organization | Basic Bin | Divided Bin (if categories) | basic_bin.md |
| Sorted small parts (resistors, screws) | Divider Bin | Multiple basic bins | divider_bin.md |
| Maximum drawer space efficiency | Basic Bin (exact drawer dimensions) | Lite Bin (vase mode) | basic_bin.md, lite_bin.md |
| Rapid printing / minimal filament | Lite Bin | Basic Bin (if strength needed) | lite_bin.md |
| Custom baseplate for drawer/desk | Baseplate | N/A | baseplate.md |
### When Pattern Is Unclear
**Ask these questions:**
1. **Environment**: Desktop (stability matters) or drawer (fit matters)?
2. **Item type**: Similar items (basic bin) or mixed categories (dividers)?
3. **Print time priority**: Need it fast (lite bin) or strong (basic bin)?
4. **Customization**: Standard sizes or specific drawer dimensions?
**Default**: When unclear, use Basic Bin - most versatile, user can refine.
## Code Generation Best Practices
### Parameter Organization
**Always declare these parameters** at top of file:
```openscad
// Grid dimensions (what user specifies)
grid_x = 2; // Grid units wide (1 unit = 42mm)
grid_y = 3; // Grid units deep
height_u = 4; // Height units (1u = 7mm)
// Gridfinity constants (NEVER change)
grid_size = 42; // Standard grid spacing
bin_size = 41.5; // Actual bin size (0.5mm tolerance)
height_unit = 7; // Height increment
corner_radius = 3.75; // Fillet radius
// Structural parameters (print quality)
wall_thickness = 2.0; // 1.6-2.4mm typical for bins
base_thickness = 2.0; // First layer above base profile
// Optional features
include_stacking_lip = true; // Add 4.4mm lip for stacking
include_magnets = false; // Add magnet holes (6mm × 2mm)
include_label = false; // Add label recess
```
**Why this order**: User dimensions first (grid units), then ecosystem constants, then structural parameters, then optional features.
### Base Profile Integration Pattern
**Every bin needs proper base profile**. Standard integration:
```openscad
module gridfinity_base_profile() {
// Z-shaped profile that locks into baseplate
// See ./common_items/basic_bin.md for complete module
// First ~5mm of bin height is dedicated to base
}
union() {
// Base profile (required)
gridfinity_base_profile();
// Bin body above base
translate([0, 0, 5]) // Start above base profile
bin_body();
// Optional stacking lip at top
if (include_stacking_lip) {
translate([0, 0, bin_height])
stacking_lip();
}
}
```
**Common mistake**: Ignoring base profile and creating flat-bottom bin. Won't lock into baseplate.
### Grid Unit Reasoning
**When user says "I need a bin for X"**:
1. **Estimate grid dimensions** for their items:
- Small parts (screws, resistors): 1×1 or 2×1 (42mm or 84mm)
- Tools (pliers, cutters): 2×2 or 3×2 (84mm × 84mm or 126mm × 84mm)
- Desk supplies (tape, scissors): 2×3 or 3×3 (84mm × 126mm or 126mm × 126mm)
2. **Calculate actual bin dimensions**:
```openscad
actual_width = bin_size * grid_x; // 41.5mm per unit
actual_depth = bin_size * grid_y;
actual_height = height_unit * height_u;
```
3. **Calculate usable interior**:
```openscad
interior_width = actual_width - wall_thickness*2;
interior_depth = actual_depth - wall_thickness*2;
interior_height = actual_height - base_thickness; // Minus base profile
// First height unit loses ~5mm to base profile
// So 4u (28mm) bin has ~23mm usable height
```
4. **Inform user of actual dimensions**:
- "2×3×4u bin = 83mm × 124.5mm × 28mm exterior"
- "Usable interior ≈ 79mm × 120.5mm × 23mm (with 2mm walls)"
### Height Unit Considerations
**Critical understanding**: First height unit is partially consumed by base profile.
```openscad
// Height budget for 1u (7mm) bin:
// - ~5mm: Base profile (socket engagement)
// - ~2mm: Usable interior height
// Result: 1u bins are VERY shallow, rarely practical
// Recommended minimum: 3u (21mm)
// - ~5mm: Base profile
// - ~2mm: Base thickness above profile
// - ~14mm: Usable interior
// Result: Enough space for most small items
```
**Guidance**: Suggest minimum 3u for functional bins, unless user specifically needs shallow compartments.
### Pattern Module Integration
**Read the module file, don't reinvent**. Each pattern has complete module in ./common_items/:
```openscad
// DON'T write basic_bin() from scratch
// DO read ./common_items/basic_bin.md and use/adapt the module
// Option 1: Include external file
include <modules/gridfinity_modules.scad>
basic_bin(grid_x=2, grid_y=3, height_u=4);
// Option 2: Paste module directly (user preference)
[paste module from basic_Related in General
modeling-omnistudio-epc-catalog
IncludedSalesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).
relationship-science-coach
IncludedUse this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.
building-sf-integrations
IncludedSalesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).
venue-templates
IncludedAccess comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.
let-fate-decide
IncludedDraws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.
net-ops
IncludedCross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.