Repository navigation
Conversation
Only `usb_c_receptacle` declared a `mating_face`, so only it was oriented. The five JST side-entry parts declared none, which had two effects. The floorplan gave every JST connector the same `Rotation::Ninety` and put all of them on the left edge whichever edge the source asked for. And `connector_orientation_issues`, which the DRC uses to flag a connector facing into the board, skips any part without a face, so the DRC could not report it. On the irrigation controller three connectors on the bottom edge faced sideways and nothing said so. Declared `mating_face = "bottom"` on `jst_ph_2pin`, `jst_ph_3pin`, `jst_ph_4pin`, `jst_xh_2pin` and `jst_xh_4pin`, read from the footprint outlines: the housing extends toward local +y from the pad row, the same convention the USB-C part uses. The floorplan now sets the rotation of any connector that declares a face from the edge it was asked for, falling back to the nearest edge, and the JST branch honours the requested edge instead of always taking the left. A soft hint is a preference, so a connector can settle away from the edge it asked for. A final pass therefore turns any edge connector to face outward from where it ended up, using the DRC's own test so the two cannot disagree. It leaves a pinned connector alone, and any turn that would overlap a neighbour, because a quarter turn changes the courtyard's extents; the DRC reports both. Measured on the irrigation controller's source, with the faces declared: three misfacing connectors before, none after. One limit. On a very small board with soft hints the placer can crowd a connector enough that the turn is declined; the test uses hard hints for that reason. Pin headers are left out: they are vertical, so their opening is not an edge.
… face `module_divider` uses a JST connector, which now declares which way its plug opens, so the lowered part carries `mating_face: "bottom"` where it carried null. One line, and it is the effect of the change, not a side effect.
CI failed on two of them, and recording the third showed a failure CI had not reached yet, since it stops at the first. parser fixtures: `edge_jst_connectors.synth` is a new design, so the every_positive_design_parses_clean snapshot gains one new file. Nothing existing changes. secure_tracker placement: one line. The JST connector J2 at x = 10 mm on the left edge goes from Ninety to TwoSeventy, which is the change itself: its plug now opens out of the board instead of into it. feather_m4_express placement: the outline is unchanged, 90.57 x 76.16 mm. J2 and J3, the two left-edge JST connectors, go from Ninety to TwoSeventy for the same reason. 17 of the 62 parts also shift, because a rotated connector moves its pad-aware `near` offsets and the greedy search places what follows from there; no part other than the two connectors changes rotation.
The rule that turns a connector to face the board edge only acts on a part that declares a `mating_face`, and only USB-C and the five JST parts did. The two other real edge connectors in the registry did not, so they were still left to whatever rotation they happened to get. `hdmi_a_receptacle` and `micro_usb_b` are `bottom`, read from their footprints the same way the JST parts were, and checked against the one part whose answer is already known: USB-C HRO signal pads at the rear, y = -4.04; housing to y = +4.15 Micro-B Molex signal pads at the rear, y = -1.46; housing to y = +3.64 HDMI Amphenol signal pads at the rear, y = -5.00; housing to y = +5.00 In each the contacts sit at the rear edge and the housing extends forward to where the plug enters, which is local +y. The vertical pin headers are left out on purpose: their opening faces up, not out of an edge. A test now requires every connector part except those headers to declare a face, so the next edge connector cannot be added without one. It fails with the face removed from `micro_usb_b`. No snapshot moves: the IR and placement snapshots are unchanged by these two.
SammyOina
reviewed
Oct 23, 2026
| let clear = placements.iter().all(|other| { | ||
| other.id == turned.id | ||
| || !padded_courtyard_rect(courtyard_lookup, &turned) | ||
| .intersects(&padded_courtyard_rect(courtyard_lookup, other)) |
Collaborator
There was a problem hiding this comment.
[P1] Revalidate board containment and edge clearance before accepting this rotation. This pass runs after placement and checks only courtyard overlap with other components; a quarter-turn near an outline can move the courtyard or copper pads outside the board even though the original placement was legal. Reject the turn unless the rotated geometry remains inside the outline and satisfies the same edge-clearance constraints, and add a regression test for that case.
This was referenced Oct 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
This is a bug fix.
What does this do?
Declares
mating_faceon seven connector parts and turns any connector with one to face outward.Which issue(s) does this PR fix/relate to?
Resolves #281.
Have you included tests for your changes?
Yes. A four-edge orientation test, and one requiring every edge connector to declare a face.
Did you document any new/modified features?
No. Placement behaviour only; no new syntax or diagnostic.
Notes
Pinned connectors are left alone, as is any turn that would overlap a neighbour.