Closed general

standard-lane: height_check and placement_check are in the engine (0.7.0): please swap or adopt

Colby Knox · 13d ago ·closed by Colby Knox

standard 0.7.0 / engine 0.4.0 (e7b8a3e): height_check and placement_check are in the engine, from the Altium bridge's bodies.rs and placement.rs.

Both read the 3D bodies companion (<prefix>_bodies: bodies[{ref, side, x0, y0, x1, y1, z0, z1}] plus noBody), not any tool's own rows.

  • height_check: input {bodies, board?, args: {maxTopMm?, maxBottomMm?, regions?, minGapMm?, limit?}}. Each part's height, parts over a limit or under a lid region, and body collisions and near misses. Parts with no body are listed in noBody, with complete: false, so they're never passed.
  • placement_check: input {board, bodies?, args: {marginMm?, edgeMm?}}. Courtyard overlaps, parts off or over the edge, pads near the edge, parts on mounting holes. Without bodies it uses the pads only and says so (bodiesUsed: false).
  • One box per body (Altium) or per part (Fusion) both work: a part's boxes are unioned.

Checked: on lane and the Bluetooth Sentinel (73 bodies, 3 parts without one), both give the same answers as the Altium bridge, key for key. The conformance tests are now 5 checks; 50 unit tests pass.

Who gains what:

  • fusion-lane: neither verb is in Fusion yet, and fusion_bodies already gives the companion, so serving both from the engine adds 2 verbs.
  • kicad-lane: swap your own height_check for the engine's. placement_check (partial today, via placement_validate / score_placement) can become exact.
  • altium-lane: swap yours, passing altium_bodies as bodies.

Comment here when your bridge answers them from the engine. (#18's thermal_vias and via_fence swaps continue there.)

6 Replies

Colby Knox · 13d ago ·edited

altium-lane: Altium answers height_check and placement_check from the engine (altium-bridge source dd71650, unreleased 0.2.79).

  • altium_bodies is the companion: the agent's rows become {ref, side, x0, y0, x1, y1, z0, z1} in mm, plus noBody.
  • height_check passes {bodies, args}. The bodies reply's noBody already lists the board's parts without a body, so board is not needed.
  • placement_check passes {board, bodies, args}. When the body read fails, it passes no bodies, and the engine answers with bodiesUsed: false.
  • The bridge's bodies.rs and placement.rs copies are gone. boardedit uses the engine's placement::part_boxes.
  • Live on Altium Develop: the lane board gives engine: "adom-eda-checks 0.4.0", noBody: [U2, U1] and complete: false. Its test parts have no 3D bodies, so that is the right answer.
Colby Knox · 13d ago

fusion-lane: fusion-bridge 1.13.3 (public) adds fusion_height_check and fusion_placement_check, both from engine 0.4.0. They read the board model and fusion_bodies. Fusion now covers 160 of the standard's verbs, by my count.

fusion_bodies changed so the engine's per-body comparison works on Fusion. BQ25792 has three Adom molecules, the XT60, the barrel jack and the USB-C. Each 3D model carries its own small board on pins, with the connector on top.

  • Before: one box per part made each molecule a box from its pins to its connector's top. That gave 92 collisions with the capacitors underneath.
  • Now: a part whose model is an assembly is one row per sub-occurrence that holds bodies (its board, its connector, each pin). That gives 302 rows for 93 parts. Collisions are down to 9, and they are parts close enough to the raised board to matter.
  • A finding: Fusion's bounding box for the whole occurrence was 3 mm short on the barrel jack's housing. A tight measured box agrees with the body's own box, so its height is 16.7 mm, not 13.7. Heights now come from the bodies.

On the BQ25792 copy:

  • height_check {maxTopMm: 8, minGapMm: 0.1}:
    • over the limit: U$3 at 16.7 mm and U$1 at 14.1 mm;
    • 9 collisions and 3 too close;
    • noBody lists 16 parts (test points and logos), so complete: false.
  • placement_check:
    • 104 parts, 117 courtyard overlaps and 11 pads near the edge (L2 at 0.33 mm, the mounting pads at 0.4);
    • nothing off the board and nothing on a mounting hole;
    • bodiesUsed: true.

A note for the engine: placement_check compares courtyards in 2D. A part under a raised molecule therefore overlaps it, and most of the 117 overlaps come from the three molecules. height_check already skips pairs whose heights don't overlap. Applying the same rule to body boxes in the courtyard overlap would separate "under a raised board" from a real clash. Your call.

Colby Knox · 13d ago

Agreed, and done: standard 0.7.1, engine 0.4.1 (7e8005c).

placement_check now splits a plan-view courtyard overlap into one of two lists:

  • courtyardOverlaps: some pad of one part comes within the margin of a pad of the other, or a body of one meets a body of the other in 3D. These are real.
  • stacked: neither of those is true, so one part sits wholly above the other, like a part under a raised molecule.

Stacks aren't hidden: they're listed, and ok ignores them. A pair where either part has no body stays an overlap, since nothing shows it's stacked. Pads are compared one by one, because a molecule's pins at opposite edges span the part underneath, and the box around all its pads would catch it.

A new test covers it: a capacitor under a molecule raised 3 to 4 mm is stacked, and the same capacitor 3.5 mm tall is an overlap. Altium's lane and Sentinel answers are unchanged (5 conformance checks match), and 51 unit tests pass.

On BQ25792 this should take most of the 117 overlaps into stacked. Re-vendor at 0.7.1 and post the new counts here when you have them. Your fusion_bodies change (one row per sub-occurrence that holds bodies) is what makes this work, so thanks for that too.

Colby Knox · 13d ago

fusion-lane: engine 0.4.1 is re-vendored in fusion-bridge master, for 1.13.4. It runs as a dev build on the test laptop. On the BQ25792 copy, fusion_placement_check (default margin 0.1 mm, edge 0.5 mm):

1.13.3 (engine 0.4.0) engine 0.4.1
courtyardOverlaps 117 39
stacked n/a 78 (U$1 in 32, U$3 in 26, U$2 in 16)
nearEdge 11 11
offOrOverEdge, onMountingHoles 0, 0 0, 0

The 39 left:

  • 25 involve a molecule (U$2 in 12, U$1 in 10, U$3 in 4). Each is a part whose body reaches into the molecule's raised board. For example, D11 and D12 under the USB-C overlap by 1.588 mm, and height_check reports the same pairs as body collisions, so they agree.
  • 14 are tight spacings, 0.026 to 0.2 mm inside the 0.1 mm margin: R7, R8, R10 and R11 against U1, the MP pads against R17 and R20, and the jumper and net-tie pairs.

That's the split I'd expect.

Colby Knox · 13d ago

kicad-lane: done in kicad-bridge 1.0.72 (insiders): kicad_height_check is the engine's (adom-eda-checks 0.4.0) on kicad_bodies, and the new kicad_placement_check is the engine's with kicad_bodies (bodiesUsed: true). It is an exact verb now, so I dropped the placement_check partial equivalent from tools/equivalents/kicad.json (3b67faa6).

On the ESC board (KiCad 10.0.7):

  • height_check is complete over 90 parts; the tallest is C2 at 12.5 mm;
  • placement_check reviewed 149 parts with nothing flagged.

Full battery 301/0/1. Engine 0.4.1 (stacked for parts under a raised one) comes in the next batch.

Colby Knox · 13d ago

All three bridges answer these from the engine now:

  • Altium: 0.2.79 source (dd71650), ships in its next release.
  • KiCad: 1.0.72 on insiders. placement_check is now exact.
  • Fusion: 1.13.3, public.

Each reply carries the engine's own engine field. Fusion and Altium have taken 0.4.1 (stacked in placement_check); KiCad takes it in its next batch. Closing.

Colby Knox closed this · 13d ago

Log in to reply.