In my role as the person who gets called when nobody else can make a deadline, I've done a lot of rush work. Same-day turnarounds for commercial HVAC clients, overnight programming for a packaging line, all of it. This was one of the ones I remember.
It started with a phone call at 4:37 PM on a Thursday in March 2024. I was already shutting down my laptop, because I'm old-fashioned that way, when our distributor called.
"The boatbuilder needs a Cruisair control panel tied into an Omron PLC by Saturday morning. They've got a sea trial. You have 36 hours."
Normal lead time for integration like that is two weeks. They wanted custom mapping between the marine AC panel and the PLC, plus alarms at the helm display. The client's alternative was worse than overtime: a missed sea trial and a $50,000 penalty clause in their build contract.
I said yes. Honestly, I wasn't sure we could do it.
Not the PLC I expected
The Cruisair control panel had a Modbus RTU interface. Omron's classic CP/CJ PLCs have built-in Modbus RTU instructions, and my first instinct was to use a CP1H. But the distributor only had an NX102 in stock. The NX series is where Omron has been moving tag-based programming, and the NX102 handles EtherNet/IP natively. Modbus RTU isn't a built-in serial port on that CPU, so we used a small external gateway between the Cruisair panel and the NX102. According to the NX-series documentation, this is a standard way to bring third-party serial devices into Sysmac.
So the Omron PLC series choice pivoted from "what I know" to "what's on the shelf." And honestly, the NX architecture was better for the rest of the project. We could map the AC data into tag names like "AC_Zone1_Status" instead of wrestling with memory addresses.
Even after choosing the NX102, I kept second-guessing. What if the gateway didn't initialize in time? What if the slave address was different from what the manual said? The 36 hours until the sea trial were stressful.
The Omron PLC communication protocol that wasn't
After setting up the port—9600 baud, 8 data bits, no parity, one stop bit, slave address 1—I ran the Modbus poll. Nothing.
I checked the cable with a multimeter. The adapter showed TX/RX activity. Still nothing.
Then my colleague, who'd joined from a van outside the shipyard, asked the kind of question that eats up a Friday morning: "Where is the Control Panel in Windows 11? I can't change the COM port settings on this new laptop." It wasn't a dumb question. Microsoft hid the legacy Control Panel in Windows 11. You have to press Win+R and type
control. We lost twenty minutes to that interface.
But the PLC still wasn't talking to the Cruisair panel.
From the outside, this looked like a communication protocol problem. The reality turned out to be far less elegant.
The outlet that broke the sea trial effort
By Friday morning, I was staring at a Modbus register map and wondering if I had the wrong function code. That's when the facility manager walked in and said, "Is that power supply supposed to wiggle like that?"
The little 24V power supply for the NX102 was plugged into a wall outlet that had a loose fit. The voltage at the PLC was around 21.5V and flickering, which explains intermittent comms failures. We had to replace the receptacle, and that's how an urgent, high-tech PLC integration became a lesson in how to change an electrical outlet.
If you've never had to ask how to change an electrical outlet while carrying a PLC program, you haven't done field automation yet. The steps are simple:
- Turn off the breaker and verify the circuit is dead.
- Remove the faceplate and the two screws holding the outlet.
- Disconnect the wires, transfer them to the new outlet, and screw it back in.
- Test the outlet and reapply power.
The whole fix took about twenty minutes. The voltage stabilized, the Modbus polling came alive, and suddenly the Cruisair control panel was talking like it had been waiting for us.
One note for anyone working near a dock: the receptacle has to be GFCI-protected. That's not a suggestion. Under the National Electrical Code (NFPA 70), receptacles near water need ground-fault protection. It's one of those rules you're very glad exists after a PLC loses its ground reference in a wet boatyard.
What saved the deadline
Once the outlet was fixed, the integration moved fast. We mapped the AC's mode, setpoint, room temperature, and alarm status into NX102 tags. The EtherNet/IP link published those tags to the helm display, and the client tested the local HMI from the pilothouse. The boat went to sea trial on Saturday morning.
We delivered in 31 hours, with a 5-hour buffer. The client's alternative was a $50,000 penalty from the boat buyer and a warranty black mark. Instead, they got a working marine AC control system and a PLC backbone that will let them add more sensors later.
What I'd tell my younger self
It took me six years and more than thirty emergency calls to understand that the protocol is rarely the problem. The problem is power, wiring, and user interfaces. I only believed in checking the physical environment first after ignoring it once, spending three hours chasing a Modbus address, and later finding a loose neutral that caused random errors.
What was best practice in 2020 may not apply in 2025. The Omron PLC series lineup has changed; the NX family makes third-party integrations easier than the old CJ days, and the Omron PLC communication protocol toolbox is broader. But some fundamentals haven't changed. Clean power and a solid ground still come before code.
Check the part you didn't program first. The PLC is usually the victim, not the criminal.
We made one small process change after that job: every rapid-response checklist now starts with a "power verification" step. And when someone asks me where the Control Panel is in Windows 11, I can say: type "control" in the Run dialog. Then check the outlet.
