Open bug report

swx_inspect_bodies reports massKg ~1000x too small

Michael · 8d ago
bugconfirmedpriority-high

Summary

swx_inspect_bodies reports massKg about 1000× too small. For the same part, swx_mass_properties gives the correct mass.

What I ran

A single-body part with material ABS set via swx_run_script {"op":"set_material","name":"ABS"}, then both read-back verbs on the same document, with no changes in between.

swx_inspect_bodies (excerpt):

"bodies":[{"areaMm2":3776.754,"bbox":{"maxMm":[15.9,1.7,7.9],"minMm":[-15.9,-9.6,-7.9]},"centerOfMassMm":[0.0,-3.407,-0.0],"faceCount":39,"isSolid":true,"massKg":2.0733615208256247e-6,"name":"Boss-Extrude19","sizeMm":{"x":31.8,"y":11.3,"z":15.8},"visible":true,"volumeMm3":2073.362}],"bodyCount":1

swx_mass_properties (excerpt):

"density": 1020.0,
"massKg": 0.0021148287512421367,
"volumeM3": 2.0733615208256243e-6

Expected vs actual

  • Expected: massKg ≈ 0.002115 (2073.362 mm³ × 1020 kg/m³).
  • Actual: massKg = 2.0733615e-6.

The reported value equals the body's volume in m³ (volumeM3 above) times 1.0. Two likely causes:

  • a density read in g/cm³ (or a fallback of 1.0) applied to a volume in m³; or
  • the material's density being ignored.

The same thing happened before any material was set: a 4823.424 mm³ block reported massKg 4.823424e-6.

I created the part with swx_new_document {"type":"part"}; the reply showed scratchFile: true and a path under ...\adom-solidworks-bridge\exports\scratch\. When I then called swx_run_script with that same path, the reply said "bridgeCreatedDocument": false and warned that the document was not bridge-created. The script still ran. I'd expect true for a document the bridge just made.

Environment

  • solidworks-bridge 0.9.26
  • Adom Bridge 2.1.168
  • SOLIDWORKS: COM reports 29.5.1; registry lists SOLIDWORKS 2021
  • Windows 11 Pro 10.0.26200

4 Replies

Drew Owens · 6d ago

Thanks Michael. Both findings were real, both are fixed, and both fixes are measured on real SOLIDWORKS (2026), not just in our tests. The current release is 0.10.8.

massKg in swx_inspect_bodies. The per-body mass call takes a density argument, and the bridge passed 0. Each body's density now comes from that body's own mass and volume, and the reply carries densityKgM3 and densitySource next to massKg; if the density can't be read, massKg is null, never volume x 1. Measured live on your brick with ABS: 1020 kg/m^3 and 0.0021148 kg, the same as your swx_mass_properties number.

bridgeCreatedDocument: false on the bridge's own part. swx_run_script compared titles instead of paths. It now uses the same path-based ownership test as every other verb; measured live, a part made with swx_new_document and scripted by path reports true. While auditing this we fixed two more title-only checks, plus a script that failed part-way leaving its new part open and owned by nobody.

SOLIDWORKS 2021. We checked every SOLIDWORKS API call the bridge makes against the version that introduced it: nothing needs anything newer than 2017, so the bridge now declares 2021 and later as supported (docs/COMPATIBILITY.md lists each call with its help-page link). We can only run 2026 ourselves, so 2021 is the one thing still unmeasured. If you're willing, with SOLIDWORKS open, run:

swx_selftest {"level":"write"}

It builds 31 small test parts in the bridge's own scratch folder, measures each one (volume, size, bodies, colour, mass) against values computed independently, closes everything it made, and returns one JSON. On 2026 (0.10.8) it reports 43 passed, 0 failed, in under five minutes, and it leaves SOLIDWORKS with nothing open. Paste your result here and we'll fix whatever 2021 shows. To pick up the release now: refresh_bridges {"name":"solidworks"}.

Drew

Michael · 6d ago

Thanks Drew. Here are the 2021 results on 0.10.9: SOLIDWORKS 2021, COM 29.5.1, Windows 11 Pro 10.0.26200, Adom Bridge 2.1.168.

Both fixes confirmed on 2021

  • massKg: swx_inspect_bodies now gives 0.0021148 kg for the ABS brick, with densityKgM3: 1020 and densitySource: "bodyMassProperty".
  • bridgeCreatedDocument: it's true for a script run into the bridge's own part, and the self-test's check for it passed.

swx_selftest {"level":"write"}: 44 passed, 6 failed (380 s)

The full reply is attached. I removed memory.largestHolders / topImages / topProcesses (other apps on my machine) and the duplicate output string. Everything else is unchanged.

All 6 failures have one cause: the scratch part is targeted by a title that includes the extension. Each one is document_not_open:

no open document is titled 'Part14-1792088642002.SLDPRT'

On this machine, SOLIDWORKS reports that document's title as Part14-1792088642002, with no extension; swx_docs lists it that way. The affected checks are:

  • swx_design_info
  • swx_get_parameters
  • swx_set_parameter
  • swx_export_step
  • swx_save
  • swx_close_doc

None of those six were actually exercised on 2021.

Windows has "Hide extensions for known file types" on here (HideFileExt = 1). As far as I know, SOLIDWORKS' document title follows that setting, so this probably isn't specific to 2021. I suspect 2026 with extensions hidden would show the same failures.

The same mismatch was visible in 0.9.26. swx_new_document returned "title": "Part1-1791829659000.SLDPRT", while swx_run_script on the same part reported doc.title: "Part1-1791829659000".

Side effect: because swx_close_doc missed it, the self-test left its scratch part open and dirty. Closing it by path worked, so path targeting is fine.

One more thing (might be ab-core rather than the bridge)

My first swx_selftest call through adom-bridge-cli (direct API, no responseMode) ended at durationMs: 122097. That's the 120 s default, even though the refreshed bridge.json declares "selftest": 1500. That run created its first scratch part and went no further; nothing was recorded in the ledger after that. Running it again with responseMode: "stream" completed normally in 440 s.

After the timeout, the CLI reported "status": "busy" with "Cannot reach relay server (port 8766)". That was misleading, since the direct API on 24680 was up the whole time. If that half belongs on adom/adom-bridge, let me know and I'll move it.

swx-selftest-sw2021.json

Drew Owens · 1d ago

Thank you, Michael. That is the first SOLIDWORKS 2021 measurement anyone has made, and it settles the version question.

The six failures are one bug, and you diagnosed it exactly. The self-test addressed its scratch part by a title with .SLDPRT; with extensions hidden, SOLIDWORKS reports the title without it. Fixed in 0.10.10 (current release 0.11.4, published today): titles match regardless of extension everywhere the bridge matches by title, the bridge addresses its own documents by path, swx_new_document reports the title as SOLIDWORKS shows it, and a self-test that cannot close something says so (documentsLeftOpen) instead of leaving a dirty part. We reproduced your condition on our 2026 machine with "Hide extensions for known file types" on: all six verbs resolve the part by bare title, by title with .SLDPRT, and by path. Today, on the published bytes, swx_selftest {"level":"write"} came back 43 passed, 0 failed, 1 skipped (the active-document read row, which only runs when something is left open), with those six verbs green and T23 and the brick in the rows.

The 120 s cut-off is Adom Bridge, not the bridge: its direct-API path ignores the verb's declared 1500 s budget and then misreports "Cannot reach relay server". Filed as adom/adom-bridge#244 with your description. Until it's fixed, use responseMode: "stream" or "job" for anything long; the self-test's hint now says so.

Your 2021 results are on the page (docs/LIVE-RESULTS.md; the compatibility table shows 2021 as tested), credited to you. If you have a minute after refresh_bridges {"name":"solidworks"} (0.11.4): swx_selftest {"level":"write"} with responseMode: "stream" should come back with 0 failed on your machine, and then I'll close both.

Drew

Michael · 1h ago

Thanks Drew. On 0.11.4, SOLIDWORKS 2021 (29.5.1), swx_selftest {"level":"write"} via responseMode: "stream":

43 passed, 0 failed, 1 skipped (172 s), the same as your 2026 run. The skip is the active-document read row; nothing was open.

  • All six verbs from before pass: swx_design_info, swx_get_parameters, swx_set_parameter, swx_export_step, swx_save, swx_close_doc. This machine still has "Hide extensions for known file types" on.
  • T23 and the brick (T24) pass.
  • 12 documents were created and none were left open.

The full reply is attached. As last time, I removed memory.largestHolders / topImages / topProcesses and the duplicate output.

Fine to close both from my side. Thanks for the quick turnaround.

swx-selftest-sw2021-0.11.4.json

Log in to reply.