Phase 3 · Ship it · L19

The tuning log

In six months you will look at a number and have exactly one question: did I measure this, or did I copy it? This is how you answer.

⏱ ~15 minutes• 🏁 Closes the course• Phase 3

◎ Why this lesson

This course exists because you had a complete, well-researched tuning guide full of numbers that nobody had measured — and no way, from the file alone, to tell which were which. That is the exact failure a log prevents. It's also what makes a three-printer fleet maintainable rather than three separate hobbies: a shared record means a measurement on one machine informs the others instead of being lost. This is the last habit, and it's the one that makes the other eighteen lessons compound.

Two places to write, and they do different jobs.

1Two homes, one record

Both, not either. They fail in different ways.
	`Filament Settings → Notes`	`tuning-log.md` in this repo
Holds	the essentials, compressed	the full history, dated
Travels with	the profile, into a config bundle	the repository
Visible	while you're about to print	when you're deciding what to trust
Survives	a machine rebuild, if the bundle is exported	a PrusaSlicer reinstall
Diffable	no	yes — this is the real advantage

The notes field is the one you'll actually read at the moment of use, so keep it short and current. The Markdown log is the one that answers how did this number get here, so it's append-only — you add a dated row, you don't edit the old one. Superseded measurements are signal: they show whether a value is stable across spools or drifting.

The notes field — enough to act on, no more

eSun PETG @MK4S 0.4 | spool: eSun PETG black, opened 2026-07-12
dried 65C/8h on 2026-08-02 | EM 0.94 measured | M572 S0.048 measured
MVS 13 measured | validated 2026-08-04, all 5 criteria
NB: black runs ~0.02 lower EM than the green spool

2What a row has to contain

Six fields, and each one exists because leaving it out has cost somebody an evening.

Date Absolute, never "last week". It's what lets you correlate a drift with a firmware update, a nozzle change, or a wet season.
Printer MK3S, MK4S or Core One. A number without a machine is worse than no number — it invites exactly the cross-family copy this course keeps warning about.
Spool — brand, material, and colour Pigment loading changes flow behaviour within the same brand and material, so a black and a white spool of identical eSUN PETG can legitimately want different extrusion multipliers. Colour is not decoration in this table.
Dried — when, at what, for how long In Mauritius this is the field most likely to explain a strange result. "Unknown" is a valid and useful entry; it tells you not to trust the row.
The measurements Temperature, EM, K or S, retraction, MVS. And critically —
Measured or inherited? Mark every value. 0.94 (m) for measured, 0.95 (i) for inherited from a table or another spool. This single convention is the whole point of the log.

▲ The measured/inherited mark is the load-bearing part

Everything else in a log is convenience. This one is the thing that distinguishes your log from the guide you started with. A profile full of (i) values is a hypothesis; a profile full of (m) values is a measurement. Both are legitimate — you cannot measure everything for every spool — but you have to be able to tell them apart, because they warrant different confidence when a print goes wrong.

A row that answers the six-month question

### MK4S · Filament
| Date | Spool | Dried | Temp | EM | S | Retract | MVS | Validated |
|---|---|---|---|---|---|---|---|---|
| 2026-08-04 | eSun PETG black | 65C/8h 08-02 | 235 (m) | 0.94 (m) | 0.048 (m) | 0.8 (m) | 13 (m) | ✅ all 5 |
| 2026-08-11 | eSun PETG green | 65C/8h 08-10 | 235 (i) | 0.96 (m) | 0.048 (i) | 0.8 (i) | 13 (i) | cube only |

Read the second row. One evening's work, one measurement — and it says so. Next time that spool misbehaves you know instantly that its advance value was never measured, and you know where to start.

3Keeping three machines honest over time

A fleet drifts. Nozzles wear, belts relax, firmware updates change defaults, and the humidity does what it does. The log's second job is to make drift visible.

Three habits, each cheap:

Re-export the config bundle after every session, into this repo, dated. File → Export → Export Config Bundle.1 Because it's an .ini in version control, git diff will show you exactly which values moved between two sessions — including ones you changed without meaning to.
Re-run the Phase 1 sign-off after any hardware change, and log it. Nozzle, belt, sheet, firmware, or moving the printer. A machine that hasn't been re-verified is a suspect again, and the log is what tells you when it was last verified.
Periodically diff your self-contained profiles against the current system profile. This is the price of the self-contained choice from Lesson 17: you don't get Prusa's fixes automatically, so you have to go and look. Once a couple of firmware releases is plenty. Adopt deliberately, and log what you adopted and why.

⌁ What "done" looks like

Your mission asked for a specific thing: go from a newly opened spool to a signed-off profile in one evening, without re-reading the guide. That is now a concrete procedure — dry it, confirm the machine's sign-off is current, run the seven Phase 2 steps in order, name and scope the profile, validate against five criteria, log it with measured/inherited marks, export the bundle. Nineteen lessons compress to one checklist, and the checklist is on The Calibration Card.

4Build a row, then read four broken ones

Start by building your own. Every field is here because leaving it out has cost somebody an evening — and every measurement carries its own (m) or (i) mark, so you cannot fill this in without deciding, value by value, whether you measured it or inherited it. That decision is the lesson.

🗒 Row builder — tuning-log.md and the notes field

Fill what you have. Marks: m = measured on this machine with this spool, i = inherited from a table, another spool or another machine.

Date absolute, never "last week" Printer Spool brand · material · colour Dried temp/hours + date, or "unknown"

Temperature °C Mark

Extrusion multiplier × Mark

Advance K on MK3S, S on the others Mark

Retraction mm Mark

Max volumetric speed mm³/s Mark

Validated scope, not just a tick

This row is a Marlin machine, so the advance value is written K, not S — and the builder below has labelled it for you. That letter is the whole point: an M572 S number copied here would still print, just plausibly wrong forever. If this value came off the MK4S, it is (i) at best. There is no conversion between the two; the only honest fix is to re-run Lesson 12 on the MK3S.

Buddy firmware, so this is M572 S — labelled S in the row below. Your MK4S and Core One values should land close to each other; if they agree within a step, that agreement is itself evidence you measured rather than copied.

Everything marked measured. Legitimate after a full evening — but if every row in your log looks like this, the marks have stopped distinguishing anything. A healthy log is mostly (i) with a few well-chosen (m).

Record the scope, not just the tick. Material, machine, speeds, enclosure state, date — a bare ✅ isn't a falsifiable claim, and you won't later be able to tell whether a failure is inside or outside what you certified.

Top block goes in tuning-log.md under that printer's heading; bottom block goes in the profile's notes field. Same facts, two homes.

Now four rows that came out of a real log, each with something wrong. Decide what it is before you open the answer.

| 2026-08-04 | eSun PETG | dried | 235 | 0.94 | 0.048 | 0.8 | 13 |

Three faults. No printer — so the 0.048 is unattributable, and on a Marlin machine it would be meaningless anyway. No colour — so you can't tell whether a future spool of the same brand should reuse the EM. And "dried" without a date or a schedule tells you nothing you can act on; "unknown" would actually be more useful, because it's honest.

Also missing: the measured/inherited marks. Every one of those five numbers is now a claim with no provenance, which is precisely the state this course started in.

| 2026-08-11 | MK3S | eSun PETG grey | 65C/8h | 235 (m) | 0.94 (m) | S 0.048 (m) | ... |

The advance value is on the wrong scale. S is M572 — Buddy firmware, Pressure Advance. The MK3S is Marlin and wants M900 K, whose values sit in a different range entirely. Marked (m), so somebody believes they measured it.

Most likely what happened: the value was measured on the MK4S and copied across, then re-marked as measured. That's the single most expensive mistake available in this course, and here it is preserved in the log — which is the log doing its job. Re-run L12 on the MK3S and record a K value.

Every row for the last four months is marked (m), on all three machines

Suspiciously complete. Measuring all seven values for every spool on every machine is a lot of evenings, and the whole point of the marks is that they distinguish. If everything is marked measured, either the marks stopped being applied honestly or they stopped being applied thoughtfully.

Realistic practice: temperature and advance are usually stable within a brand and material, so they're often legitimately (i) after the first spool. Extrusion multiplier is the one that genuinely moves with colour and is worth measuring per spool. A healthy log is mostly (i) with a few well-chosen (m).

A row with full measurements and Validated: ✅, but no scope recorded

Validated at what? Lesson 18 ended with the claim's scope: material, machine, speeds, enclosure state, date. A tick without those is not a falsifiable claim — you can't later determine whether a failure is inside or outside what you certified.

Concretely: if this was a Core One row validated with the door open and you now print with it shut, the tick doesn't cover you. Record the scope or the tick means "it looked fine once".

5Check yourself

From memory. These interleave the whole course.

Question 1 of 3

Why does spool colour earn its own field in the log?

Question 2 of 3

What does the measured/inherited mark buy you that a plain number doesn't?

Question 3 of 3

Why does choosing self-contained profiles create an ongoing obligation?

✎ Your task · do this with your tutor

Backfill the log, honestly

Open tuning-log.md — you started it in Lesson 4 — and bring it up to date. The important part is the honesty of the marks, not the completeness of the table.

A Machine section per printer, with the Phase 1 sign-off numbers you actually measured, dated.
A Filament section per printer. Backfill a row for every profile currently in your bundle — including the ones you haven't tuned yet. Mark every single value (m) or (i). Most of the starter bundle will be (i). That's the correct answer and the point of the exercise.
A Fleet section: the three printer_model strings from Lesson 17, current firmware versions, and the date of each machine's last hardware change.
Export a config bundle into the repo and commit it alongside the log.
Finally, one paragraph: "The value in my current profiles I trust least is ___, because ___, and the measurement that would earn it is ___."

→ Paste it back to me. That last paragraph is the real assessment — and it's also your to-do list for the first Phase 2 session.

What you can now say

Two homes: the notes field for acting, the Markdown log for deciding what to trust. The log is append-only, because superseded values are signal.
Six fields, and colour is one of them — pigment moves flow within a brand.
Mark every value measured or inherited. That mark is what separates a measurement from a hypothesis.
A config bundle in version control makes drift diffable, including changes you made without meaning to.
Self-contained profiles owe you a periodic diff against the current system profile — the price of not inheriting.

📖

Primary source · read this next

Configuration and profiles — Prusa Knowledge Base

The hub for everything profile-related: where they live, how the wizard installs them, and how compatibility flags behave. Worth a skim now that you have somewhere to put what you learn from it.

💬 I'm your tutor — ask me anything. That's the end of the written course, which makes this the most useful moment to ask: paste me your log and I'll tell you which values I'd challenge and which machine I'd start Phase 2 on. From here the work is measurement, and I'm here for every session of it. Confused beats stuck.

Linked: Glossary → tuning log, config bundle, system profile, compatible printers condition, validation set, extrusion multiplier, Linear Advance, Pressure Advance, drying, one-variable rule, calibration order. Keep it close with → The Calibration Card.

§References

Prusa Research. How to import and export custom profiles in PrusaSlicer. The File → Export → Export Config Bundle path, and that a bundle contains all custom settings saved in the current PrusaSlicer version. Link.
This course. Master tuning guide, §1 — logging spool brand, colour, date, measured EM, advance value and MVS in the filament notes field, and that colour matters because pigment changes flow behaviour within the same brand. Link.

Lesson L19 of the prusa-profile-tuning course · all lessons · The Calibration Card · glossary