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

All posts →