AI Flow

Hi Colby,

Target wiki: adom/adom-aiflow

Versions

• AI Flow 0.2.51
• Fusion Bridge 1.13.67
• Hydrogen on a Windows laptop, WSL Adom-Workspace, Fusion lane

What happened

Thanks again for AI Flow. I ran into a placement issue on a small 4-layer board with parts on both sides.

place land puts bottom-side parts on the top side. A part that sits on the bottom (B.Cu) in AI Flow's board copy, and is moved with place land --moves, ends up on the top side of the live Fusion board. The landing reports readback_mismatch for some parts, but the parts it already moved stay flipped. After that, AI Flow's board copy says bottom and the live board says top for the same parts. There is no AI Flow verb to put a part back on its side or to undo the landing.

Steps to reproduce (generic)

1. Use a Fusion board (linked to its schematic) with some parts on the bottom side.
2. Write a moves file that moves one bottom-side part a little: {"<REF>": {"x": ..., "y": ..., "rotation": 90}}.
3. Run place check --moves <file>. It passes, and the part stays on the bottom in the run's board copy.
4. Run place land --moves <file>.
5. Read the part back from the live board (fusion_board_info): its rotation is R90 (top) instead of MR... (bottom).

Expected vs actual

• Expected: The part keeps its side. A bottom-side part lands on the bottom at the new x, y and rotation, and the live board matches the run's board copy.
• Actual: The part lands on the top side. The run's board copy still says bottom, so the two copies disagree. A "side" key in the moves file is ignored (the moves schema is only x, y, rotation), and there is no set-side or undo-land verb to fix it through AI Flow.

What I think is going on

• fusion_move_parts runs MOVE '<ref>' (x y); ROTATE =R<deg> '<ref>'; for a numeric rotation. An absolute ROTATE =R<deg> drops the M (mirror) flag, so a bottom part is flipped to the top.
• The bridge already accepts an EAGLE rotation string: passing "rotation": "MR<deg>" to fusion_move_parts keeps the part on the bottom, and the readback verifies.
• The bottom-side rotation sense also needs mapping. For the same pad positions, a KiCad bottom rotation of θ matched EAGLE MR(360-θ) in my check (θ = 90 needed MR270; θ = 0 was MR0). Sending MR<θ> puts a polarised part's pads the wrong way round.

Suggested fix

Either of these would solve it:

1. Preserve side on land: when the part is mirrored on the live board, or is on B.Cu in the run's board, send MR<mapped deg> instead of a plain number.
2. Add a side field to the moves schema ("side": "F" | "B"), honoured by place check (flip the footprint in the board copy) and place land (send MR... for B), with the readback checking side too.

It would also help to have a way to undo or repair a land through AI Flow (for example place land --restore from the last good board, or a place set-side). And place land should stop before moving anything when a part's side would change.

No board files, logs or screenshots attached; the steps above are generic.

Thanks!

— Andy Engevold