Don't Use a Generic Mitsubishi PLC Instruction List

If you searched for a Mitsubishi PLC instruction list and opened the first PDF that came up, pause. The right list is not a generic list. It is tied to a specific CPU family, a specific CPU model, and the software version you are programming with.

Remember this: the most expensive instruction list is not the one with the most errors. It is the one that looks correct for your CPU but is not.

Why? Because Mitsubishi PLC covers more than one control platform. An FX3U is not an FX5U. A Q02U is not an iQ-R. An older A-series CPU is not a current MELSEC CPU. They share a brand name, and many instructions carry across, but the full instruction set and operand behavior need to match.

What I do and why instruction lists ended up in my review checklist

I am a quality and brand compliance manager at an industrial automation company. I review every program and handover package before it reaches a customer—roughly 150 deliverables per year. In our Q1 2024 audit, the surprise was not how many first submissions had problems. It was how many problems traced back to an instruction list that looked official but was not specific to the CPU.

I should be careful with the exact percentage. I do not remember it well enough to quote, and I do not want to invent a data point. The pattern was clear, though: wrong-reference issues appeared more often than logic errors.

It took me about 200 project reviews to understand what now sounds obvious: a Mitsubishi PLC instruction list is a compatibility specification, not a training handout.

I am not saying every engineer needs to memorize instructions. I am saying the moment you choose the reference, you choose the risk.

One project that made this a rule

In March 2023, I reviewed a machine upgrade package. The drawing said Mitsubishi PLC, and the engineer had worked from a summary labeled “Mitsubishi PLC instruction list.” The code compiled. Most instructions were fine. One instruction, however, was based on a manual that did not match the actual CPU model. I flagged it before delivery, and the engineer corrected it with a small program change. The surprise was how little it had to do with programming ability.

Before that project, I expected quality problems to be visible: wrong wire colors, missing terminals, poor documentation. The problems that hurt more are the ones that look right until the machine moves.

After that project, our program review checklist starts with the exact CPU model and software version before we look at a single rung of logic.

Where generic Mitsubishi PLC instruction lists go wrong

A Mitsubishi PLC instruction list is a snapshot of available operations and operand ranges for a particular CPU family. Basic contacts, coils, MOV instructions, and comparison instructions show up across many models. But “shows up” is not the same as “behaves identically.”

Even within one family, a lower-cost CPU may have fewer available instructions or different operand limits than a higher-performance CPU. The search result does not know which one you have.

Let me rephrase that: instructions are execution contracts, not just mnemonics. The contract defines which operands are allowed, how pulse execution works, how data types are handled, and whether an instruction can be used on a specific CPU at all.

If the list you are using does not say which CPU family and software version it covers, treat it as a clue rather than a source. It might be 80 percent right for your machine. The missing 20 percent is what causes the expensive call.

The same problem appears in internal wikis. A document gets labeled “Mitsubishi PLC instructions” because it was correct for one machine. Later, someone applies it to a different CPU because the brand name matches.

How I verify an instruction list before approving a project

When I approve a project, I do not look for the most impressive programmer. I look for the easiest way to prove the code will run on that CPU. The instruction list is part of that proof.

1. Confirm the exact CPU model, including the suffix. FX3U, FX5U, Q02U, R08CPU, and older QnAS CPUs do not all share the same instruction rules.
2. Confirm the programming software and version. GX Developer, GX Works2, and GX Works3 are not interchangeable when you are looking up instruction behavior.
3. Use the manual for that CPU family. Start with Mitsubishi Electric's FA documentation. If a PDF has no CPU family label, treat it as suspect.
4. Diff migrated code against the old and new instruction reference. This catches instructions that changed behavior instead of instructions that are obviously missing.
5. Lock the verified reference into the project file. Then the next engineer who opens the project does not have to search for the same list again.

The compiler catches some mismatches, but not all. A CPU can accept an instruction and still process it according to a different operand rule. Reviews should not stop at “does it compile.”

The cheap source becomes the expensive source

Here is where I sound like a quality person instead of a salesperson: choose the instruction list the way you would choose a critical spare part, not the way you would choose a PDF download.

A free list from a forum or an unlabeled copy in an old file folder can be correct enough. But when it is not correct, the cost appears in engineering hours, commissioning delays, and reworked documentation. The price of the source is the smallest number in that equation.

I remember one support call where an engineer spent hours chasing a machine fault. The cause was a list from a source that looked close but had the wrong timer range for the actual CPU. The engineer changed one instruction and the fault disappeared. Hours for one line is a bad trade.

That is why I argue against the cheapest source, not against saving money. A verified source is not overhead. It is insurance for the commissioning schedule.

Boundary conditions and honest exceptions

If you are an experienced technician and you only need to understand what one instruction does on a machine you already know, a quick reference card can be enough. The warning is for new code, major migrations, and sign-offs. Those need a verified source.

This warning is loudest for migrations from an older A-series or QnA CPU to a current platform. It is dangerous to assume every instruction will behave the same way after a platform change.

An instruction list is also not a substitute for machine safety work. If a machine trips, moves unexpectedly, or seems dangerous, stop and check the hardware, wiring, guards, and emergency-stop chain before you blame the program.

And no generic article—including this one—can approve your project. That responsibility belongs to someone standing in front of the machine, with the actual CPU model and the actual manual open.