The Day I Wasted a Week (and $5,400) on an Omron PLC Configuration
It was a Tuesday—September 14, 2021, to be exact—and I was staring at a brand-new Omron Sysmac NJ501-1500 controller, fresh out of the box. The project was a mid-sized packaging system for a food processing client. Simple enough: a conveyor line with a few sensors, actuators, and a labeling station. I’d done this kind of thing before, but this was my first full project using the NJ series and Sysmac Studio version 1.50.
I’ll spare you the sales pitch: Omron’s PLCs are solid. I’ve used CP1L and CP1H for smaller jobs, and CJ series for medium-scale stuff. But the NJ series? That’s where things get interesting—and painful if you’re not careful.
What I Thought I Knew (and What I Was Wrong About)
Here’s something most vendors won’t tell you: even experienced PLC programmers often confuse “motion control” capability with “basic programming logic.” They’re not the same thing. When I started the project, I assumed that because the NJ is part of the Sysmac family, its basic logic would behave identically to the CJ series I’d been using for years—or rather, I assumed they were interchangeable for simple I/O control. Actually, the NJ uses a fundamentally different architecture for motion control axes—and the way you configure tasks in Sysmac Studio changes how your ladder logic executes.
What most people don’t realize is that the “basic programming logic of Omron PLC” isn’t a single thing. It depends on the series. The CP1 processors use a simple cyclic scan. The CJ2 series adds priority task scheduling. The NJ? It runs on a real-time OS with EtherCAT—and if you don’t configure your periodic tasks correctly, your logic might not execute when you expect it to. That is what caught me.
The Setup: Hardware and Software
I’d configured the system with an Omron NJ501-1500 (the motion controller with 4 axes), an EtherCAT coupler, and a handful of NX-series I/O modules. The programming environment was Sysmac Studio version 1.50. My goal was to create a basic sequence: start conveyor, wait for sensor, label products, stop for jams, resume. Standard stuff.
- Controller: NJ501-1500 (motion control version)
- Software: Sysmac Studio 1.50
- I/O: NX-series digital-in/digital-out modules
- Network: EtherCAT for motion, EtherNet/IP for HMI
I’d used a similar I/O configuration on a CP1L project three months prior—the one that went perfectly, so I thought: “This should be easier, since the NJ is more advanced.” No, wait—that’s exactly the kind of overconfidence that gets you.
The Mistake: A Missing Task Configuration
In Sysmac Studio, programs are assigned to tasks. Each task can be set to run at a specific cycle time or priority. I’d created my main sequence in a program called “MainSeq” and assigned it to the default “PrimaryPeriodicTask.” Standard practice, right?
The problem was that I also had a secondary safety check—a pressure sensor that needed to stop the conveyor if it exceeded a threshold. I put that logic in a separate program called “SafetyCheck.” But I forgot to set its task priority correctly. Actually, I set it to “Low” thinking it wouldn’t matter—or rather, I didn’t set it at all. I left it at the default “Normal” but the system assigned it to the same task as the main sequence.
Here’s the insider knowledge: In the NJ series, if you put multiple programs in the same periodic task, they execute sequentially in order of declaration—not in parallel. My safety check ran after my main sequence in the same cycle. If the main sequence set an output that the safety check wanted to override, the override wouldn’t take effect until the next cycle. And if the cycle time was short enough—maybe 1ms—the safety check effectively never got a chance to stop the conveyor in the same cycle that the fault occurred.
On my test bench, I simulated a pressure spike. The safety check saw it. But it didn’t stop the conveyor because the main sequence had already set the output in the same cycle. We caught the error when the test conveyor jammed—audibly—and the safety check tripped a cycle late. I thought it was a sensor timing issue. It took me three hours of debugging to realize the real problem. (Facepalm.)
The Consequences: Real Costs, Real Delays
That error—just one wrong task assignment—caused:
- 3 days of troubleshooting (thinking it was a wiring issue)
- 1 day rewriting the safety logic into a separate periodic task with higher priority
- Roughly $4,800 in engineering time plus the cost of a replacement sensor that we’d accidentally damaged during testing (roughly $600—not that we bill that separately, but it’s a real number)
Total waste: about $5,400 for my first NJ project. Plus the embarrassment of explaining to my manager why the schedule slipped by a week.
What I Learned: The Real Basic Logic of Omron Sysmac PLCs
After that disaster—and after the third rejection in Q1 2024 of a similar configuration I reviewed—I created a pre-check list for Sysmac Studio projects. Here are the lessons that stuck:
- Tasks matter more than you think. The NJ series uses a real-time OS. Each program must be explicitly assigned to a task with the correct priority and cycle time. If you want safety logic to override main logic, put them in separate tasks with the safety task at a higher priority.
- Parallel execution is an illusion. Programs in the same task run sequentially. If your logic depends on reading an output status within the same cycle, you need to plan for the execution order.
- Document your task configuration. Sysmac Studio lets you name tasks—use that feature. I now include a task diagram at the start of every project.
- Test edge cases. My test sequence worked when everything was normal. But I never tested what happens under extreme timing conditions. Now I always simulate worst-case cycle times.
- Read the manual—seriously. Omron’s NJ-series Sysmac Studio User’s Manual (Cat. No. W614) has a chapter on task execution. I read it after the failure. It spells out exactly what I got wrong. Take this with a grain of salt, but in my experience, the official Omron documentation is excellent—if you take the time to read it before you start.
Why This Matters for Anyone Learning Omron PLC Logic
Here’s the thing: when you search for “the basic programming logic of Omron PLC,” most results show you how to create a ladder diagram or a structured text function block. They don’t warn you about the architecture differences between series. They assume you’ll figure out the task model on your own. In my opinion, that’s a gap in the training content available online.
AtOmron, we actually do offer training classes that cover these nuances—the Sysmac Basic course, for example, walks through task configuration. I’d rather spend 20 minutes explaining this upfront than have another engineer repeat my $5,400 mistake.
Final Thought: An Informed Customer Asks Better Questions
If you’re new to Omron PLC programming—or even if you’ve used CP1 and CJ series for years—don’t assume the NJ series works the same way. The hardware is different. The software is different. The programming logic is fundamentally the same (AND, OR, Ladder, ST), but the execution model is not.
I’ve made that mistake so you don’t have to. Now go configure your tasks correctly.
