Ryan Malloy
ad7022916c
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.
2.6 KiB
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:
-
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.
-
Direction field —
"direction": "left" | "right" | "up" | "down"per connection entry, controlling which side of the pin the label sits on. -
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.