Backing Up Mazatrol Programs to a PC: The CMT Transfer Discipline

The parameter and battery guide covers the scary half of this subject: on older Mazatrol controls, memory is battery-backed, and when it goes, your parameters take your programs with them. This page is the programs' half — how to get Mazatrol programs off the control and onto a PC, what a real backup contains, and the habits that separate "we have backups" from "we discovered what our backups were worth during a crisis."

I spent 19 years at Mazak Corporation as an Applications Engineer. I've stood in shops that lost a decade of proven programs in one weekend power event, and shops that shrugged off the same event because somebody did this work on a quiet afternoon.

How CMT transfer works, in principle

On the T-Plus, T-32, and Fusion 640 generations, program transfer runs through the control's CMT / I/O functions over an RS-232 serial connection to a PC running communication software. The control sends; the PC receives and saves the program as a file. The transfer can run in both directions — which matters, because sending a program back into the control is how you prove the whole chain works.

The entire game is agreement. The communication settings on the control side and the PC side must match — every shop that has fought a transfer that produces garbage or nothing has fought a settings mismatch, a wrong cable, or both. On the cable: a plain serial cable is frequently not the right cable; these connections typically need a null-modem configuration, and "it fits" is not evidence it's wired correctly.

I am deliberately not printing setting values here, because the right values depend on your control generation and your PC software, and a number copied from a web page for a different control is worse than no number. The discipline that works is this:

1. Get one transfer working, in both directions. Send a program out, save it, clear it from the control if you can afford to (or use a scratch program), and send it back in. A backup you've never restored is a hypothesis.
2. Write down what worked — the settings on both ends, which cable, which port, which software — and keep that record with the machine. The next transfer may be done by a different person, under pressure, at the worst possible time.
3. Repeat the round-trip after any change — new PC, new cable, control service — because the chain you verified is the only chain you have.

What a complete backup set includes

Programs alone are not a recovery. If a control loses its memory, you need the machine back to the state where those programs run as proven — which means the backup set for each machine should include:

• Programs — every stored program, not just the current job
• Parameters — the complete parameter set, per the battery guide
• Tool data and offsets — the descriptions and values the programs were proven against (a program without its tool data is half a backup)
• Work offsets and machine data the control allows you to output

Back up when the machine is in a known-good state — ideally right after a successful run of important jobs, and again before any service work, battery replacement, or control work begins.

Storage discipline: where backups go to die

The failures I see are rarely transfer failures. They're filing failures:

• Label everything by machine, control, and date. "QT250 final backup" on an unlabeled drive helps no one at 6 a.m. on a Monday. The file should say which machine, which control generation, and when it was taken. Machine serial in the folder name is not overkill.
• Keep a copy off the machine's PC. A backup that lives only on the laptop next to the machine shares that machine's fate in a fire, flood, or theft. A second copy somewhere else — office server, cloud folder, a drive that goes home — is the difference between a setback and a loss.
• Date discipline beats volume. Ten undated backups are worse than two dated ones, because nobody can tell which represents the last known-good state. When you take a new backup, the old one gets archived with its date, not overwritten anonymously.
• Used machine? Back it up the week it lands. Before you change anything, capture the machine exactly as it arrived — programs, parameters, tool data. Machines bought used rarely come with documentation, and the as-received state is the only baseline you will ever have.

Newer controls are not exempt

Matrix, SmoothG, and later controls offer removable media and network options that make transfer easier than RS-232 ever was. Easier is not the same as done. The failure mode just changes: programs living on one USB stick, in one drawer, unlabeled — or on the control and nowhere else because copying them was always a task for later. The discipline above is media-independent: round-trip verified, completely labeled, duplicated offsite, refreshed when the machine's state changes.

An afternoon of transfers and labeling buys you the ability to treat a memory loss as an inconvenience. Without it, the same event is a week of downtime and a program library rebuilt from memory — the expensive kind of nostalgia.

When something on a Mazak lathe isn't working

I do this for a living. If you have Mazak lathes with no verified backups, a used machine that arrived with no documentation, or a transfer setup nobody has ever gotten to work, send me the part, the machine, and the control version. I'll tell you what's possible.

Thank you, Tom Herzog