workflow ·
Forty Minutes Before You Learn Anything
The work between a log landing on your desktop and the first useful plot is paid per file, repeated every session, and thrown away at the end of it.
By Blankplots Team · 4 min read
On This Page
A log file arrives from the shared drive. Before it can tell you anything, it has to be made presentable, and every engineer who works with equipment logs knows the sequence by heart.
The Ritual
Open the file in a spreadsheet. Watch it stall, or refuse outright, because the row count is past what the grid will hold. Split it, or give up and open it somewhere else. Find that the timestamp column came in as text, and fix that. Skip the header block the tool writes before the data starts — a different number of lines than last time, because the firmware was updated in between. Work out which of the several hundred columns are the four you care about, from names that are abbreviations of abbreviations. Delete the rest, or hide them. Build the chart. Fix the axis, because the default put six weeks on one screen. Now, finally, look at it.
Call it forty minutes. Some days twenty, some days the whole morning if the file is unusual. None of it is analysis. It is the toll you pay at the gate, and the moment you have paid it you are exactly where you thought you were when the file arrived: looking at one run, on one chart, wondering whether it is normal.
The Part That Doesn't Amortize
If this were a one-time cost it would barely be worth writing about. Anyone would spend forty minutes to set up a working environment they then used for a month.
But the cost is charged per file. The next log gets the same treatment, and the one after that. Nothing you learned about the first file's layout carries forward, because the knowledge lived in a sequence of manual actions rather than anywhere the tool could keep it. Close the session and it is gone.
That is the direction the cost scales, and it is the wrong one. The questions worth asking are almost never about one run. They are about a dozen wafers from the same lot, or the same recipe on two chambers, or six weeks of the same step to see whether a drift is real or a story you are telling yourself. Every one of those questions is a multiple of the toll.
Three Runs Is A Budget, Not A Conclusion
Here is the consequence, and it is the part worth being uncomfortable about: the number of runs an engineer looks at is usually not set by what the investigation needs. It is set by how much file preparation they can stand before the day gets away from them.
Three runs is a common answer. Three runs is also, frequently, not enough to distinguish a real excursion from ordinary spread — but it is what fits in the time available, so it becomes the evidence base. The decision that follows gets made on it. Nobody in that chain is being careless. The tooling quietly set the sample size, and then the engineer wrote up what the sample showed.
When someone says a tool is slow, this is usually what they mean. Not that the chart takes a long time to render. That the cost of looking at one more run is high enough to argue against looking.
What Should Have Been Saved
Almost everything in the ritual is a description of the file, not a decision about the analysis. Where the data starts. Which column carries the timestamp and in what format. Which column's value marks the boundary between one run and the next. Which columns are worth plotting by default. How far into a step to start measuring, so a startup transient doesn't contaminate the statistics.
Those are stable facts about a file format, and a given tool writes the same format for years. They should be stated once, saved as a reusable profile, and applied to every file of that shape from then on — including by the colleague who receives the same export next week and would otherwise derive all of it again from scratch.
That is the whole of the fix, and it is unglamorous. There is no faster parser that solves this, because parsing was never the slow part. The slow part was that a person had to re-explain the file to the software every single time they opened one. Do that once instead, and the forty minutes becomes the time it takes to drag the file in — which is the point at which an engineer can afford to look at twelve runs instead of three, and let the evidence, rather than the calendar, decide when they have seen enough.
Continue Reading
A Plotting Tool Should Know What A Recipe Step Is
Feature count is the wrong axis to judge a tool on. The question is whether it knows your domain, or makes you re-encode it from scratch every session.
· 4 min read
Your Workflow Is The Spec
We build narrow on purpose, which only works if the narrowness matches what engineers actually do. When it doesn't, we would rather hear it than not.
· 4 min read
Everything Your Best Engineer Knows Is On Their Laptop
A service organization's diagnostic history sits on individual hard drives. That is not a filing problem — it is a business running on memory it does not own.
· 3 min read