The Omron PLC Series Checklist I Use Before Specifying a Controller

I'm a controls engineer. For the past six years, I've handled automation orders for a distributor and systems integrator. In that time, I've personally made and documented 11 significant mistakes that added up to roughly $40,000 in wasted budget. That's my way of saying I've ordered the wrong PLC parts, missed specs, and paid for it. This checklist is how I prevent those mistakes now.

If you've ever specified a PLC and realized later that the pulse output frequency was too low, you know the feeling. Trust me on this one: writing it down works. Here's what you need to know before choosing an Omron PLC series.

The 7-Step Checklist

Step 1: Count the Real Requirements First

Before you look at models, make a table. Not in your head. On paper or a spreadsheet. List discrete I/O, analog channels, high-speed counters, pulse outputs, motion axes, and communication protocols. Seriously, check the pulse output requirement before you order.

I only believed the advice to check every output after ignoring it once. In 2019, I ordered 14 CPUs for a packaging line. The I/O count was fine. The CPU model was fine. But I didn't check the pulse output requirements, and every unit had to go back. The Omron PLC pulse output maximum frequency is not a single number across the product line. On the CP1L and CP1H, some pulse outputs are rated up to 100 kHz. On NX position interface units, the limits are different—and often higher. If your servo drive needs 500 kHz and you choose a CPU with a 100 kHz ceiling, no amount of programming will fix that.

Step 2: Match the Series to the Workload, Not to Habit

The Omron PLC series lineup is broad, which is a good thing. CP1L and CP1H cover compact control. CJ2 handles medium-speed logic and analog. NX and NJ are for machine automation and EtherCAT motion. As of February 2025, all of these are still active in distribution. But that doesn't mean you should pick the one you used last year.

I don't have hard data on how often wrong series selections happen, but based on our quoting log, my sense is it's roughly one in five resubmissions. If you need coordinated motion, don't force a compact PLC to do it. If you need a simple sequence, don't buy a motion controller and pay for software you won't use.

Step 3: Map the Communication Protocols Before Choosing the CPU

List every device that will talk to the PLC: HMI, VFD, barcode scanner, SCADA, solar inverter. The solar one is more common than you might think. A customer asked me recently whether an Omron PLC could monitor his solar panel micro inverter. The answer was yes, because that inverter supported Modbus RTU over RS-485. If it had only offered cloud API access, we would have needed a gateway, and the cost would have gone up.

So before you order, ask: what protocols do I need? EtherNet/IP? EtherCAT? Modbus TCP? Serial? The Omron PLC series has options for all of these, but not every CPU has every port built in. Missing this detail means adding converters and extra programming hours.

Bottom line: communication mapping is not a detail you can fill in later.

Step 4: Decide the Safety Architecture Up Front

If a machine needs a safety-rated stop, light curtain monitoring, or safe torque off, decide that before you select the CPU. Adding safety later means redoing the wiring plan, the BOM, and the program structure.

I've used separate safety PLCs when the customer's spec named a specific product, like a Pluto safety PLC for the safety circuit. I've also used Omron NX-SL safety modules over EtherCAT. I'm not going to tell you one is always better than the other. The right choice depends on the machine, the safety level, and the team's familiarity. The key is to make the choice early.

Step 5: Compare Total Cost, Not Unit Price

This is the step I'm most tempted to skip. I used to compare CPU prices and pick the cheapest one that met the specs. Then I chose a controller with a 12-week lead time because it was $200 cheaper. We ended up paying $1,500 in expedite fees and overtime to get the project back on schedule. That $200 saving turned into a $1,500 problem.

My rule now is to compare total cost of ownership. Include the software license, training, spare parts, programming cable, and the cost of downtime. This is also how I answer the what is the best home generator question that customers occasionally ask. The best generator for someone off-grid is different from the best one for occasional outage backup. Same goes for PLCs. Per FTC guidance on advertising claims, 'best' needs evidence—and your evidence should be total cost, not initial price.

I'm not saying the lowest quote is always wrong. I'm saying you can't know until you calculate the cost to install, commission, and maintain. That's a lesson I learned by ignoring it once.

Step 6: Build in Memory Headroom

Program memory and data memory are not the place to save money. I once approved a CPU with exactly enough memory for the current program. It looked fine on paper. Then the customer added two recipe variants and a reporting block, and the CPU said 'insufficient memory.' We had to swap to a larger series, rewrite the program, and re-test. It cost roughly $6,700 and a week of schedule.

Now I specify 30 percent memory headroom minimum. It feels wasteful at the time. It isn't. The day you need it, it's a no-brainer.

Step 7: Test the Pulse Output With the Real Equipment

The last step is the one I hate, because it requires actual hardware and time. But it's non-negotiable. The datasheet tells you the Omron PLC pulse output maximum frequency under ideal conditions. In the real world, you have cable capacitance, electrical noise, and a specific servo or stepper driver input. That changes everything.

Honestly, I'm not sure why maximum output specs are so rarely quoted with load and cable conditions. My best guess is those numbers come from clean lab setups. So I test on the actual driver, with the actual cable length, before I approve the design. Take it from someone who watched a machine skip steps on a 200 kHz command because the cable run was too long. The PLC did its job. The wiring killed it.

Common Mistakes That Still Show Up

• Assuming every unit in a series has the same pulse output capability. Check each model number.
• Treating safety as an optional add-on. It's an architecture decision.
• Comparing prices without comparing lead times. Late parts cause way more damage than a slightly higher price.
• Forgetting software licenses. On one project, the license cost more than the CPU itself.
• Ignoring the real maximum frequency under load. That spec is a starting point, not a guarantee.

A quote that comes in 20 percent below everyone else is a red flag until you understand why. It could be a legitimate volume discount, or it could be a clue that a requirement was missed.

The Short Version

1. Count every I/O, pulse output, high-speed counter, and analog channel.
2. Pick the series that matches the workload, not last year's project.
3. Map every protocol.
4. Decide safety before ordering.
5. Calculate total cost.
6. Leave 30 percent memory headroom.
7. Test pulse output frequency on the real driver and wiring.

This checklist has saved us a ton of time and money. I still make mistakes—but not the same ones. This checklist won't make you perfect. It will, however, catch the expensive stuff before it ships. Take it from someone who learned the hard way.