Will My Program Survive the Repair? (Yes — Here's Where It Actually Lives)

The most common question we get isn't about price or turnaround. It's some version of: "That terminal runs the machine. If I send it out, do I lose the program?"

Short answer: no. Physical repairs — touch glass, backlights, power supplies, power stages — don't touch application storage. But the fear deserves a real answer, so here's where your program actually lives, platform by platform.

HMIs: the application is in flash, not in the failing parts

• Allen-Bradley PanelView Plus (6 & 7): the FactoryTalk View ME runtime (.mer) lives in internal flash or a CF/SD card. The parts that fail — digitizer, backlight, power supply — are physically and electrically separate from that storage. A touch repair no more erases your screens than replacing a laptop's cracked glass erases its hard drive.
• Siemens Comfort/Basic/Multi Panels: the WinCC runtime project sits in internal flash (plus optional SD). The classic Comfort Panel failure is power-supply capacitors — a board-level repair that never writes to project storage.
• Pro-face, Mitsubishi GOT, Omron NS/NB: same architecture, same answer — project in flash/CF/SD, failures in glass/backlight/power.

Memory cards: if your application lives on a removable card, you can keep the card when you ship — we test with our own media. If the only copy lives in the unit, say so on the intake form; imaging it before any work is standard practice for us anyway on data-carrying units.

Servo drives: parameters mostly live upstream

• FANUC: servo and spindle parameters live in the CNC control, not the amplifier. A repaired amp reinstalls without reprogramming in nearly every case.
• Mitsubishi MR-J series: parameters sit in the amplifier's protected EEPROM — separate from the IPM and power circuits that fail. Repairs preserve them; we verify the parameter set is intact at final test.
• Yaskawa Sigma: same story — protected parameter memory, untouched by power-stage work.
• Indramat/Ecodrive: the special case, handled specially — firmware and parameters ride on a plug-in firmware module. It stays physically with your unit through our whole process; we never separate them.

PLCs: the program is in the CPU — which is exactly why we repair around it

PLC programs live in CPU memory (battery-backed or flash). The components we repair — rack power supplies, I/O modules, comm modules — carry no program at all, so those repairs are zero-risk to your logic. For CPUs themselves we're blunt: keep your offline project backup current regardless of anyone's repair promises, because a CPU that dies hard takes its memory with it no matter who's holding it. (And verify your battery-replacement procedures on legacy families — more programs are lost to dead batteries during a casual swap than to any repair bench.)

What a professional lab does that protects you further

1. Intake notes travel with the unit — "application only exists in this terminal" changes how it's handled from minute one.
2. Data-bearing units get imaged before work where the platform allows.
3. Nothing is reset or restored to defaults unless the repair strictly requires it — and then only after the image exists and you've been told.
4. Functional test proves the application — an HMI leaves our bench booted into your screens, not a test pattern.

The one thing to do on your side

Whatever you send anyone: keep your own offline backups current. The .apa/.mer for your PanelViews, TIA project for Siemens, drive parameter files, PLC project files — on a server, dated. Not because the repair threatens them, but because the failure someday might. The units that scare their owners most are the ones where the only copy of the program is inside the thing that's smoking.

Repair preserves your program. Backups make it so nothing else can lose it either.