Snapmaker Studio v0.9.0

Snapmaker Studio v0.9.0 — the project that crosses whole

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

Bring a project from another slicer and Studio prepares a U1 copy of it. Until
now that copy quietly lost things: painted colour, the parts an object was built
from, the settings you had set on one object, and — in one path — the print
settings themselves. This release is mostly about the crossing, and everything in
it was established by handing Snapmaker Orca a file, letting Orca save it back,
and reading what Orca wrote.

Your project arrives as the project you made

Painted colour survives

A prepared copy carried painted colour exactly as the source wrote it, and Orca
opened it with nothing painted. Painting is only read when the mesh sits in its
own object file inside the package — so that is where a painted object goes now,
and the colour arrives.

Eight painted facets in, eight out, in the same slots. The encoding did not
change; where it lives did.

An object's parts arrive as parts

A project saying "this half prints in filament 2 and that half in filament 5"
used to arrive as one undifferentiated object, and Studio correctly reported the
second filament as not carried. The copy now splits the object along its real
volume boundaries, so each part crosses with its own filament.

The parts recombine to the source geometry facet for facet, nothing is
duplicated, and a filament in slot 5 is not quietly clamped to four.

A modifier arrives as a modifier

Some volumes in a project are not meant to be printed — they change how the
slicer behaves near them. Studio used to carry the whole object as one mesh, so
those arrived as solid plastic. Worse than the "not carried" it reported.

Each now crosses with the word Orca actually uses for it, over geometry marked as
not-printable. Measured rather than guessed: two cubes that do not touch, sliced,
and the plate footprint read back — 500 mm² when the second is solid, 400 mm² for
every non-printing role. None of them becomes plastic.

Several objects arrive as several objects

A project with more than one object kept its geometry in one place, and painting
is not read from there — so a multi-object painted project lost its colour while
every individual check passed. Every object now crosses as its own object with
its own file, its own place on the plate and its own records.

If any one object cannot be carried, the whole project declines and crosses
verbatim instead. Half a conversion would leave the rest in a shape the target
does not read.

Settings you set on a single object

Studio read per-object settings and reported every one of them as not carried.
Three of them can cross — layer height, infill density and supports — and they do
now, in the target's own vocabulary rather than the source's.

That distinction matters: copying the source's spelling across is writing
nonsense with a straight face. Handing Orca one candidate at a time, with an
invented word as the control, drew the line: those three survive, the source's
own spellings do not. Every value is checked before it is written, because a
value the slicer cannot read does not cost you the setting — it costs you the
object.

A per-object layer height is withheld on a multi-filament plate, because Orca
refuses to slice a plate whose objects disagree about it when a prime tower is
involved. The audit says so rather than writing a project that will not open.

Two fixes you would have noticed

The print settings from your project were reaching the file and not the
slicer. Studio translates five values from a source project — layer height,
first layer, infill density, wall count and brim — so a project sliced at 0.15 mm
with four walls does not arrive at 0.2 mm with two. They were being written but
not declared, and an undeclared value is replaced by the preset on load. The
whole of that promise was correct in the file and invisible in the slicer. It is
declared now.

An unpainted patch on a painted object printed in the wrong filament. It now
prints in its own volume's filament, as it should.

A second materials provider

Studio has read Spoolman for a while to answer "will this job run out of
filament?". It now reads Bambuddy as well.

Settings → Materials provider offers None, Spoolman or Bambuddy. There is no
second page: pick one, give the address of the machine on your network that runs
it, test the connection, map a spool to each slot. Changing provider clears the
address and the mapping, because a spool number only means something to the
provider that issued it.

Everything after that point is identical whichever one you use — the same
sufficiency rules, the same warnings, the same refusals. A short, tracked, recent
weight still blocks a send; a stale one, a figure worked out from a spool's
declared size, and a figure with no date all warn instead; nothing tracking the
spool stays unknown.

Both are read-only. Studio does not create spools and does not decrement anyone's
remaining weight.

Fixed on the way

• A provider address that redirected off your network was followed. A local
  address is not a promise about where the next request goes, and one that
  answered with a redirect to the public internet was being followed. Refused
  now, for every provider, in the one place all of them share. Studio still makes
  no requests to the internet.
• A slot with a stale mapping claimed the printer had looked at it. If a
  mapping pointed at a spool that no longer exists, Studio said "the printer
  reports it empty" — with no printer connected and nothing having looked. It now
  says which of the three it actually means: the printer saw an empty slot, your
  mapping points at a spool that is gone, or nothing can tell.
• Malformed numbers from a provider could become a weight. They stay unknown.
• A modifier off the plate was reported as an object off the plate.
• Eight values in the U1 template had never reached a print — restated preset
  defaults that the slicer overwrote on load, including a nozzle type and start
  and end code older than the presets they were competing with. Removed.

Also in this release

• The fidelity report answers each fact twice: what is in the file, and what the
  slicer will do with it. "Preserved" used to mean only the first.
• Prepare declares the values the slicer is not to take from its own preset, so a
  stated value is the value that runs.
• Placement moves a project onto the plate in one piece, in the target's layout.

Still true

Studio does not slice — Snapmaker Orca does. Studio never starts a print on its
own; every action in Printer Hub is confirmed by you. Everything is local: no
cloud, no account, nothing uploaded off your local network — the one transfer
Studio makes is a sliced job to your own printer, after you confirm it. Your
original files are never modified; preparing always writes a copy. Advice is
advisory: Studio reports what it can establish and says "unknown" when it cannot,
and it does not promise a print will work.

Windows only. The installer is not code-signed — verify the SHA256 on the release
page before running it.

Known limitations

• The fitted nozzle cannot be read from stock firmware, and free storage is not
  reported by it either.
• Remaining filament is known only where something tracks it. Without a provider
  it stays unknown, which is the honest answer on a stock setup.
• A materials provider that requires a sign-in cannot be read; Studio has nowhere
  safe to keep a credential and says so rather than storing one.
• Two providers are implemented and normalise into one shared shape. That is
  evidence the shape is general; it is not a claim that every provider will work.
• Painted colour is read, but whether two colours meet on a layer is decided by
  the slice, so such colours have a toolhead reserved rather than being called
  simultaneous.
• An object whose volumes cannot all be represented declines the split and
  crosses whole, with the audit naming what that costs.
• One machine, one firmware version. The read-only verification generalises; the
  sample does not.

Verification for this release — every count, and what was run against the real
printer — is in
TRUST_STATUS.md.
Installing and verifying the download:
windows-install.md.
Materials providers in detail:
MATERIAL_PROVIDERS.md.

Snapmaker Studio v0.8.0 — the spool, the printer, and the evidence

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

Two things you can use, and one claim Studio can now back.

Will this print run out of filament?

A printer knows which spool is in which slot, because it is looking at it. It
knows nothing about how much is left on it. So the question people actually ask
before pressing print is one no printer can answer — and Studio used to say
"unknown" to it on every setup.

If you run Spoolman on your network, Studio can now read it.

Settings → Materials provider. Choose Spoolman, type the address of the
machine it runs on, press Test connection, then say which spool is in which
slot. That is the whole setup. No account, no cloud, and Studio does not scan
your network looking for anything.

It asks which way your slots are numbered — 1 to 4, or 0 to 3 — because a person
counts them one way and the G-code counts them the other. Guessing puts every
spool one slot out and then reports the wrong material with total confidence.

How hard Studio leans on a number

A refusal to send is the strongest thing Studio says, so it has to be earned:

• Enough, and recent — the figure and its age, and you carry on.
• Short, tracked, and recent — not enough. This blocks the send.
• Short, but nobody has updated the figure in over a week — a warning with
  how old it is. Never a refusal.
• A weight worked out from the spool's declared size — a warning. That is
  arithmetic, not a record of what has been used.
• No date on the figure at all — a warning. Nothing says it is still true.
• Nothing tracking the spool, or Spoolman unreachable — unknown. Not
  "enough", and not "empty".

Being stopped by bookkeeping teaches people to ignore the warnings, and the next
one might be right.

When the printer and Spoolman disagree

The printer wins on what is physically in the slot, because it can see it, and
the disagreement is shown rather than quietly resolved:

Printer reports PLA; your Spoolman mapping says PETG. Check slot 2.

Studio still uses Spoolman's remaining weight there. Which material is loaded and
how much is left are two different claims, and only one of them was contested.

Studio reads Spoolman and never writes to it. It does not create spools, and it
does not decrement anyone's remaining weight after a print.

A second printer, and what that does and does not mean

Studio's printer intelligence used to be written around one machine. The bed
fallback was a constant called U1_BED; a sliced job was checked against the
text "u1" rather than against the printer on the other end of the wire, so a job
correctly sliced for any other machine was reported as wrong.

That knowledge is now data. Studio ships printer profiles — build volume, tool
count, what a machine reports about its own materials, what it is known not to
report — and the checks read what the printer actually says.

To prove it rather than assert it, a second profile ships: a VORON 2.4 250.
One extruder against the U1's four, a 250 mm cube, no object exclusion, and
nothing at all reporting loaded filament. The same code ran against it: one
toolhead was read as one, a four-tool job was blocked, and what is loaded came
back unknown — because a tool count is not a spool count.

Snapmaker U1 — hardware verified.
VORON 2.4 250 — profile verified; hardware not tested by this project.

Those are different claims and Studio keeps them apart. No VORON has ever been
connected to Studio. That profile's facts come from the configuration Klipper
itself publishes for the machine. The U1 remains the only printer this project
has put on a wire, and it is the printer everything here is verified against.

Fixed on the way

These were found while making the above reachable. None of them could affect
v0.7.2, because nothing in that release could configure a material provider —
the engine could read one and no screen ever sent it an address.

• A provider address went straight to the network layer. A file:// address
  opened a local file, and a public web address was actually fetched. Addresses
  are now checked to be on your own network before anything is opened. Studio
  still makes no requests to the internet.
• A stale weight, and a weight worked out from a spool's declared size, could
  both refuse a send. Both now warn.
• Spoolman hides archived spools unless asked for them, so a slot mapped to one
  read as "no such spool" rather than "that spool is archived".
• On a printer that reports its own filament, Studio now records that the machine
  itself confirmed the slot — as opposed to a mapping you entered.

Also in this release

• Design and placement checks name the printer they measured against, so a figure
  that came from a profile never reads as one that came from your machine.
• Printer Hub no longer calls every printer that answers a U1, and shows which
  machine it identified and on what evidence.
• The not-found hint no longer tells you to change a setting on a machine Studio
  has never seen.

Still true

Studio does not slice — Snapmaker Orca does. Studio never starts a print on its
own; every action in Printer Hub is confirmed by you. Everything is local: no
cloud, no account, nothing uploaded. Your original files are never modified —
preparing always writes a copy. Advice is advisory: Studio reports what it can
establish and says "unknown" when it cannot, and it does not promise a print will
work.

Windows only. The installer is not code-signed — verify the SHA256 on the release
page before running it.

Known limitations

• The fitted nozzle cannot be read from stock firmware, and free storage is not
  reported by it either.
• Remaining filament is known only where something tracks it. Without a provider
  it stays unknown, which is the honest answer on a stock setup.
• Painted colour is read, but whether two colours meet on a layer is decided by
  the slice, so such colours have a toolhead reserved rather than being called
  simultaneous.
• A PrusaSlicer object whose volumes use different filaments cannot be fully
  carried; the audit reports the rest as not representable rather than picking
  one.
• One machine, one firmware version. The read-only verification generalises; the
  sample does not.

Verification for this release — every count, and what was run against the real
printer — is in TRUST_STATUS.md.

---

Verify before you run it

• Installer: Snapmaker.Studio_0.8.0_x64-setup.exe
• Size: 17,011,290 bytes
• SHA256: 67776cd1db9f620d3c38e656bf831b0f976e0669ce91398caa998e40cf929af6

Get-FileHash -Algorithm SHA256 .\Snapmaker.Studio_0.8.0_x64-setup.exe

v0.7.2 — a Prusa object's filament survives the crossing

Snapmaker Studio v0.7.2 — a Prusa object's filament survives the crossing

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

A patch release with one defect fixed and one audit that should have caught it.

Every PrusaSlicer project came out on filament 1

If you assigned an object to filament 3 in PrusaSlicer and asked Studio to prepare
a U1 copy, the copy assigned it filament 1. Every object, every project. The
geometry was byte-identical, nothing was reported removed, and the print would
have come out in the wrong colours.

Prepare now carries what the source says each object prints in. A slot above four
is carried as it is, never renumbered to fit the machine's toolheads — a project
may legitimately reference six colours, and deciding which to merge is a question
for you, with Studio's colour planning, not a silent rewrite. An object with no
assignment of its own takes its volumes' slot when they agree, and its own name
comes across with it.

The audit could not see it

Fidelity compared per-object assignments only when both files spoke the same
dialect, and a PrusaSlicer source never does. It now reads the assignment from
either dialect and reports one row per object: preserved, changed with
"slot 3 → slot 1", lost, or — for an object whose volumes use different
filaments, which a single-part U1 object cannot represent — not representable,
with the slots named rather than one of them quietly chosen.

What has not changed

Studio still does not slice — Snapmaker Orca does. It still never starts a print,
never modifies your original file, and never sends anything anywhere.

Verified against this installer

• Installed-build acceptance: 31/31, including upgrading in place from v0.7.1
• Real Snapmaker U1, read-only: 26/26
• u1convert selfcheck: 27/27 over 15 documented routes
• pytest: 1185 passed, 4 skipped · npm run test: 306 passed

Verification detail: docs/TRUST_STATUS.md. Installer name, size
and hash: docs/RELEASE_METADATA.md.

Still true, and stated plainly

Windows only. The installer is not code-signed — verify the SHA256. Purge cannot be
separated from printed filament in Orca's output. The fitted nozzle cannot be read
from the printer. Free storage is not exposed by stock firmware. Painted colour is
read from the project, but whether two painted colours share a printed layer is
decided by the slice. A PrusaSlicer object whose volumes use different filaments
cannot be fully carried into a single-part U1 object, and the audit says so.
Remaining filament is known only where something tracks it.

v0.7.1 — what a real brush writes

Snapmaker Studio v0.7.1 — what a real brush writes

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

A patch release with two fixes and one correction, all of them found by checking
Studio against something outside itself.

A genuine painted project could be reported as partly undecodable

v0.7.0 read painting from files that Studio's own encoder had written and slicers
had echoed back. This release went further and painted inside Snapmaker Orca
2.3.5 and Bambu Studio 02.08.02.61 — their gizmos, their brushes, their filament
palettes — and read what those slicers saved.

That found a defect. A single facet of a large surface, painted with Snapmaker
Orca's round brush, is written as a 35,460-character attribute; Studio refused
anything over 4,096, a limit chosen before any slicer-authored file had been seen.
Two facets of a real project came back as malformed, losing their filament, area
and height. Studio now reads them: three filament slots across 55,374 painted
patches, in under a tenth of a second.

"Share the same layers" was more than Studio can prove

Two colours whose heights overlap can meet on a printed layer. Whether one
really does is decided when Orca slices, and Studio does not slice. The plan has
not changed — a toolhead is reserved for each such colour, which is the
conservative answer either way — but the wording now matches the evidence:
"not proven separable — reserve a toolhead each".

Four claims on this project's own pages were false

The README's download button still pointed at v0.6.2. The self-check was described
as a 25-check table and the acceptance harness as 30 checks. The evidence section
credited "the published v0.6.2 installer" directly above v0.7.0's numbers.

The guard that exists to prevent exactly this read one line at a time, so a
sentence that wrapped, or a link outside the Download section, was invisible to
it. It now reads whole blocks — paragraphs, table rows, list items, with the
headings above them — and covers release links anywhere, installer credits,
screenshot paths, combined evidence rows, prose counts and the demo's length. Each
of the four false claims is now a test against the guard itself.

What has not changed

Studio still does not slice — Snapmaker Orca does. It still never starts a print,
never modifies your original file, and never sends anything anywhere: no cloud, no
account, no telemetry.

Verified against this installer

• Installed-build acceptance: 31/31, including upgrading in place from v0.7.0
• Real Snapmaker U1, read-only: 26/26
• u1convert selfcheck: 27/27 over 15 documented routes
• pytest: 1153 passed, 3 skipped · npm run test: 306 passed

Verification detail: docs/TRUST_STATUS.md. Installer name, size
and hash: docs/RELEASE_METADATA.md. What painting Studio
reads, where it stops, and which slicer proved which row:
docs/PAINTED_COLOUR.md.

Still true, and stated plainly

Windows only. The installer is not code-signed — verify the SHA256. Purge cannot be
separated from printed filament in Orca's output. The fitted nozzle cannot be read
from the printer, and stays unknown. Free storage is not exposed by stock firmware.
Painted colour is read from the project, but whether two painted colours share a
printed layer is decided by the slice, not the file — and that a paint state names
filament N has been proven by slicing in PrusaSlicer only. Remaining filament is
known only where something tracks it.

v0.7.0 — the painting, read

Snapmaker Studio v0.7.0 — the painting, read

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

Multi-material painting is the part of a project most tools treat as opaque. A
model painted in four filaments looks, to anything that is not a slicer, like a
mesh — and Studio was one of those things. It could prove a project had painted
regions, and then said painted colour "cannot be classified without slicing".

The paint was in the file the whole time. This release reads it.

What Studio now knows about a painted project

Before anything is sliced, from the project's own per-facet data:

• Which filament slots the painting uses. Exactly, including a slot the
  project paints with but never lists — which is a defect in the project, and is
  reported rather than quietly renumbered onto a filament that happens to exist.
• How much of the model each painted colour covers — the number of facets it
  touches and the surface area it accounts for. Those are two different facts
  and are shown as two: a mesh's triangles are not equal in size, so 40% of the
  facets is not 40% of the surface.
• The height band each painted colour occupies, reconstructed from the
  painted patches themselves and placed by the object's own transform, so the
  heights are the heights on the plate.
• Which colour the unpainted parts print in — from the part's own assignment,
  or unknown where the project does not say.

What that changes for a project with more colours than toolheads

The old answer to a painted six-colour project was one sentence: Studio cannot
classify this safely. Now each colour gets a verdict and the evidence behind it:

• a colour whose painting shares a height band with another needs a toolhead,
  because the two can meet on a layer;
• a colour painted only between, say, 38.2 mm and 61.0 mm, with every other
  colour ending below it or starting above, can be handled as a planned swap;
• a colour that cannot be compared — no readable height, or another colour
  assigned to a whole object whose extent Studio has not measured — stays
  unclassified, with that reason attached.

The colours card leads with the sentence a beginner needs — "Parts of this model
are painted with 3 filament colours." — and keeps every number behind it one
click away.

Where Studio still stops

Two painted colours whose heights overlap can meet on a printed layer. Whether
they do is decided when Orca slices. Studio says the first and never the
second. That boundary is the point of the feature, not a gap in it.

Fixed

• Every painted project in the field was reported as unpainted. The trait
  looked for painting in Metadata/model_settings.config, where no slicer has
  ever written it.
• The fidelity audit compared painting by counting markers in the bytes. That
  cannot tell painting that survived from painting that was rewritten: remap
  every painted facet to a different filament, or shrink a painted region to a
  quarter of its area, and the count is identical. It compares the painting
  itself now.

What has not changed

Studio still does not slice — Snapmaker Orca does. It still never starts a print,
never modifies your original file, and never sends anything anywhere: no cloud, no
account, no telemetry.

Verified against this installer

• Installed-build acceptance: 31/31, including upgrading in place from v0.6.2
• Real Snapmaker U1, read-only: 26/26
• u1convert selfcheck: 27/27 over 15 documented routes
• pytest: 1104 passed, 3 skipped · npm run test: 304 passed

The decoding itself was checked against files two real slicers wrote: paint was
handed to PrusaSlicer 2.9.6 and OrcaSlicer 2.4.2, and both wrote every attribute
back byte for byte. The painted fixture was then sliced for a five-extruder
printer, and the G-code used tools T0–T4 and no others — which is what proves a
paint state names filament N counting from one, rather than that being asserted.

Verification detail: docs/TRUST_STATUS.md. Installer name, size
and hash: docs/RELEASE_METADATA.md. What painting Studio
reads and where it stops: docs/PAINTED_COLOUR.md. Each
release's evidence is kept separately under docs/internal/evidence/.

Still true, and stated plainly

Windows only. The installer is not code-signed — verify the SHA256. Purge cannot be
separated from printed filament in Orca's output. The fitted nozzle cannot be read
from the printer, and stays unknown. Free storage is not exposed by stock firmware.
Painted colour is read from the project, but whether two painted colours share a
printed layer is decided by the slice, not the file. Remaining filament is known
only where something tracks it.

v0.6.2 — evidence that stays true

Snapmaker Studio v0.6.2 — evidence that stays true

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

A patch release. Four defects, three of them found by attacking the project's own
verification rather than its features.

A release's evidence changed when a later release shipped

Studio's public argument is "check it yourself", so its counts are load-bearing.
There was one canonical evidence file, rewritten on every release — and because
there was only one of it, publishing quietly restated the numbers that every
document quoted, including the sections describing releases that had already
shipped.

The trust record said v0.6.0 had been verified with 967 backend tests, 290 desktop
tests, a 30-check acceptance run and 26 hardware checks. v0.6.0 shipped with 822,
284, 28 and 20. The larger figures come from a suite and a harness that did not
exist when it was published. v0.5.0 and v0.4.0 had their hardware counts
overwritten the same way.

Evidence is now one immutable snapshot per release. Past releases were
reconstructed from what each release's own tag recorded — and where a release
recorded nothing, the snapshot says so rather than carrying a plausible number
backwards. Publishing adds a file; it never edits one. A test re-derives every
published release's evidence from its own tag, so a future release cannot rewrite
what an earlier one was verified with.

Studio could fail to start on a machine that is short of ports

The loopback service spoke HTTP/1.0, which closes the connection after every
response, and drawing a single page makes a dozen calls. Each one took a fresh
source port and left it in TIME_WAIT.

That is invisible on a quiet machine and fatal on a busy one. The machine this was
found on had 14,000 connections held open by Docker Desktop; Studio's own service
could not be reached, and sometimes could not even bind — the app simply did not
start, for a reason that had nothing to do with Studio.

It speaks HTTP/1.1 now, so a client keeps one connection. Binding retries and falls
back to fixed ports below the dynamic range, and if even that fails the message
says what is actually wrong.

"This printer does not report which filaments are loaded" could be untrue

A dropped connection and a printer that genuinely reports nothing came back the
same way, so a momentary network failure was reported as a fact about the user's
machine. They are told apart now, printer reads retry before giving up, and the
firmware page degrades to "Studio could not ask" rather than an error.

A re-slice could pass as the file that was checked

The send fingerprint identified a job by size and modification time. A re-slice
that lands on the same byte count, written inside the same timestamp tick, matched
both — which is exactly the case the fingerprint exists for. It now fingerprints
the contents as well, at three bounded windows: the start, the middle and the end.

Also in this release

Every item in the send confirmation can show what it was read from, one level down
— the beginner never opens it, and an expert who doubts a verdict should not have
to ask. The card says when the printer was last actually read. And the guard that
checks public counts now reads the README's combined row, which said
822 · 284 · clean · clean through an entire release because the old check only
recognised a count next to the word "passed".

What has not changed

Studio still does not slice — Snapmaker Orca does. It still never starts a print,
never modifies your original file, and never sends anything anywhere: no cloud, no
account, no telemetry.

Verified against this installer

• Installed-build acceptance: 30/30, including upgrading in place from v0.6.1
• Real Snapmaker U1, read-only: 26/26
• u1convert selfcheck: 25/25 over 15 documented routes
• pytest: 1004 passed, 3 skipped · npm run test: 293 passed

Verification detail: docs/TRUST_STATUS.md. Installer name, size
and hash: docs/RELEASE_METADATA.md. Each release's evidence
is kept separately under docs/internal/evidence/.

Still true, and stated plainly

Windows only. The installer is not code-signed — verify the SHA256. Purge cannot be
separated from printed filament in Orca's output. The fitted nozzle cannot be read
from the printer, and stays unknown. Free storage is not exposed by stock firmware.
Painted colour cannot be classified without slicing. Remaining filament is known
only where something tracks it.

v0.6.1 — the answers, attacked

Snapmaker Studio v0.6.1 — the answers, attacked

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

v0.6.0 closed the workflow: the sliced job comes back on its own, Studio works out
whether it belongs to your project, and the send confirmation says what will
actually happen. This release was spent trying to make all of that lie.

Everything below was a real defect in v0.6.0. If you are running it, this is worth
the download.

Studio could not read the object names in a real Orca job

The strongest evidence that a G-code file is the slice of your project is that it
prints the same objects. Studio looked for that in the labels Snapmaker Orca writes
when object exclusion is switched on — and it is off by default.

Three jobs pulled off a real U1 carry 90, 52 and 3,476 object labels between them,
in the other dialect, and not one of the kind Studio was looking for. So the
evidence was there, in the files it was written for, and Studio was not reading it.
It reads both dialects now, and PrusaSlicer's as well.

A matching setup was being read as a matching project

Same printer, same spools, same materials came out as "looks like your project" —
which is true of every job sliced in a workshop. Any file in the folder could be
called the slice of any project.

Evidence is now separated into what identifies the model — which objects the job
prints — and what merely describes the setup it was sliced with. With nothing
identifying the model, the answer is "Studio can't tell", however much of the rest
lines up, and the reasoning is one click away wherever the verdict appears.

The separation also fixes the opposite mistake: a project re-sliced in a different
colour is still that project, and a job printing one plate of a four-plate project
is part of it rather than a stranger.

The watcher would offer a file that stopped part-way

Snapmaker Orca writes its time estimate and filament total inside the first few
hundred kilobytes of a job, and the old completion check accepted either as proof
the file had finished. A job cut off early contained both. It now needs the ending
its own dialect actually has.

The same check also slept two seconds per file inside a request the app repeats
every five seconds, so a folder of twelve jobs blocked for twenty-four. It
remembers sizes between polls instead, and never sleeps.

Nothing re-read the world between the check and the send

You read the checks, walk to the printer, come back and press send. In between, a
slot can empty, a spool change, a print start, or the job be re-sliced to the same
filename — and nothing on screen looks any different.

The check now records what it looked at. Sending re-reads the same things, and if
any of it moved, nothing is uploaded: what changed is named, the fresh answer
replaces the stale one, and the decision goes back to you.

"Upload failed" was four different situations

A printer that refused the file, a connection that dropped, bytes accepted but
never listed, and a file the printer has not finished reading each need something
different done about them. They are told apart now — including a printer still
describing the file this one replaced, which is how a job starts with the previous
file's estimate.

Filament figures now say where they came from

"87 g needed, 43 g left, it will run out" only stops a send when it rests on a
figure something is actually keeping track of, short by more than that tracking can
drift. A number of unstated origin warns instead. Negative weights, weights larger
than the spool holds, and weights that are not weights are refused rather than
used, and a tracker that contradicts the printer about what is loaded is shown as a
disagreement rather than silently resolved.

A model name could reach a support bundle

The bundle drops your project's filename on purpose — it goes to a stranger. The
sliced-job half of it was carrying the name through anyway. Fixed, and now guarded
by a test that tries to get a model name out of every route into the bundle.

A badge told people they had firmware they do not have

"Extended firmware" appeared whenever a printer reported fifteen or more macros —
which a community build adds, and so does an owner who writes their own. Detection
is positive only now: the firmware has to answer for itself, distinguishably from
what the printer serves for a path nobody claims. Not finding it never means your
printer is stock, because Studio cannot know that.

A prepared PrusaSlicer copy prints the way the project did

Layer height, first layer height, infill, walls, brim, support on or off and the
filaments now carry into the U1 copy, each recorded with where it came from. A
project sliced at 0.15 mm with four walls used to arrive as the starter profile's
0.2 mm and two, which is a different print of the same shape.

Temperatures deliberately do not carry: a PrusaSlicer profile's 245 °C is about a
Prusa hotend, and copying it into a U1 project would look like fidelity while
handing one machine another machine's numbers.

What has not changed

Studio still does not slice — Snapmaker Orca does. It still never starts a print,
never modifies your original file, and never sends anything anywhere: no cloud, no
account, no telemetry.

Verified against this installer

• Installed-build acceptance: 30/30, including upgrading in place from v0.6.0
• Real Snapmaker U1, read-only: 26/26
• u1convert selfcheck: 25/25 over 15 documented routes
• pytest: 967 passed, 3 skipped · npm run test: 290 passed
• Bounds measured on files built for the purpose: a 525 MB job reads in 0.20 s
  holding 40 MB; its timeline scans in 3.0 s holding 9 MB

Verification detail: docs/TRUST_STATUS.md. Installer name, size
and hash: docs/RELEASE_METADATA.md.

Still true, and stated plainly

Windows only. The installer is not code-signed — verify the SHA256. Purge cannot be
separated from printed filament in Orca's output. The fitted nozzle cannot be read
from the printer, and stays unknown. Free storage is not exposed by stock firmware.
Painted colour cannot be classified without slicing. Remaining filament is known
only where something tracks it.

v0.6.0 — the workflow becomes one thing

Snapmaker Studio v0.6.0 — the workflow becomes one thing

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

v0.5.0 could read a sliced job, plan the materials and decide whether to send it.
It still made you carry the file back from Snapmaker Orca by hand, and it could
not tell whether that file was the slice of the project you had just checked.

Both are fixed, and they are the same fix: Studio now follows one job through its
whole life instead of answering questions about files.

The sliced job comes back on its own

Tell Studio once where Snapmaker Orca saves its exports. While you are on the page
that cares, it notices finished jobs appearing there and picks up the one that
belongs to your project.

It will not offer a half-written file: a candidate has to have stopped growing
and end the way a finished job ends. One folder, chosen by you. No background
service, no watching your disk, nothing uploaded anywhere.

"Is this actually the slice of my project?"

Everything after slicing depends on that answer, and nothing in a G-code file
points back at the 3MF it came from. So Studio weighs what evidence exists — the
set of object names, the filament colours and materials in each slot, how many
slots, the target machine, the object count — and tells you how sure it is:

• This is your project, sliced — evidence hard to produce by coincidence
• Looks like your project — several signals agree, none decisive
• Studio can't tell — the evidence points both ways
• A different project — something that cannot be true of the same file

A matching filename is never proof. Two files can share a name and nothing
else, and Studio treats that as the weak hint it is. Object names are compared as
a fingerprint, so your model names never leave the file. If two candidates are
equally good, you get a question rather than a guess.

What is loaded can come from more than the printer

The printer knows which spool is in a slot. It does not know how much is left on
it — no printer does. Studio now accepts optional read-only sources for that, over
your local network, starting with Spoolman.

The printer stays the authority on what is in a slot; another source may only add
what the machine cannot see. Nothing is required, nothing is written back to
anyone else's records, and when two sources disagree Studio says so rather than
picking one.

"Do I have enough filament?"

With a source that tracks remaining weight:

Slot 2 needs 87 g. The tracked spool has 43 g left — it will run out part-way
through.

That is a blocker on the send check, because running out mid-print is not a
warning. Where a spool's weight is not tracked — which is every stock U1 — the
answer is unknown, and Studio says so instead of staying quiet.

One surface for the whole job

This print shows the stages in the order they happen: before slicing,
prepared, after slicing. It is the same work as before, without needing to know
which page to open next. Every individual page still exists and still works — in
Simple mode the cockpit takes the place of "Check my model", which moves to More
tools.

Fixed: uploads that were not finished

Moonraker accepts an upload and parses its metadata afterwards, so Studio used to
report success while the printer could not yet describe the file — the failure
the U1 Toolkit documented. Uploads are now confirmed against the printer's own
metadata, with one polite rescan request if it has not appeared, and a file of the
same name but a different size is caught. "Uploaded" now means the printer has it
and has read it.

Also fixed: handing Studio a .3mf where a .gcode was expected used to produce
a report that looked empty for no stated reason. It now names the mistake.

Checked, and still honestly unknown

Free space on the printer. Traced properly this time rather than assumed:
/machine/system_info reports total_bytes: 0, /server/files/roots reports no
sizes, and nothing else on stock firmware exposes disk usage. Studio says it
cannot tell you whether a job will fit, and now says exactly what it looked at.

Unchanged

Local-first: no cloud, no account, no telemetry, nothing uploaded. Studio does
not slice — Snapmaker Orca does. Your originals are never modified. Studio never
starts a print on its own, and every check is advisory rather than a promise.

Upgrading

Install over the top. Settings and library are kept, and the upgrade path is part
of the release checks.

Known limitations

• Windows only.
• The installer is not code-signed; verify the SHA256.
• Purge cannot be separated from printed filament in Snapmaker Orca output.
• The fitted nozzle cannot be read from stock firmware.
• Free storage is not reported by stock firmware.
• Painted colour cannot be classified without slicing.
• PrusaSlicer projects are read in full but not yet fully carried into a U1 copy;
  what cannot be carried is named in the fidelity report.

Install

Installer name, size and SHA256: RELEASE_METADATA.md.
What was verified and how: TRUST_STATUS.md.

v0.5.0 — the loop gets intelligent

Snapmaker Studio v0.5.0 — the loop gets intelligent

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

v0.4.0 taught Studio to read the job your slicer produced and check it against
your printer. This release answers the three questions that come next.

What happens during this print?

Studio reads the whole job in one pass and tells you, in order:

• it starts on slot 3, loaded with your yellow PLA;
• the bed goes to 65 °C;
• slots 1, 2 and 4 join in at layer 1;
• slot 3 is finished with at layer 239 — that spool can come out;
• it pauses at layer 88 and waits for you;
• 764 tool changes in total, each one purging some filament;
• 281 layers, ending on slot 4.

Every line carries the G-code that proves it, folded away until you want it. This
was verified against a real 89 MB four-colour job: read in half a second, using
eight megabytes of memory.

What should I load?

Once a job is sliced its tool assignments are fixed — slot 3 prints what the
slicer decided slot 3 prints. So Studio answers the question you actually have,
slot by slot: this one is ready; this one is empty and the job needs it; this one
has PETG and the job wants PLA; this one the job never touches, so leave it alone.

Colour is advisory and says so. Material is compared by family, so "PLA Matte"
loaded against a job sliced for "PLA" is not reported as wrong.

Studio does not track your filament and does not want to — U1Hub, Spoolman and
OpenSpool already do that well. This is the intelligence over whatever spool state
your printer reports.

Ready to send?

Three buckets, kept strictly apart:

• Will stop the print — provable. A slot the job uses is empty. A tool the
  printer does not have.
• Worth settling first — real, but not proof. A different colour is loaded.
  The printer is busy. The job pauses and nobody is standing there.
• Studio can't check this — the fitted nozzle, which stock firmware does not
  report; free space, which this firmware does not report either.

An unknown is never promoted to look thorough, or demoted to look clean. And the
send button is not disabled when there is a blocker — it is your printer, and
Studio says why instead of deciding for you.

PrusaSlicer projects are read, not just recognised

Studio used to detect a PrusaSlicer .3mf and read its printer model, and
nothing else — so an ordinary Prusa project came out as "0 filaments, no layer
height" and every check downstream had nothing to work with.

It now reads the project's own configuration: printer model and bed size, every
filament slot with its type, colour, vendor and diameter, layer and first-layer
heights, supports, temperatures, per-object extruder assignments and overrides,
and variable layer-height profiles. What a U1 copy cannot keep — variable layer
height, per-object overrides, support styling — is named in the fidelity report
instead of quietly disappearing.

One button that talks to the internet, and only when you press it

Help → Check for a newer version asks GitHub which release is newest. That is
the only outbound request Studio makes. It sends nothing about you, your files or
your printer, it never runs on its own, and it never downloads or installs
anything — the answer is a version number and a link.

It is built into the desktop shell rather than the page, so the web view keeps its
lock-down, and a test fails the build if that ever changes.

Fixed

• The timeline scanner missed everything in a job written on Windows: lines end
  with CR LF there, and the stray carriage return sat between the marker and the
  end of the line. Found by its own test.
• A quoted filament name containing a comma invented an extra extruder.
• The public evidence counts had drifted from what the harnesses produce — 21/21
  where it is 27, 15/15 where it is 18, 495 backend tests where there are 766.
  There is now one canonical source and a test that fails the build when a
  document disagrees with it.

Upgrading

Install over the top. Settings and library are kept, and the upgrade path is part
of the release checks: v0.4.0 is installed, used, then upgraded, and the resulting
state is verified.

Unchanged

Local-first: no cloud, no account, no telemetry, nothing uploaded. Studio does
not slice — Snapmaker Orca does; reading a G-code file is not producing one.
Your originals are never modified. Studio never starts a print on its own. Every
check is advisory and none of them promises a successful print.

Known limitations

• Windows only.
• The installer is not code-signed; verify the SHA256.
• Purge cannot be separated from printed filament in Snapmaker Orca output.
• The fitted nozzle cannot be read from stock firmware.
• Free storage is not reported by this firmware, so Studio says so rather than
  guessing whether a job will fit.
• Painted colour cannot be classified without slicing.

Install

Installer name, size and SHA256: RELEASE_METADATA.md.
What was verified and how: TRUST_STATUS.md.

v0.4.0 — the loop closes, and the beta ends

Snapmaker Studio v0.4.0 — the loop closes, and the beta ends

Independent open-source project — not affiliated with or endorsed by Snapmaker.
"Snapmaker" is a trademark of its respective owner.

This is the first stable release of Snapmaker Studio, and it finishes the job the
project set out to do.

Studio can now see the other half

Until today Studio stopped at the slicer. It read your project, explained the
risks, compared the project against your printer, prepared a corrected copy, and
handed that copy to Snapmaker Orca. What Orca produced was somebody else's
problem — which meant the most expensive failures were the ones Studio could not
see:

• the job prints from slot 3, and slot 3 is empty;
• the job was sliced for PETG, and PLA is loaded;
• the job was sliced for a different printer entirely.

None of those are visible in the project file. None are visible on the printer
alone. Open the .gcode your slicer produced and Studio now reads it, then
compares it to the printer as it is right now.

Drag it onto the window, or hand it to Studio on the command line — a sliced job
is not treated as a project, and goes straight to the new After Slicing page.

Studio still does not slice. Snapmaker Orca does.

What it reads, and what it refuses to

From the file itself: which machine it was sliced for, the slicer and version,
layer count and height, estimated time, filament per slot, which tools it
actually prints from, the nozzle it expects, whether it defines excludable
objects.

Against your printer: every tool it needs exists; every slot it uses has a spool;
the loaded material matches, compared by family so "PLA Matte" is not a false
alarm against "PLA"; the sliced bed fits the real bed; the firmware supports the
object exclusion the job assumes; the printer is free.

And the refusals, which matter just as much. Purge is never split out of a
total the slicer did not split. Snapmaker Orca reports one filament figure per
slot and does not separate purged filament from printed filament, so Studio
reports the total, says the split is not available from this file, and leaves it
there. The nozzle check is still an honest unknown, because stock firmware does
not report which nozzle is fitted.

Costing from measurements instead of estimates

Once a file is sliced, guessing stops being necessary. Filament by slot and print
time are read from the file. Every line says where its number came from —
measured by the slicer, derived from your prices, an assumption you can change,
or not stated at all. A figure the file does not contain reads as unknown, never
as zero.

A bug report worth sending

Studio asks people to tell it when it gets an analysis wrong. That report needs
facts behind it, and gathering those by hand is exactly what nobody does. Help →
Reporting something Studio got wrong now assembles them: your project's traits,
the Doctor's findings, the sliced job, what your printer reported, and the fix
ledger.

Your username, home folder, file paths, machine name and printer address are
replaced before the bundle is assembled, and you can read the entire thing
before it is written to disk. Studio never sends it anywhere.

Upgrading from a beta

Install over the top. Your settings and library are kept, and the upgrade is
checked as part of the release: a beta.24 installation is created, used, then
upgraded, and the resulting state is verified.

What was fixed

• u1convert selfcheck crashed at the very end on a default Windows console —
  the results table contained a character cp1252 cannot encode. The one command
  Studio tells strangers to run now prints its own results on a stock console.
• The support bundle leaked a model's file name: redacting a username inside a
  path inserted characters that stopped the path redaction dead. Paths are
  redacted first now. Caught by its own test before the feature ever shipped.
• A slicer that reports filament per slot without a total now has the total added
  up rather than left blank.

Unchanged

Local-first: no cloud, no account, no telemetry, nothing uploaded. Studio does not
slice. Your originals are never modified. Studio never starts a print on its own.
Every check is advisory — it does not promise a successful print.

Known limitations

• Windows only. macOS and Linux builds are not built or tested.
• The installer is not code-signed. SmartScreen will show an unknown
  publisher; verify the SHA256 below before running it.
• Purge cannot be separated from printed filament in Snapmaker Orca output.
• The fitted nozzle cannot be read from stock firmware.
• Painted colour cannot be classified without slicing, and is reported as
  unclassified rather than guessed.

Install

Installer name, size and SHA256: RELEASE_METADATA.md.
Full instructions and uninstall: windows-install.md.
What was verified and how: TRUST_STATUS.md.