How to Learn Mitsubishi PLC Programming: A 5-Step Checklist from Someone Who's Made Every Mistake

Who This Checklist Is For (And What It Solved for Me)

If you're staring at a Mitsubishi FX5U or a Q series CPU, and the manual isn't clicking yet, this is for you. Or maybe you're already a year in, but your programs have this habit of failing in weird ways that take two days to debug.

I've been handling Mitsubishi PLC training and support orders for about 7 years. In that time, I've made some genuinely expensive mistakes—$12,400 worth, to be precise, across about 30 significant screw-ups. This checklist is the result of systematically documenting every single one of those failures. It's five steps. Do them in order. You'll save time, money, and a lot of frustration.

Here's the thing: most training materials tell you how to do things right. They don't tell you what actually goes wrong when you try to do them. This list covers both.

Step 1: Get the Right Software (It's Not Just 'GX Works')

The first mistake I made—and I see it in new trainees constantly—is downloading the wrong software. Mitsubishi has three major programming environments:

• GX Works2 – For older series like FX3U, FX2N, Q series (AnS/QnAS), and L series.
• GX Works3 – For FX5U, FX5S, FX5UJ, and the new R series. This is not a newer version of GX Works2. It's a completely different platform. They do not share project files.
• GX Developer – Legacy. Avoid unless you're maintaining ancient equipment.

In July 2022, I watched a trainee spend an entire afternoon trying to open an FX5U project in GX Works2. He'd read 'GX Works' online and assumed. The error messages are cryptic—something about 'file format not supported.' He thought the file was corrupted. Re-downloaded everything. Three hours gone.

Checklist check: What CPU is on your PLC? If it's an FX5U, you need GX Works3. Full stop. Also, note that GX Works3 requires a 64-bit OS and at least 4GB RAM. I've had it crash repeatedly on a machine with only 4GB (note to self: stop recommending 4GB as 'enough').

Step 2: Hardware Setup—The Cable Trap

This is where most of my early budget went. You'd think USB is USB. Not with Mitsubishi PLCs.

For FX5U series: You need a USB cable (Type A to Type B mini). The FX5U uses a mini-USB port on the CPU itself. A standard USB printer cable works, but only if it's a 'mini-B' on the device end.

For FX3U/FX2N: You need the SC-09 cable (USB version) or an FX-USB-AW adapter. There's a cheap generic cable you can find online, but I've had connection issues with three different brands. The Mitsubishi branded one? $85. I went through $120 in generic cables before buying the official one. It worked first time. $85 saved me from a $33 'savings' that cost me a week of frustration.

For Q series: The Q series uses an ethernet connection. Setup is straightforward, but the IP must be in the same subnet. I once set mine to 192.168.0.10 when the PLC had a subnet mask on 255.255.255.0 but the gateway was 192.168.1.1. Everything looked correct. Nothing connected. Four hours.

Checklist check: Identify your PLC series. Order the correct cable. If you're using USB, try the official cable first. If you're using ethernet, verify the subnet mask matches your computer's settings. Don't trust the screen display—ping the PLC from command prompt to be sure.

Step 3: Learning the Basics (The Right Order)

Everyone wants to jump into complex programs. The conventional wisdom is 'learn ladder logic basics.' I agree. But here's what nobody told me: Mitsubishi PLCs use a specific approach to memory allocation that will trip you up.

Here's the progression I now recommend (and I learned this the hard way):

1. Binary logic: Ladder diagrams, basic timers (T0-T255), basic counters (C0-C199). Get comfortable with contacts and coils before anything else.
2. Integer math: MOV, ADD, SUB, MUL, DIV. Why? Because almost everyone needs to read a sensor value and convert it to engineering units. I spent 2 weeks trying to figure out floating point for that. You don't need it.
3. Comparison instructions: CMP, <=, >=, ==. This is where you start making decisions in the program. When the temperature sensor reads 100°C, turn on the fan.
4. Data registers: D0-D range, R registers for file registers. This is the memory you actually work with. Understanding addressing is key.
5. Subroutines and functions: CALL, P, and FB (function blocks). Only after you've handled the basics. I jumped into this too early and created an unmaintainable mess.

Checklist check: Start with binary, then math, then comparisons. Don't attempt function blocks until you've written at least 5 simple programs that work. The training path is sequential for a reason.

Step 4: Simulate Before You Download

This one sounds obvious. But in a real-world scenario, you're often on a deadline and you skip it. I've done this three times. Each time, I regretted it.

GX Works2 and GX Works3 both have built-in simulators. They run the program on your PC without a PLC connected. It catches a surprising number of problems:

• Timer values that are set to 0 (timer runs continuously = program hangs).
• Counter overflow (counter counts past max value = resets).
• Address conflicts (accidentally using the same memory location for two things).
• Logic that never exits (like a loop that gets stuck in a subroutine call).

In Q1 2024, I was testing a new program for a conveyor system. The simulator flagged a timer value of 'K0' (immediate execution, never resets). I'd missed it in 3 passes of the code. That one timer would have caused the conveyor to stop unpredictably. The fix took 5 seconds. The alternative? Probably a shutdown.

Checklist check: Enable the simulator. Run the program for at least 15 minutes. Watch the timer values. Watch the counter values. If the program has a loop cycle, run it through the simulator repeatedly until you're sure it works.

Step 5: Test on the Real PLC (The First 20 Minutes)

You've downloaded the program. Now what? Everyone I train wants to immediately press RUN. Don't. The first 20 minutes on the real PLC are about safety, not about how well your program runs.

Here's my routine:

1. Check input states: Turn on each input physically (switch, sensor, etc.). Verify the input LED on the PLC lights up and the software reflects the change. If a sensor is wired normally closed and your program expects normally open, this is where you'll catch it. Not after the machine starts moving.
2. Check output states: Manually force outputs one by one. Verify the external device (relay, motor starter, valve) responds. I once forced an output and nothing happened. The wiring was swapped. It took 30 seconds to fix, but if I'd started the program, it would have failed unpredictably.
3. Run in single-step mode: Most Mitsubishi PLCs can be set to step through the program scan by scan. Watch what happens. Does the timer count as expected? Does the comparison match the input? This is your last chance to catch errors without the machine running.
4. Run with manual override active: Set the PLC to RUN mode, but keep the manual/automatic selector in manual. The machine shouldn't move on its own. If it does, stop immediately.
5. First real run: Let it run one cycle. Watch everything. Then stop. Evaluate.

Checklist check: All inputs confirmed. All outputs confirmed. Run one scan step. Run with manual override. Then run one cycle. If any step fails, fix it before proceeding.

"In September 2022, I skipped step 2 on a $3,200 order of eight Q series CPUs for a packaging line. I'd checked the program thoroughly in simulation—the logic was perfect. But when I powered up the first cabinet, an output to the unload conveyor was locked on. That single error cost $890 in re-wiring and a 1-week delay. I've never skipped step 2 again."

Common Mistakes I Still See People Make

Even after 7 years, I'm still catching myself. But these are the three I see most often in new users:

• Forgetting to set the clock: Mitsubishi PLCs have a real-time clock. If your program uses timers that are date-based (like 'shut down at 6 PM'), the clock needs to be set. Every time you power cycle the PLC, it resets to factory default. Set it once, then make sure the battery is good. The default battery lasts 3-5 years, but I've seen them fail in 2.
• Overcomplicating the first project: I see people try to implement a complete SCADA system with PID control as their first project. Start with controlling a single relay. Then a sensor. Then two sensors. Then a sequence. Build up slowly.
• Not documenting the program: I've made this mistake more times than I can count. When you need to debug something a month later, good comments are a lifesaver. Poor comments are a false sense of security. I now require a comment on every rung in GX Works3. If it can't be explained in one sentence, the logic is too complicated.

Checklist check: Verify the PLC clock is set. Document the logic as you go. If you don't know what a rung does in 30 seconds, rewrite it.