Getting Started with Mitsubishi PLC Programming: Common Mistakes & How to Avoid Them (By a Guy Who Made Them All)

Before You Wire a Single I/O Point

I've been handling Mitsubishi PLC orders for a training and distribution company for about six years. My first year was a masterclass in mistakes—I've personally documented 18 significant errors totaling roughly $14,000 in wasted budget across customer setups and internal demos. This article is my attempt to pass along the scars.

A quick note: this is based on my experience with the FX series (2N, 3U, 5U), the Q series, and the L series, as of early 2025. Mitsubishi updates GX Works software and firmware frequently, so always cross-check with your specific hardware revision and the latest programming manual (Mitsubishi Electric's own site is the best source, not third-party forums).

Common Mistake #1: Assuming Your PLC Model Matches Your Power Wiring

This isn't a 'choose the right PLC' guide—that depends on your I/O count and comms needs. But the mistake I see most often is people plugging in a 24V DC input model into a 100-240V AC mains without checking the power supply unit. The FX3U, for example, has a specific input power rating. I fried an FX3U-32MT on the second day of my first job because I was in a hurry. $680 down the drain, plus a 3-day wait for a replacement.

Here's how to avoid this:

• Scenario A (Standard AC mains, 100-240V): You need a PLC with an integrated AC power supply (like the FX3U-32MR) OR an external 24V DC power supply. Most FX models can be ordered as 'ES' or 'D' versions for different inputs. Check the part number suffix.
• Scenario B (24V DC system, e.g., in a vehicle or battery-powered setup): You can use a 'D' version of the FX directly... but be aware of the inrush current. Many cheap 24V power supplies can't handle the startup draw of a CPU plus I/O modules. I blew a 1.5 amp fuse in my test rig because I didn't realize that the L02CPU consumes more than just the base unit label says.
• Scenario C (Using a solar trickle charger as 24V source): This is trickier. A 'trickle charger' typically outputs a float voltage that's too high (13.6V-14.4V for a 12V system) for the PLC's 24V nominal. Don't assume it's regulated. I tested this in early 2022—the output on a cheap unit was 18V peak, which can damage the input circuitry of a 24V DC PLC. (Should mention: you need a proper 24V voltage regulator or a specifically designed industrial power supply, not a car battery charger.)

Common Mistake #2: Connecting Sinking vs. Sourcing Inputs Wrong

This one is almost a rite of passage. Mitsubishi PLCs, especially the FX series, have both sinking and sourcing input capabilities depending on the model's type. The common 'NPN' vs 'PNP' sensor confusion is the main culprit.

For the FX3U and FX5U:

• Sinking Inputs (FX3U-32MT/ES): The common (COM) terminal is +24V. The input turns ON when the signal from your sensor (or pushbutton) is pulled LOW (0V). This works with NPN sensors.
• Sourcing Inputs (FX3U-32MT/D): The common (COM) terminal is 0V. The input turns ON when the signal is pulled HIGH (+24V). This works with PNP sensors.

The mistake: buying a PNP sensor off the shelf and connecting it to a sinking input. I did this in September 2022 on a $3,200 order for a packaging line. The sensor signal was inverted, and the PLC read a '1' when it should have been '0'. The machine started a cycle prematurely. No one was hurt, but it cost us $890 in redo and a 1-week delay for new sensors.

If you're unsure, read the PLC's input manual for your specific model. It's always listed in the 'Wiring' chapter. Also, many FX5U models have configurable input types via the parameters in GX Works3, which is a huge improvement.

Common Mistake #3: Ladder Logic Errors That Wasted My Time (and Yours)

Your code works on the simulator but fails on the real machine. The most common issue? Scan time and 'state' reliance. I'm not going to give you a full programming tutorial (that's what Mitsubishi's manual is for), but these three pitfalls are the ones I see in 80% of support tickets.

The numbers said my logic was correct. My gut said something was off. Turns out the simulation in GX Works2 doesn't perfectly replicate the physical I/O refresh behavior on a Q series CPU with a large remote I/O rack.

• Scenario A (Standard, Continuous Operation): Use the 'main' scan time properly. Don't use FOR loops that take longer than the watchdog timer. I once used a 1000-iteration loop for a checksum calculation in an FX3U. The PLC tripped a watchdog error. Simple fix: break the loop into smaller chunks or use a different instruction.
• Scenario B (One-Shot or 'Edge' Detection): This is the classic. You have a pushbutton to start a sequence. You write 'LD X0 OUT Y0'. It sticks on because the PLC cycles through the scan faster than a human can release the button. The fix: use a one-shot rising edge instruction (PLS or PLF) or a self-holding (seal-in) circuit. I see this error in almost every first-time programming attempt.
• Scenario C (Using Timers Across Different Conditions): Mistake: using the same timer number in multiple rungs. By default, Mitsubishi's timers (T0, T1, etc.) are global. If you use T0 to control a delay for Motor A and Motor B, they conflict. This caused a machine to start two motors at once in my old employer's system. The result: a blown 10-amp fuse and a three-day production halt.

How to Diagnose Which Scenario You're In (And Not Just Blame the PLC)

I've caught 47 potential errors using this simple diag approach in the past 18 months:

1. Force the output: In GX Works, can you forcibly turn Y0 ON/OFF? If yes, your hardware wiring to the output device is correct. If no, check the COM terminal and the load's voltage.
2. Monitor the input: Are the X points blinking as you press the button? If the input LED doesn't light up, it's almost always a wiring or sensor type error (see Mistake #2).
3. Check the 'Device Memory': Is the internal relay (M0) turning ON but the timer (T0) not? That points to a logic error, not a hardware fault.

Take this with a grain of salt, but about 70% of 'dead PLC' calls we get are actually just a mis-wired 24V supply or a blown fuse on the DC power module. Check the fuses first—I've wasted hours on that (Source: personal experience, roughly $2,500 in wasted diagnostic time over 4 years).

Don't hold me to the exact number, but I've probably saved our team about $6,000 in rework this year alone by using this checklist. It's not glamorous, but it works.