Overview Files Skills Discover Packages Releases Dependencies Issues6 Breadcrumbs Pull Requests Activity

Install?

Adom Desktop bridge for Altium Designer: file-based symbol/footprint/IntLib authoring with LCSC/JLCPCB part numbers, Gerber/BOM/CPL batch output, and an in-process .NET extension adding parameterized headless verbs - STEP export with hole and copper options, and KiCad import with no wizard.

adom-wiki pkg install barrett-land/adom-desktop-altium-bridge

Latest: v0.0.55, published 2026-08-12

Download for your machine · v0.0.55?

Release 0.0.55

Downloadv0.0.55 · 315 B · 78 downloads Download for Windowsv0.0.55 · 44 KB · 1 download

Contents

Install
What it can do
Headless STEP export (via the extension)
What it can't
Architecture
Develop

README

markdown

adom-desktop-altium-bridge

SUPERSEDED (2026-08-30): this functionality now lives in adom/altium-bridge — the master Altium bridge + skillpack, maintained by the adom org. Bridge runtime: adom-bridge bridge_install {\"manifestUrl\":\"https://wiki.adom.inc/api/v1/pages/altium-bridge/files/adom-bridge-altium-manifest.json\"} — 81 verbs, resident-agent lane, full parity with this bridge plus surfaces/DRC/OutJob/boards. This page stays up for existing installs but receives no further updates.

Drive Altium Designer on a Windows desktop from a container — build and edit file-based libraries, and generate batch outputs from an OutJob.

Altium ships no headless mode and no CLI. This bridge forwards work into the running GUI as DelphiScript via X2.EXE, exposed as ordinary Adom Desktop verbs.

Install

adom-wiki pkg install barrett-land/adom-desktop-altium-bridge   # the skill, in the container
adom-desktop bridge_install '{"manifestUrl":"https://wiki.adom.inc/download/barrett-land/adom-desktop-altium-bridge/0.0.55/altium-bridge-manifest.json"}'
adom-desktop --ai-thread "<your thread>" altium_ping '{}'

What it can do

Area	Verbs
Host-side (no Altium round-trip)	`altium_ping` `altium_detect` `altium_script_state`
Inspect	`altium_addin_ping` `altium_list_docs` `altium_list_symbols` `altium_read_symbol` `altium_read_params`
Author	`altium_build_symbol` `altium_build_footprint` `altium_add_body` `altium_create_resistor` `altium_create_and_attach` `altium_install_library`
Clone / copy	`altium_clone_symbol` `altium_copy_sch_component` `altium_copy_footprint` `altium_import_part`
Edit	`altium_add_component` `altium_set_visibility` `altium_set_text_style` `altium_rename_component` `altium_rename_footprint` `altium_remove_component`
Package	`altium_compile_intlib` `altium_extract_intlib` `altium_cleanup_libs` `altium_close_doc`
Batch output	`altium_export_step` `altium_run_outjob`
Extension	`altium_install_extension` (installs the in-process .NET server)

Headless STEP export (via the extension)

Altium registers no parameterized processes, so from outside you only get parameterless, dialog-driven commands. This package ships a small in-process .NET extension that fixes that:

adom-desktop --ai-thread "<thread>" altium_install_extension '{}'   # Altium must be CLOSED
# start Altium, then:
X2.exe -RAdomBridge:ExportStep(Req=C:\Users\Public\AdomAltium\exportstep_req.txt)

The request file carries PcbDoc, Out, and options — Holes=All for real drilled geometry (mounting holes become actual holes, not pad artwork), Copper=All to bake 3D copper into the STEP, Models=Step|Extruded|Both.

🔴 Altium's -R parser splits on whitespace, so a path with a space is truncated and the leftover tokens are opened as files. Never put data on the command line — that is why parameters go in a request file at a space-free path.

⚠️ Installing or updating the extension requires Altium closed (it holds the DLL open), and a failed load takes Altium down at startup. Put extension/REMOVE-AdomBridge.cmd on the Desktop first: it is a self-contained one-click rollback.

What it can't

The library verbs act on .SchLib / .PcbLib / .IntLib only — no design documents. There is no placement, routing, netlist editing, DRC or ERC. To read a .PcbDoc, .PcbLib or .SchLib without Altium at all, use the native Rust crates (altium-pcbdoc, altium-pcblib, altium-schlib) — no Windows, no GUI, far faster.

Calls are serialized; overlapping ones make Altium raise a modal that blocks everything until dismissed.

Architecture

container:  adom-desktop altium_<verb>
    ↓ Adom Desktop relay
Windows:    server.py on :8801              host-side verbs answer here
    ↓ C:\Users\Public\AdomAltium\{request.txt,response.json}
Altium:     X2.EXE -RScriptingSystem:RunScript(AdomAltium>Run)

One X2.EXE forward per command. DelphiScript cannot host a resident callback server, so this is the ceiling — the way to go fast is fewer, fatter commands (altium_import_part imports a whole part in a single forward).

Develop

Source is in bridge-src/. Three files each declare what exists — bridge.json (verbs[]), server.py (COMMAND_HANDLERS) and AdomAltium.pas (Dispatch) — and they have drifted apart before, shipping verbs the script could not run. check_wiring.py proves they agree and runs as a build gate.

./bridge-src/deploy.sh 0.0.38                      # wiring check + tests + build
./bridge-src/deploy.sh 0.0.38 --publish            # + push the page repo
./bridge-src/deploy.sh 0.0.38 --publish --install  # + reinstall onto the desktop

Publishing goes through adom-wiki repo push (the git layer), never pkg publish, which would overwrite page files from the tarball.

To iterate on the DelphiScript, drop an edited AdomAltium.pas into C:\Users\Public\AdomAltium\ and call verbs normally — a newer script there wins and is left alone. altium_script_state shows which copy is live. Fold it back into bridge-src/addin/AdomAltium/ before publishing.

See SKILL.md for the full verb reference and the OutJob caveats.