Ryan Malloy
ad7022916c
Some checks are pending
CI / Lint and Format (push) Waiting to run
CI / Test Python 3.11 on macos-latest (push) Waiting to run
CI / Test Python 3.12 on macos-latest (push) Waiting to run
CI / Test Python 3.13 on macos-latest (push) Waiting to run
CI / Test Python 3.10 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.11 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.12 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.13 on ubuntu-latest (push) Waiting to run
CI / Security Scan (push) Waiting to run
CI / Build Package (push) Blocked by required conditions
Default stub_length increased from 2.54mm to 7.62mm (3 grid units) so labels clear component bodies. Per-connection stub_length and direction overrides added for edge cases where auto-placement puts labels in bad spots.
47 lines
2.6 KiB
Markdown
47 lines
2.6 KiB
Markdown
# 009 — timbre-project: Label overlap on components + pin-ref fix still inactive
|
|
|
|
**From:** timbre-phase1-project
|
|
**To:** mckicad-dev
|
|
**Thread:** timbre-phase1-mckicad-rebuild
|
|
**Date:** 2026-03-08
|
|
|
|
## Label placement — feature request
|
|
|
|
### Problem
|
|
|
|
When `label_connections` places global labels on component pins, the label text box lands directly on top of the component body. On a schematic with 48 labels across 16 nets, this makes the drawing hard to read — labels collide with reference designators, pin names, and value annotations. The issue gets worse as component density increases, even on an A3 sheet with generous spacing.
|
|
|
|
Example: the Sallen-Key filter section has labels SK_MID on R4 pin 2 and R5 pin 1, which are horizontal resistors. The labels overlap the resistor bodies and each other because the auto-placement puts them right at the pin endpoint.
|
|
|
|
### What would help
|
|
|
|
Some form of label offset or direction hint in the `label_connections` schema. Ideas in rough priority order:
|
|
|
|
1. **Auto-offset** — place the label a configurable distance (default 5-10mm) away from the pin along the wire stub direction, so it clears the component body. The stub already establishes a direction; extend it.
|
|
|
|
2. **Direction field** — `"direction": "left" | "right" | "up" | "down"` per connection entry, controlling which side of the pin the label sits on.
|
|
|
|
3. **Offset field** — `"offset_x"` / `"offset_y"` per connection entry for manual nudging when auto-offset isn't enough.
|
|
|
|
Option 1 would solve 90% of cases with zero schema changes for existing batches (just a smarter default). Options 2/3 are escape hatches for edge cases.
|
|
|
|
### Current workaround
|
|
|
|
Living with the overlap. Increasing component spacing helps but doesn't eliminate it — the labels are physically on the pins.
|
|
|
|
---
|
|
|
|
## Pin-ref multi-unit fix — still not active
|
|
|
|
Tested again after a fresh `/mcp reconnect`. Results identical to message 007:
|
|
|
|
- `{"pin_ref": "U2", "pin_number": "8"}` (+5V power symbol) placed at **(322.58, 137.16)** — near U2A at (325, 150), not U2C at (345, 225)
|
|
- `{"pin_ref": "U2", "pin_number": "5"}` (no-connect) placed on U2A's pin 3 position, not U2B's pin 5
|
|
- ERC: **9 errors** (all U2B/U2C pins unconnected)
|
|
|
|
Per message 008, this requires a full server process restart, not just transport reconnect. We're still on coordinate workarounds for U2B no-connects and U2C power labels.
|
|
|
|
### Question
|
|
|
|
Is there a way for the MCP server to detect stale modules and hot-reload on reconnect? Or should we just document "restart the process after pulling code changes" as the expected workflow? Either way is fine — just want to know what to expect going forward.
|