Buy the Hardware, Write the Software

Two scenes

Hangzhou, today. A W/B4C multilayer is going down on a silicon wafer and nobody is in the room. The carousel turns under four magnetrons — three pulsed-DC supplies on the metals, two RF on the dielectrics — and the recipe is loading bilayer 14 of 30. Shutters fire in windows of a few hundred milliseconds: target shutter open, substrate shutter open, 7.4 seconds of W, substrate shutter closed, carousel rotates 90°, target shutter closed, the next supply ramps to its setpoint, B4C for 23 seconds, and again. One application orchestrates all of it. Thirty-two channels of telemetry — pressures, voltages, currents, gas flows, shutter states, carousel position — write to disk once a second. The supplies hold their setpoints. I’m at lunch.

Kharkiv, 2002. Same job, different century. Two MS-DOS PCs sat on a wooden bench next to the chamber, connected by a parallel cable. One drove the carousel and the shutters; the other handled the substrate-rotation steppers and the supplies. They synchronized through the LPT port — one machine pulsing a strobe, the other watching for it — because no single DOS box could bit-bang two banks of stepper motors through one parallel port and still keep its timing. The recipe lived in a Turbo Pascal program with the blue-on-cyan menus of Turbo Vision. I’d start it, hear the steppers chatter through the chamber wall, and watch the screen redraw in 80 columns while the deposition ran.

The chambers got bigger. The supplies got better. The substrate holders learned to cool themselves. None of that changed the question the software has to answer: which thing moves now, for how long, while which other thing is open. The architecture around the chamber is what changed — and most of what we learned, we learned the hard way. We tried to buy that architecture once, from a vendor with a turnkey recipe editor and a polished HMI. We came back and wrote our own.

That’s the story.

Two PCs and a parallel cable

The Kharkiv chamber is still there. Horizontal carousel, custom-built in 2002, retrofitted twice but the bones unchanged — still depositing samples twenty-four years on. Not a museum piece; running this week. Everything I believe about how deposition control should work I learned standing next to it.

The build budget had room for steppers, supplies, vacuum hardware, and two used PCs. It didn’t have room for proper motion controllers — cards that take a “go to angle X at speed Y” command and handle the pulse train themselves. So we did what people did in 2002 when the budget said no: we drove the stepper motors directly off the LPT pins. Each step pulse was a bit-banged write to the parallel port, timed in software. One DOS box could just about keep one bank in time if it did nothing else. Two banks — carousel and substrate rotation — were beyond it. Pulse trains collided, timing slipped, thicknesses came out wrong — and we usually didn’t know until the XRR fits came back a few days later.

So we split the work. One PC drove the shutter and the carousel. The other drove the substrate-rotation steppers and the supplies. They synchronized over the parallel cable between them — one machine raised a strobe line, the other watched the corresponding input pin and acted on the edge. Crude, deterministic, cheap. At the bottom of every synchronized-motion problem is a wire and a moment.

Kharkiv, 2002. Horizontal carousel, two MS-DOS PCs in the rack, an LPT cable between them. Still running.

The software was DepositionSystem 2 — a Turbo Pascal program with a Turbo Vision UI, the text-mode library that gave you IBM-PC-blue panels with cyan trim and pull-down menus driven by arrow keys. It had a recipe language: a flat list of commands the operator typed in or loaded from a file, walked top to bottom. deposit for so many seconds at such a power, move to such a position, wait until a condition. Software timers, not hardware ones. For 2002 it was genuinely capable — recipes you could read, edit, and save instead of a knob-and-stopwatch routine — but it was bounded by what the era gave you. DOS, single-tasking, no preemptive scheduler, every millisecond accounted for by hand.

The Turbo Vision menus are long gone. What survived from DepositionSystem 2 — what I’ve ported into every generation since, in three languages on three platforms — is the recipe model. deposit / move / wait as composable commands, executed in sequence, with hardware bindings swappable underneath. That abstraction was right in 2002 and is still right. It’s the spine of the software running in Hangzhou today.

For the next fifteen years, that was the only architecture I knew how to build — and no reason to think anyone built deposition control any other way.

The detour through Korea

In 2017 I started a new lab in the Republic of Korea. New country, new chamber, new assumption: fifteen years had passed since Kharkiv, and surely vendor automation had grown up in that time. The trade shows said it had. The brochures showed touchscreens, certifications, smooth front panels — all the visible signs of professional industrial gear that we hadn’t been able to afford on the Kharkiv build. I was ready to stop being the person who wrote the software.

The chamber itself was beautiful. A vertical-magnetron configuration optimized for Mo/B multilayers — the materials system you reach for when you’re chasing BEUV optics at 6.7 nm. The control system was a Weintek HMI: full-color touchscreen, a recipe editor with named steps, the whole package. And the touchscreen was, honestly, an upgrade. Operators stopped making keyboard typos at three in the morning. Shift handovers got cleaner — a new student could look at a screen and see what the chamber was doing without being walked through a Turbo Pascal menu tree first. Less training overhead. Real gain.

Korea, 2017. Vertical magnetrons, fresh chamber, fresh hope that this time we wouldn’t have to write the software.

Then we started reading recipes. The recipe editor had two verbs. Move the substrate. Move the shutter. That was the language. You could compose the verbs into sequences, name the sequences, save them — but the vocabulary did not extend.

The recipe editor. Move substrate. Move shutter. That was the language.

Chamber pressure was a knob on the front of the cabinet. During a run, the operator stood at the chamber and turned it, watching a gauge, holding pressure inside a window by hand. Not “set a setpoint and the controller holds it.” A knob. A hand. A gauge. For a four-hour Mo/B run, somebody’s afternoon.

The DC magnetron supplies were the same story. Power was set on the front panel of each supply — knobs and toggles, one supply at a time. No scripted ramp from the recipe. No programmed setpoint inside a step. If a sample called for 220 W on the Mo target and 180 W on the B target, the operator dialed both supplies in before the run and adjusted them by hand if the cathode voltages drifted.

And nothing was written down. Zero data channels logged. No telemetry trace, no run record, nothing on disk when the chamber stopped. The HMI had a touchscreen and no memory.

The HMI automated the easy half — motion. It left the chemistry to the operator.

That was the part that took the longest to accept. The recipe engine was the vendor’s, end to end. We couldn’t extend recipes to drive the supplies — the editor didn’t expose that surface. We couldn’t add a logging channel. We couldn’t modify the existing motion steps beyond what the dropdown allowed. We could file feature requests, and we did, and some of them came back six months later in a firmware update and most of them didn’t. After fifteen years of writing our own software, what surprised me wasn’t the limitations themselves — it was the loss of the ability to fix them. The keyboard didn’t help. The compiler didn’t help. The chamber was somebody else’s program now.

By the time we were specifying the next chamber, “we’ll just buy it” was off the table. Touch UX yes — that lesson stuck. Closed engine no. The next build would have a touchscreen, and underneath the touchscreen, source code we owned.

The chamber we run today

Hangzhou, 2021. New chamber, fresh build, and this time I knew exactly what I wanted underneath the touchscreen because the previous two had told me.

The geometry is conventional and deliberately so: four 150 mm magnetrons arranged around a horizontal carousel, an ion etch gun for substrate cleaning and pre-deposition treatment, a water-cooled substrate holder that doesn’t drift thermally over a five-hour run, and an airlock so the chamber doesn’t have to be vented to atmosphere between samples. Base pressure 1×10⁻⁷ Torr. Nothing here is exotic. The exotic part is what’s bolted to the side of it.

Five power channels feed those magnetrons — three pulsed-DC supplies for the metals, two RF supplies for the dielectrics. Every one of them is on the recipe bus. After Korea, that was the first thing we wrote into the spec for the next chamber: no front-panel knobs in the workflow, no operator standing next to a cabinet adjusting a setpoint while a run goes on. Power is a number in a script, ramped between values on the schedule the recipe demands, logged the entire way.

The software is a full Delphi rewrite — third generation now, third language, but the recipe model from 2002 is still recognizable underneath. deposit / move / wait came back and grew up. Supply ramps are scriptable. Shutter and carousel timing are scriptable. Recipes compose into longer recipes; there’s no length cap and no fixed step count. The operator sees a touchscreen, because the lesson from Korea on UX did stick. What’s different from Korea is what’s behind the touchscreen: source we own, an engine we can extend, a recipe vocabulary that grows when the chemistry asks for new verbs.

APS System Control. Recipe, chamber state, live telemetry — one screen, one app.

And it writes everything down. Thirty-two channels of telemetry — chamber pressure, voltage and current and delivered power on each of the five supplies, gas flows on every line, shutter states, carousel position — sampled once a second and written to a tab-separated file. About 1.5 MB of plain text per run. One application, one timeline, one machine. No parallel cable between two PCs trying to keep their clocks in step. No vendor middleware deciding which channels deserve to be exposed and which don’t. The Kharkiv chamber needed two computers because no single DOS box could handle the timing; the Korea chamber recorded nothing because the engine wasn’t ours to extend. This one is one process on one PC, and the log is the run.

The practical consequence is that you load a recipe, click start, and walk away. A 30-bilayer W/B4C stack for X-ray fluorescence optics is a five-hour deposition; the operator queues it and goes to lunch. The chamber holds setpoints, the supplies hold their power, the carousel rotates on schedule, and the log file grows by a row a second until the recipe ends. This software is what we now ship as APS System Control, sold via SWS Vacuum Technology. Every run we’ve done in this chamber since the build has left a complete record on disk — and we’ve kept all of them.

The substrate underneath

The 32 channels weren’t designed for posterity. They were a debugging tool — when a run came out wrong, you opened the log and looked for the moment something drifted. The reason we kept the files is mundane: disk was cheap and nobody had a reason to delete them. About 1.5 MB per run, one tab-separated file at a time, piling up in a folder nobody pruned. For the first few years they were exactly what they looked like — diagnostic exhaust from the chamber, occasionally consulted, mostly ignored.

One run, 32 channels, one second per sample. The artifact we never planned to keep.

Five years later, when a W/B4C series came back with XRR fits that wouldn’t agree even though the recipes and substrates were identical, I’d checked everything I knew to check and seen nothing wrong. So I asked Claude — through an MCP server we’d written for the lab notebook — to find what I’d missed. It found a 6% power-supply mismatch in the deposition logs. Minutes instead of days. That story is told in detail elsewhere; the part worth saying here is that it would have been impossible without the chamber underneath. The query that ran in seconds was reading rows that had been written, one per second, by a recipe engine running in Hangzhou three years before the question existed.

The thread runs in one direction. Deposition control made the chambers possible. The logs made the data possible. The notebook made the data findable. The AI made it queryable. Each layer assumed the one beneath was already there — and the bottom layer, the one nobody talks about at AI conferences, is a piece of software that started life on two MS-DOS PCs trying to keep step over a parallel cable.

The interesting work always sits on top. The substrate is what you write first.