How to Select PLC Architecture for a Machine
Most PLC decisions get made too early. Someone picks a controller off the last job's bill of materials, and six months later the machine has grown a second station, three more servo axes, a vision check and a robot, and the platform is out of room. We've been building custom machines for 30 years, and the pattern hasn't changed. The architecture decision matters more than the brand, and it has to be made from how the machine runs, how it fails and who will fix it at 2 AM.
Start With the Process
Before we talk hardware, we write down the sequence, the cycle time, what the operator touches, how material moves, where quality gets checked and how many shifts the machine will run. A standalone fixture with a few prox sensors and a multi-station assembly cell with robots, barcode verification and traceability are two different control problems, even if the I/O counts look close.
Then we list every device and ask one question about each of them: what happens when it stops talking, sends a bad value, or fails energized? That answer drives the controller choice, the safety design and the fault recovery more than any spec sheet.
Match the Architecture to the Machine
Compact. A small machine with everything near one panel can run well on a compact PLC with built-in I/O. It's cheaper and simpler. The catch is that spare I/O points don't fix a lack of memory, communications or expansion slots once the customer adds a station.
Modular. A rack with a processor, power supply, comms and I/O cards is where most of our custom machines land. You size it to the job, add cards as options come in, and replace a module instead of a controller.
Distributed. Long machines, conveyor lines and robotic cells usually get remote I/O at each station. It saves a lot of wire and makes troubleshooting local. But remote I/O is part of the control system, not a wiring shortcut. Network layout, managed switches, voltage drop and what each station does on a lost connection all have to be engineered.
Size I/O for the Next Change, Not for Everything
Separate discrete, analog, safety, high-speed and specialty points such as load cells, thermocouples and encoders. Treating them all as "I/O" is how commissioning surprises start.
A machine that needs 120 points doesn't need a 250-point system. Put the spare capacity where expansion is actually likely: rack slots, network ports, power supply margin, panel space and channels for the options already on the table. And mind placement. A low-level analog signal run alongside a VFD or a welder will give you problems no amount of code can fix.
Settle Motion, Robots, Safety and Vision Up Front
These drive the architecture more than the point count does. A PLC that sequences cylinders fine may not handle synchronized servo motion. Define the axes, accuracy, camming, coordination and recovery after a fault, and decide whether motion lives in the PLC, a motion controller or the drive.
With robots, draw a clear line. In our manufacturing automation and integration work, the PLC owns material flow, permissives, safety status and sequencing, and the robot controller owns paths and robot faults. The handoff should be something a maintenance tech can see, not something buried in interlocks.
Safety gets designed with the machine, not bolted on after the panel layout is done. Zones, e-stops, door switches, light curtains, safe torque off and restart conditions come out of the risk assessment, and that decides between safety relays, a safety PLC or distributed safety I/O. Vision works the same way. Let the PLC coordinate it and let the vision controller do the vision.
Decide What Data Leaves the Machine
Some machines need an HMI and a fault history. Others need counts, downtime reasons, recipes, quality results and serialized tracking feeding plant systems. Settle who owns that data and what happens when the network drops. A reporting connection going down should never stop production.
Plant standards, spare parts and the customer's cybersecurity policy matter as much as protocol compatibility. Remote access can save a day of diagnosis, but it needs controlled permissions, network segmentation and the customer's sign-off every time.
Build It for the Person Who Fixes It
A control system gets judged when it faults in the middle of a shift. Alarms that name the station and device, labeled components, accessible terminals and drawings that match the panel are architecture decisions, not finishing touches. Some faults need a full reset. Others should allow a controlled restart without scrapping the parts in the machine.
The same goes for power: separate and protect control power, plan for inrush, ground it properly, and decide whether a UPS is needed. In a harsh environment, enclosure rating, heat and access for service can matter more to equipment life than the PLC model.
This is also why we built AetherMIP, our on-prem AI appliance for PLC-controlled machines. It reads the machine's data and its documentation and helps operators and techs find faults faster, and the AI can't write back to the PLC. Good architecture makes a machine diagnosable, and AetherMIP is built to take advantage of that.
Don't Overbuild It
The goal isn't the biggest platform. It's the right amount of capability for the production risk. A low-volume fixture shouldn't carry line-control cost, and a high-throughput cell shouldn't be held back by a controller picked to win the quote. Before we release a design, we ask five questions:
- Does it hold cycle time at peak?
- Does it cover every required safety function?
- Can maintenance find and recover from the common faults?
- Can it take the options the customer is already talking about?
- Can parts and support be had without a long shutdown?
If the answer to any of them is no, the architecture isn't done. From our shop in Reading, PA, we design, build, commission and support custom machines across the Mid-Atlantic, and we hand over complete drawings, software backups and a spare parts plan with every one.