If you have a dead elevator controller board and the OEM no longer sells it, an elevator control PCB copy is usually the fastest route back to a working spare. The lab traces the physical board, recovers the schematic and Gerber data, identifies every component, and — when the machine code matters — reads the firmware out of the MCU so a rebuilt board behaves like the original. Two to six weeks is typical, and the biggest variable is almost always the microcontroller, not the copper.
That’s the short answer. Below is what actually happens to the board, what we need from you, and where these projects get difficult.
What elevator control boards look like once you open the cabinet
Elevator electronics are unusual because one cabinet contains several very different board types, and people often ask for a “controller copy” when they mean one specific card in the rack.
- Main control / logic boards. Four to six layers, a 16- or 32-bit MCU, external SRAM or NVRAM, an RTC with a coin cell, EEPROM for parameters, RS-485 or CAN transceivers, and a lot of optocoupled I/O.
- Drive and inverter boards. Two-layer or four-layer with thick copper, IGBT gate drive, current sense, bus capacitors, and wide creepage spacing between the mains side and the logic side.
- Car operating panel and hall call boards. Often single- or double-sided, with LED drivers, membrane switch headers, and a small 8-bit MCU running a serial protocol.
- Door operator boards. Small motor drive, encoder input, sometimes a DSP or a dedicated motor control chip.
- Safety circuit and relay boards. Force-guided relays, redundant contacts, series safety chain wiring.
These boards are also old. It is normal to receive a 1990s or early-2000s card with through-hole logic, a masked-ROM part, and a silkscreen that has half worn off. That age is exactly why the work exists — and it changes how the job is planned.
Why the age of the board drives everything
Older elevator boards use conformal coating that has yellowed and hardened, electrolytic capacitors that have already leaked onto pads, and battery holders that have vented and eaten a trace or two. Before anyone traces a single net, the board has to be cleaned, the corrosion mapped, and any missing copper reconstructed from the surrounding geometry rather than guessed at.
The other age problem is parts. A board from 1998 will have at least a few line items that no distributor stocks. That means the copy job includes a real sourcing and substitution exercise, not just a BOM transcription.
How an elevator control PCB copy actually runs, step by step
- Intake and photography. Both sides shot at high resolution, connector pinouts documented, coating condition and any prior repairs recorded before anything is touched.
- Electrical check. If the board still powers up, rails and key signals are measured first. A working reference is worth a lot at verification time, and once components come off you don’t get a second chance at it.
- Desolder and component identification. Every part is removed, measured or read, and logged with package, value, tolerance, and voltage rating. Sanded-off or relabeled ICs get identified by pinout behavior and by what the surrounding circuit demands.
- Layer imaging. The bare board is scanned, then inner layers are exposed one at a time for multilayer cards. Vias, pad stacks, and drill sizes are recorded as measured values, not assumed ones.
- Netlist and schematic recovery. Copper images become a netlist, and the netlist becomes a readable schematic organized by function — power, MCU core, safety I/O, serial bus — rather than by position on the board.
- Continuity verification. The recovered netlist is checked point-to-point against the physical board. This is the step that separates a usable file set from a pretty drawing.
- Output generation. Gerbers, drill files, stackup, BOM, pick-and-place, and the schematic in an editable format.
- Rebuild and test. New bare boards, assembly, firmware programmed in, then bench and in-system testing against the original behavior.
Elevator work adds one step most copy jobs don’t have: the safety-related circuitry gets documented separately and deliberately. Series safety chain inputs, force-guided relay feedback paths, brake and overspeed monitoring — those nets are traced, cross-checked, and annotated on their own sheet, because that is where a transcription error stops being a nuisance and starts being dangerous. If your controller is part of a system covered by an inspection regime like EN 81-20/EN 81-50 or ASME A17.1, a copied board does not inherit the original’s certification, and any substitution in a safety path is a decision for your engineer of record, not for the copy lab.
Boards from other high-consequence sectors get the same treatment — the approach we use on elevator logic cards is close to what medical device board work demands, for the same reason: the failure mode isn’t “it stops working,” it’s “it hurts someone.”
The firmware question, which is where most projects live or die
Copper is the easy part. An elevator main board’s personality is in its MCU: floor tables, travel curves, door timing, fault logs, learned shaft data, and often a serial protocol nobody documented. Duplicate the hardware perfectly and load nothing, and you have a board that boots into an error state.
So the practical question is which of these applies to you:
| Situation | What the project looks like |
|---|---|
| You have the hex or binary from your own engineering archive | Hardware copy only. Cleanest and cheapest path. |
| Firmware exists only inside the chip, unprotected or lightly protected | Read out, verify against a second board if available, program the rebuilds. |
| Read protection is set (STM32 RDP, AVR lock bits, PIC code protect, MSP430 JTAG fuse or BSL password) | Feasibility assessment first, on the exact die revision. Outcome varies by part and by protection level. |
| Masked ROM or a fully locked modern part with a hardware root of trust | Often not feasible non-destructively. Time to talk about a functional rewrite instead. |
| Parameters live in an external EEPROM or NVRAM | That device gets read too — and it usually holds the site-specific configuration. |
Do not lose sight of that last row. On plenty of elevator controllers, the MCU firmware is generic across the product line and the thing that makes your unit yours sits in a 24Cxx or a battery-backed RAM. Copy the flash, forget the EEPROM, and you get a board that runs but doesn’t know your building.
Two honest points about protected chips. First, feasibility depends on the specific part number and silicon revision, so nobody who is being straight with you will promise an outcome before looking at the actual chip. Second, this is only a legitimate service when you own or are authorized to service the design — recovering firmware for equipment you maintain, or for a product whose source code your company lost. We ask you to confirm your rights before work starts, we run projects under NDA, and we decline requests aimed at competitors’ products.
What to send us, and what you get back
A useful quote takes about ten minutes of your time. Send:
- Clear photos of both sides of the board, whole board in frame, laid on a dark non-reflective surface, taken straight down with even light. Photograph the connector edge separately.
- Board dimensions in mm, plus your best read on layer count and board thickness.
- Close-ups of the main IC markings — MCU, any ASIC or gate array, memory devices, and the relabeled parts if there are any. This is the single most useful thing you can send.
- Model and manufacturer of the controller and the elevator, if you know them.
- Symptom description if the board is faulty, and whether you have a second working unit.
- One line on deliverables: files only, files plus prototypes, or a small production run.
Back from us: a feasibility read on the hardware, a separate read on the firmware if a locked MCU is involved, a lead time, a price, and a note on any component we already expect to be obsolete. If the MCU markings suggest a hard case, you hear that before you commit, not after.
What “deliverables” means in practice
Full file set: schematic in editable form, Gerbers and drill files, layer stackup with measured dielectric thicknesses, BOM with substitution notes, pick-and-place data, and the firmware image where recovery was in scope. Prototype tier adds assembled boards, tested. Production tier adds first-article inspection and repeatable supply. The instrumentation and test equipment work we do uses the same deliverable structure, so the vocabulary carries over if you’ve commissioned that kind of job before.
Where these jobs get hard, stated plainly
- Custom silicon. Some 1990s elevator platforms used gate arrays or house-numbered ASICs. The copper copies fine; the part cannot be bought. That turns into a redesign of that function block, or a hunt on the obsolete market.
- Potted or epoxy-covered assemblies. Encapsulated modules and heavily conformal-coated power stages need careful removal. Sometimes the coating comes off cleanly. Sometimes it takes pads with it.
- One-of-one boards with heavy corrosion. Reconstructing burned or leaked-away copper is doable, but with a single damaged sample and no working reference, verification confidence is lower. Two samples — one dead, one alive — is a materially better project.
- Locked modern MCUs. A recent part at its highest protection setting, with debug permanently disabled, may not be readable by any reasonable method. Then the choice is functional re-implementation, which is a longer and different kind of engagement.
- Undocumented bus protocols. If the copied board has to talk
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quoteRelated reading